> First, in a subscription only have one redelivery tracker, pending acks is > binding to consumer, we don't need to record redelivery count per consumer > and if record it in consumer, will get a different behavior ismax redelivery > count per consumer, but for now we defined the redelivery count per > subscription.
Sure, what I was thinking was more to store it in consumer pending acks and carrying it over to the new consumer when redelivering. > Second, i think we need separate pending acks and redeliveryTracker, it's > better to implement another redeliveryTracker. Sure, these are separate concepts. Though I think the current name `pendingAcks` is a bit misleading. What the map really tracks is "message that were pushed to this consumer and not acked". My main concern with the new map is to have to potentially accumulate lots of items in the concurrent hash map, irrespective of whether the DLQ is being used or not. Especially, this might be mostly not the case in exclusive/failover subscriptions, where data is typically processed in order. [ Full content available at: https://github.com/apache/incubator-pulsar/pull/2508 ] This message was relayed via gitbox.apache.org for [email protected]
