apache
ARTEMIS-4787 anycast q is not auto-created if multicast q already exists 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.
BTW, I already ran the full test-suite on this and there were no failures related to my changes.
Does https://github.com/apache/activemq-artemis/commit/ac1b483cb449b72b5eaa2b4c6547bc7cdea92dae 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.
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.
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.
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.
I'm abandoning this for now as the user who requested this change is dealing with it client-side.