GitHub user lhotari added a comment to the discussion: async/sync mode in pulsar producer and consumer
When sending messages asynchronously, you cannot assume that they are sent from the client to the broker until the callback receives a message id from each message that has been sent. This comment about the correct usage of the Pulsar Java client might be helpful: https://github.com/apache/pulsar/pull/22011#issuecomment-1936188709 The relevant part: > The Pulsar client is designed to continue attempting to send messages until a > potential send timeout occurs. It's also possible to set up an unlimited send > timeout, allowing the client to retry indefinitely. This feature is detailed > in the Pulsar documentation, available at > https://pulsar.apache.org/docs/3.1.x/cookbooks-deduplication/#pulsar-clients > (it's explained in the context of message deduplication). You can refer to > the Javadocs for [sendTimeout on > ProducerBuilder](https://pulsar.apache.org/api/client/3.1.x/org/apache/pulsar/client/api/ProducerBuilder.html#sendTimeout(int,java.util.concurrent.TimeUnit)). > It's crucial for messaging applications to be equipped to handle potential > failures in message delivery, especially when data consistency is a key > concern. Once the Pulsar client has acknowledged the message as sent by > returning the message id, the responsibility for maintaining and ensuring the > delivery of the message shifts to Pulsar. It's also necessary to verify that > the message id is returned when using the asynchronous API > ([sendAsync](https://pulsar.apache.org/api/client/3.1.x/org/apache/pulsar/client/api/Producer.html#sendAsync(T))). > If sending results in an error or the messaging application never receives a > message id from the Pulsar client, it's the messaging application's > responsibility to retry. GitHub link: https://github.com/apache/pulsar/discussions/22382#discussioncomment-8981176 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
