-
Notifications
You must be signed in to change notification settings - Fork 3.7k
[fix][broker] fix delayedMessagesCount error in InMemoryDelayedDeliveryTracker #25076
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -274,4 +274,72 @@ public void testDelaySequence(InMemoryDelayedDeliveryTracker tracker) throws Exc | |
| tracker.close(); | ||
| } | ||
|
|
||
| @Test(dataProvider = "delayedTracker") | ||
| public void testDelayedMessagesCountWithDuplicateEntryId(InMemoryDelayedDeliveryTracker tracker) throws Exception { | ||
| assertFalse(tracker.hasMessageAvailable()); | ||
|
|
||
| // case1: addMessage() with duplicate entryId, | ||
| // getScheduledMessages() enter multiple timestamp and "cardinality <= n", | ||
| // finally make tracker empty | ||
| assertTrue(tracker.addMessage(1, 1, 10)); | ||
| assertTrue(tracker.addMessage(1, 2, 20)); | ||
| assertTrue(tracker.addMessage(1, 2, 20)); | ||
| assertTrue(tracker.addMessage(1, 3, 40)); | ||
| assertTrue(tracker.addMessage(1, 4, 50)); | ||
|
|
||
| clockTime.set(50); | ||
| assertTrue(tracker.hasMessageAvailable()); | ||
| assertEquals(tracker.getNumberOfDelayedMessages(), 4L); | ||
| assertEquals(tracker.delayedMessageMap.size(), 4L); | ||
|
|
||
| Set<Position> scheduled = tracker.getScheduledMessages(10); | ||
| assertEquals(scheduled.size(), 4); | ||
| assertEquals(tracker.getNumberOfDelayedMessages(), 0L); | ||
|
|
||
|
|
||
|
|
||
| // case2: addMessage() with duplicate entryId, | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In case2 the comment says it enters cardinality > n, but with getScheduledMessages(10) and 4 unique entryIds it should hit the cardinality <= n branch. Could we adjust the comment to match the scenario (case3 seems to be the one exercising cardinality > n)?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes. have changed the comment |
||
| // getScheduledMessages() enter one timestamp and "cardinality <= n", | ||
| // finally make tracker empty | ||
| clockTime.set(0); | ||
| assertTrue(tracker.addMessage(1, 1, 10)); | ||
| assertTrue(tracker.addMessage(1, 2, 10)); | ||
| assertTrue(tracker.addMessage(1, 2, 10)); | ||
| assertTrue(tracker.addMessage(1, 3, 10)); | ||
| assertTrue(tracker.addMessage(1, 4, 10)); | ||
|
|
||
| clockTime.set(50); | ||
| assertTrue(tracker.hasMessageAvailable()); | ||
| assertEquals(tracker.getNumberOfDelayedMessages(), 4L); | ||
| assertEquals(tracker.delayedMessageMap.size(), 1L); | ||
|
|
||
| scheduled = tracker.getScheduledMessages(10); | ||
| assertEquals(scheduled.size(), 4); | ||
| assertEquals(tracker.getNumberOfDelayedMessages(), 0L); | ||
|
|
||
|
|
||
|
|
||
| // case3: addMessage() with duplicate entryId, | ||
| // getScheduledMessages() enter one timestamp and "cardinality > n", | ||
| // finally make tracker remain half cardinality | ||
| clockTime.set(0); | ||
| assertTrue(tracker.addMessage(1, 1, 10)); | ||
| assertTrue(tracker.addMessage(1, 2, 10)); | ||
| assertTrue(tracker.addMessage(1, 2, 10)); | ||
| assertTrue(tracker.addMessage(1, 3, 10)); | ||
| assertTrue(tracker.addMessage(1, 4, 10)); | ||
|
|
||
| clockTime.set(50); | ||
| assertTrue(tracker.hasMessageAvailable()); | ||
| assertEquals(tracker.getNumberOfDelayedMessages(), 4L); | ||
| assertEquals(tracker.delayedMessageMap.size(), 1L); | ||
|
|
||
| scheduled = tracker.getScheduledMessages(2); | ||
| assertEquals(scheduled.size(), 2); | ||
| assertEquals(tracker.getNumberOfDelayedMessages(), 2L); | ||
|
|
||
|
|
||
| tracker.close(); | ||
| } | ||
|
|
||
| } | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
About the new n < 0 branch: this should be unreachable in normal flow. One potential way to hit it is int overflow from int cardinality = (int) entryIds.getLongCardinality().
Would it be better to keep cardinality as long (and compare cardinality <= (long) n) to eliminate overflow, instead of only logging when n < 0?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right. I think it is another issue and both use long value is better. Do you think we fix it in this pr or you push another pr to fix?