TakaHiR07 commented on code in PR #25076:
URL: https://github.com/apache/pulsar/pull/25076#discussion_r2625482838
##########
pulsar-broker/src/main/java/org/apache/pulsar/broker/delayed/InMemoryDelayedDeliveryTracker.java:
##########
@@ -126,10 +126,13 @@ public boolean addMessage(long ledgerId, long entryId,
long deliverAt) {
}
long timestamp = trimLowerBit(deliverAt, timestampPrecisionBitCnt);
- delayedMessageMap.computeIfAbsent(timestamp, k -> new
Long2ObjectRBTreeMap<>())
- .computeIfAbsent(ledgerId, k -> new Roaring64Bitmap())
- .add(entryId);
- delayedMessagesCount.incrementAndGet();
+ Roaring64Bitmap roaring64Bitmap = delayedMessageMap
+ .computeIfAbsent(timestamp, k -> new Long2ObjectRBTreeMap<>())
+ .computeIfAbsent(ledgerId, k -> new Roaring64Bitmap());
+ if (!roaring64Bitmap.contains(entryId)) {
+ roaring64Bitmap.add(entryId);
Review Comment:
InMemoryDelayedDeliveryTracker#clear() is trigger in this two place.
<img width="1305" height="331" alt="image"
src="https://github.com/user-attachments/assets/015eec31-f7a8-4fc7-a244-8d1e9dd27bb2"
/>
AddConsumer I think is ok because it would synchronized clear in
removeConsumer. modified in this pr,
https://github.com/apache/pulsar/pull/22270. It looks like a double-check
operation.
https://github.com/apache/pulsar/blob/82ab144e6d38b5544ab814b02abf8c4099b94150/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/persistent/PersistentDispatcherMultipleConsumersClassic.java#L255
Pulsar-admin clearBacklog I am not sure, but I guess it is no matter. Just
as the same as pulsar-admin reset-cursor, if we reset-cursor when consumer is
connecting, the offset may be not the one we want to set. So we should
disconnect consumer and then do pulsar-admin operation.
--
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]