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-4787 anycast q is not auto-created if multicast q already exists on address #4957

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

Conversation

jbertram
Copy link
Contributor

@jbertram jbertram commented Jun 3, 2024

There's an edge-case in the auto-creation logic for anycast queues that checks to see if any queue already exists on the address and if so then nothing further is created. It's not clear to me what use-case this is for, and it precludes the use-case detailed on ARTEMIS-4787 where a migrating user has overlapping names for JMS queues and topics.

This commit removes this edge-case and adds a test to verify auto-creation works properly with both OpenWire and Core. The test includes methods for AMQP, but they are disabled since the AMQP protocol handler doesn't handle this use-case at all. This PR is specifically for OpenWire.

@jbertram
Copy link
Contributor Author

jbertram commented Jun 3, 2024

BTW, I already ran the full test-suite on this and there were no failures related to my changes.

@jbertram jbertram force-pushed the ARTEMIS-4787 branch 5 times, most recently from 6540f95 to 354a704 Compare June 6, 2024 04:17
@jbertram jbertram changed the title ARTEMIS-4787 anycast q does not auto-created if multicast q already exists on address ARTEMIS-4787 anycast q is not auto-created if multicast q already exists on address Jun 6, 2024
@gemmellr
Copy link
Member

gemmellr commented Jul 1, 2024

Does ac1b483 factor in here at all? I believe it came up in the context of federation, but seems like it could overlap and looks like it went in after your changes were created.

Needs rebased and retested either way at this point.

@tabish121
Copy link
Contributor

This one needs rebased and touched up before it can be checked as main has quite a few changes including deprecating methods in SimpleString the tests added are still using.

…sts on address

There's an edge-case in the auto-creation logic for anycast queues that
checks to see if any queue already exists on the address and if so then
nothing further is created. It's not clear to me what use-case this is
for, and it precludes the use-case detailed on ARTEMIS-4787 where a
migrating user has overlapping names for JMS queues and topics.

This commit removes this edge-case and adds a test to verify
auto-creation works properly with both OpenWire and Core. The test
includes methods for AMQP, but they are disabled since the AMQP protocol
handler doesn't handle this use-case at all. This PR is specifically for
OpenWire.
@tabish121
Copy link
Contributor

Does ac1b483 factor in here at all? I believe it came up in the context of federation, but seems like it could overlap and looks like it went in after your changes were created.

Needs rebased and retested either way at this point.

The change in the mentioned commit doesn't come into play here as the AMQP sender controller code is checking that an address created with one routing type doesn't get used when creating a queue with the opposing routing type, in this case the first consumer created wins and the second case can't proceed as it would violate the checks int he controller.

@tabish121
Copy link
Contributor

tabish121 commented Jul 15, 2024

I ran this through CI and it seems to break quite a few tests, so probably more work to do here.

I checked into some of the failed AMQP tests and the issue is that with this change it now seems to create a queue in cases where it did not in the past because there already was an existing Queue on an Anycast address and so you get failures because you don't get messages you should have because they are in a different Queue than the one the receiver is subscribed to.

@gemmellr gemmellr marked this pull request as draft July 30, 2024 16:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants