Skip to content
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.

Sign up for GitHub

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

Jump to bottom

ARTEMIS-4415 accept indeterminism of broker dispatch #4602

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from
Draft

ARTEMIS-4415 accept indeterminism of broker dispatch #4602

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 4 additions & 2 deletions ...ion-tests/src/test/java/org/apache/activemq/artemis/tests/integration/server/LVQTest.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -167,11 +167,13 @@ public void testMultipleMessages() throws Exception {
ClientMessage m = consumer.receive(1000);
Assert.assertNotNull(m);
m.acknowledge();
Assert.assertEquals(m.getBodyBuffer().readString(), "m3");
String val = m.getBodyBuffer().readString();
Assert.assertTrue("1 or 3 =? " + val, "m1".equals(val) || "m3".equals(val));
Copy link
Member

@gemmellr gemmellr Sep 1, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesnt seem like a desirable change for an LVQ test. It would then be about as well deleted for all the good it would really be doing in verifying the 'LV' bit.

It currently creates the consumer before sending so it seems rather pot-luck what it will see. The next test creates it after, and also checks the count as you said. Or it could use a transacted producer for the 'second round' of sends. Something synchronous between send and check, basically.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the crux is that the broker decides what is the LV, and it is non deterministic in this case.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is currently but per your comment and other tests it could probably be made deterministic. Instead, with this change the test wouldnt really be verifying anything much at all.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gtully can't you instead make the test deterministic? like keeping consumers and senders on a certain condition that's required for the test?

I had this issue in other tests... where I needed to verify the bindings were in place before asserting.. or the consumers were ready to receive with credits.. etc...

m = consumer.receive(1000);
Assert.assertNotNull(m);
m.acknowledge();
Assert.assertEquals(m.getBodyBuffer().readString(), "m4");
val = m.getBodyBuffer().readString();
Assert.assertTrue("2 or 4 =? " + val, "m2".equals(val) || "m4".equals(val));
}

@Test
Expand Down
Loading