merlimat commented on issue #15705: URL: https://github.com/apache/pulsar/issues/15705#issuecomment-1136738845
> @codelipenghui thank you for the explanation; that makes sense. > > Two clarifications: > > 1. How does this apply to nacked messages? if a new KeyShared consumer `c2` is blocked due to markDeletePosition not being caught up to the point where `c2` joined, if an existing consumer `c1` negatively acknowledges a message that hashes to `c2`, will the nacked message go to `c2` or `c1`? C2 will joined and be marked that it can only receive messages dispatched from the moment it joins. In this example, a message nacked by c1, will still get redelivered to c1 (unless c1 disconnects), because the keys are not switched until everything that c1 has already received is acked. Otherwise, we could get a nack on one message and then on another and they could end up being out of order, eg: if c2 also goes away. > 2. Address this limitation, do you really need to track state for every key in the topic? I may be naïve here, but it seems to me that you would only need to track state for **each key which has messages that have been dispatched to a consumer**. That's still an O(N) state where there's currently not one, but it's a much smaller N. This might be getting into feature request territory now though. "**each key which has messages that have been dispatched to a consumer**." ... for which the worst case scenario is to track every key :) -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
