Asynchronous server-side processing in a request/reply scenario

[dnitzan]

Request/reply semantics requires that the server side listener method (annotated with @SendTo) return a response synchronously. There are use cases where server side request processing is asynchronous such that the listener method can't return a result immediately and must defer the response, releasing the consumer thread to handle other incoming requests. Once the result is available, an application thread would need to send it back to the client. This would be a feature similar to Servlet 3.0 Asynchronous Processing.

[garyrussell]

We already added this for @RabbitListener last year.

However, managing the offsets for Kafka could make this tricky to implement - we wouldn't want to commit the offset until the async operation is complete.

If the next async operation completes first, and its offset committed, and then the first one fails, it's too late because its offset has already been implicitly committed.

Since Kafka message are not discretely acknowledged, going async with Kafka record consumption is really not recommended because of the risk of message loss and/or the complexity of managing offsets.

For this reason we didn't proceed here, but we can put it on the backlog and give it some more thought.

[dnitzan]

True, we faced the same issues building a custom request/reply mechanism on top of Spring Kafka. We eventually elected to just commit periodically (with ack-mode=time) regardless of downstream asynchronous processing and it is perfectly fine for us. If such a relaxed guarantee is sufficient, then it greatly simplifies the implementation.

[garyrussell]

OK; with that caveat; we'll try to get it into a future release.

[dcheung2]

I think it is reasonable difficulty. But still may could be done even without a full prefect asynchronized flow.

for example.

when ackMode=BATCH
-> That container could async all the listeners within same BATCH but refer the ack until all messages in a poll() responsed

when ackMode=TIME
-> same as BATCH, but synchronize all once by time, not poll()

when ackMode=RECORD
-> No real concurrently processing. Just one message a time, but allow developers to use async API.

The real difficulty is timeout/retry management which make the state complex.

For another example,
if the first message jammed, the 2nd failed, but 3rd successes. should it ack or retry from where ?
but this is a problem business logic to worry about. not the middleware
That spring-kafka should provide some configuration.