Document message acknowledgement in ReactiveMessageConsumer about pulsar-client-reactive HOT 5 OPEN

Beware that batched messages may not be acked if all the messages from the batch are not acked before closing the consumer (the consumer is closed when consumeOne/consumeMany completes).

from pulsar-client-reactive.

Beware that batched messages may not be acked if all the messages from the batch are not acked before closing the consumer (the consumer is closed when consumeOne/consumeMany completes).

This is most likely caused by the lack of configuring .batchIndexAckEnabled(true) on the ReactiveMessageConsumerBuilder and enabling acknowledgmentAtBatchIndexLevelEnabled=true in broker.conf (PULSAR_PREFIX_acknowledgmentAtBatchIndexLevelEnabled=true env variable for docker container, #13 contains changes for Pulsar Testcontainer). If it doesn't fix the issue, we'd have to investigate further.

from pulsar-client-reactive.

The purpose of MessageResult is to have a functional and data (value) oriented way to do acknowledgments without side-effects. In functional programming, everything is a value. By googling, I found a related presentation "Railway Oriented Programming: Functional error handling". It's in different context, but that presentation explains the type of design. Wikipedia's "Result type" contains a short explanation.

from pulsar-client-reactive.

This is most likely caused by the lack of configuring .batchIndexAckEnabled(true) on the ReactiveMessageConsumerBuilder and enabling acknowledgmentAtBatchIndexLevelEnabled=true in broker.conf

I think that if the consumer gets closed the batch will be fully redelivered to another consumer. So it's not really enough for the consumeOne case.

from pulsar-client-reactive.

This is most likely caused by the lack of configuring .batchIndexAckEnabled(true) on the ReactiveMessageConsumerBuilder and enabling acknowledgmentAtBatchIndexLevelEnabled=true in broker.conf

I think that if the consumer gets closed the batch will be fully redelivered to another consumer. So it's not really enough for the consumeOne case.

.batchIndexAckEnabled(true) and acknowledgmentAtBatchIndexLevelEnabled=true should handle that. I guess the gap is with the asynchronous acknowledgement mode which might not wait for all pending acknowledgements to "drain" when closing.

from pulsar-client-reactive.