poorbarcode commented on code in PR #20179:
URL: https://github.com/apache/pulsar/pull/20179#discussion_r1208606556
##########
pulsar-broker/src/main/java/org/apache/pulsar/broker/service/persistent/PersistentStickyKeyDispatcherMultipleConsumers.java:
##########
@@ -65,23 +67,22 @@ public class PersistentStickyKeyDispatcherMultipleConsumers
extends PersistentDi
private final KeySharedMode keySharedMode;
/**
- * When a consumer joins, it will be added to this map with the current
read position.
- * This means that, in order to preserve ordering, new consumers can only
receive old
- * messages, until the mark-delete position will move past this point.
+ * When a consumer joins, it will be added to this map with the current
last sent position per the message key.
+ * This means that, in order to preserve ordering per the message key, new
consumers can only receive old
+ * messages, until the mark-delete position will move past this point in
the key. New consumers can receive
+ * any new messages with the message key that is not in the last sent
position.
*/
- private final LinkedHashMap<Consumer, PositionImpl>
recentlyJoinedConsumers;
-
- private final Set<Consumer> stuckConsumers;
- private final Set<Consumer> nextStuckConsumers;
+ private final LinkedHashMap<Consumer, LastSentPositions>
recentlyJoinedConsumers;
+ // The lastSentPosition is not thread-safe
+ private final LastSentPositions lastSentPositions;
PersistentStickyKeyDispatcherMultipleConsumers(PersistentTopic topic,
ManagedCursor cursor,
Review Comment:
@equanz Sorry, my reply has been delayed again
Let me summarize this scenario:
1. a message(`Msg_1`) was put into the Replay Queue caused by the target
consumer(`C_1`) having no permits.
2. at this moment, the new Consumer(`C_2`) takes over the key of `Msg_1`
above.
3. in the next round, `Msg_1` was delivered to `C_2`.
Is this explain correct?<sup>[1]</sup>
---
If yes<sup>[1]</sup>, I have some question: If we revert the PR
https://github.com/apache/pulsar/pull/20026, the `step 1` and `step 2` can not
be executed concurrently, right?<sup>[2]</sup>
---
If yes <sup>[2]</sup>, there have 2 case:
#### Case 1: `step 1` runs before `step 2`
In this case, the `max read position` of `C_2` should be larger than
`Msg-1`, then `Msg_1` will not be sent to `C_2` in the next round.
#### Case 1: `step 2` runs before `step 1`
In this case, the key of `Msg_1` above will still be taken over by `C_1`,
then `Msg_1` will not be sent to `C_2` in the next round.
--
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]
