Document share consumer poison message protection and delivery count #4103
Conversation
Add comprehensive documentation on KIP-932's broker-side poison message protection mechanism. Clarifies that delivery count is broker-internal and not exposed to applications. Includes: - How delivery count works and configuration via group.share.delivery.attempt.limit - Retry strategy recommendations using RELEASE/REJECT/ACCEPT acknowledgment types - Example showing proper error handling patterns for transient vs permanent failures Addresses common questions about redelivery semantics in share consumers. Signed-off-by: Soby Chacko <soby.chacko@broadcom.com>
| // Release the record for redelivery | ||
| // Broker will retry up to group.share.delivery.attempt.limit times | ||
| logger.warn("Transient error processing order, will retry: {}", e.getMessage()); | ||
| ack.release(); // RELEASE - make available for retry |
There was a problem hiding this comment.
Just a question.
When we do release for the intermittent errors, does broker ensure an order of records?
Or when we use share group consumer the order of records is of the scope and we should treat every record as independent logical entity which does not effect any others?
Thanks
There was a problem hiding this comment.
When using Share Groups, there's no ordering guarantee - records are distributed at the record level across any available consumer, so they can be processed out of order. When release() is called, that record goes back into the pool and could be picked up by any consumer at any time, with no guarantee about when it gets redelivered relative to other records. Each record should be treated as an independent entity that doesn't depend on the order of others. If ordering matters for a use case, traditional consumer groups are the right choice since they provide ordering guarantees within each partition.
2 participants
Add comprehensive documentation on KIP-932's broker-side poison message
protection mechanism. Clarifies that delivery count is broker-internal
and not exposed to applications.
Includes:
Addresses common questions about redelivery semantics in share consumers.