-
Notifications
You must be signed in to change notification settings - Fork 916
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
ARTEMIS-4415 accept indeterminism of broker dispatch #4602
base: main
Are you sure you want to change the base?
Conversation
make me wonder what is actually being verified, at the point of clientsession start, it is not possible to know the state of the broker unless we wait for some metric, maybe wait to count == 2. |
@@ -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)); |
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.
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.
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.
I think the crux is that the broker decides what is the LV, and it is non deterministic in this case.
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.
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.
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.
@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...
No description provided.