vroyer commented on PR #211: URL: https://github.com/apache/pulsar-client-reactive/pull/211#issuecomment-2852435189
Hi Lari, With the current implementation, the only way to nack for some business reason is to throw a RuntimeException and the retry is managed by reactor (see [pipelineRetrySpec](https://github.com/vroyer/pulsar-client-reactive/blob/main/pulsar-client-reactive-api/src/main/java/org/apache/pulsar/reactive/client/internal/api/DefaultReactiveMessagePipelineBuilder.java#L66)). In this case, the pulsar DeliveryBackoff is ineffective and this is the reason why I went further with the second commit. The pipeline retry should occurs when the handler unexpectedly fails, not when you need to nack a message for some business logic and rely on the pulsar redelivery to reprocess the message. To avoid a breaking change with the current auto-acknowledged messageHandler, the best solution seems to introduce another "messageHandler2" returning a MessageResult where you can ack or nack messages depending on your use case ? Regards, Vincent. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@pulsar.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
