Consumer acknowledge messages from streams

[kurenchuksergey]

Hi, I have a basic question, how correctly consume messages, and how to handle any exceptions in MessageHandler?
If I wanna skip messages, then it is clear that I should handle any exception by myself.
Question what will be the opposite?

I ask because MessageHandler doesn't provide a current channel and I can't neck messages like it described here: https://www.rabbitmq.com/streams.html#consuming

Maybe it is just unclear to me from the current documentation (https://rabbitmq.github.io/rabbitmq-stream-java-client/stable/htmlsingle)

What I use:
Spring AMQP: https://github.com/spring-projects/spring-amqp/blob/80313264e9dfc63c75ebd43d2dbeb6aa63f22c23/spring-rabbit-stream/src/main/java/org/springframework/rabbit/stream/listener/StreamListenerContainer.java#L263

which depends on MessageHandler and provides me channel as a null

[acogoluegnes]

If you want to skip messages you have to ignore them and return in the MessageHandler, messages will keep flowing. The acknowledgment with AMQP is just a way of asking for more messages, which is not necessary with the stream client.

If you want to have more control over how messages are flowing (e.g. to avoid overflowing your consumers), there is a new flow API in 0.11.0.

Note that this flow control is independent of offset tracking, which is a way to store at which point a consumer is in a given stream (to be able to restart a new incarnation of the consumer where the previous one left off).

[kurenchuksergey]

Hi @acogoluegnes Thanks for your answer!
Seems I can freeze a processing by flowSubscription (similar to java/reactor flow). Now it is clear.
Only one thing I still do not know: What is the default behavior if your message handler throws any exception?
Will it skip the message/will it retry this message? What will be with offset?

[acogoluegnes]

In case of an exception in the message handler, the whole delivery frame is skipped. That can be several messages (a "chunk"). Then messages will keep flowing in subsequent delivery frames (if any).

I would recommend using a MessageHandler decorator around your application logic handlers to deal with exceptions and write tests to check the behavior.