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.

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

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

Conversation

gtully
Copy link
Contributor

@gtully gtully commented Sep 1, 2023

No description provided.

@gtully
Copy link
Contributor Author

gtully commented Sep 1, 2023

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.
It was breaking after a few thousand iterations for me and now is not, but to some end, it is now verifying two things!

@@ -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

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...

@clebertsuconic clebertsuconic marked this pull request as draft September 12, 2023 17:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants