[AMQ-9262] Composite consumers do not work properly with a network of brokers

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 5.18.1
• Fix Version/s: 6.0.0, 5.17.5, 5.18.2
• Component/s: Network of Brokers
• Assignee: Christopher L. Shannon
• Reporter: Christopher L. Shannon
• Created: 06/Jun/23 23:03
• Updated: 13/Jun/23 12:11
• Resolved: 07/Jun/23 11:21

Description

I found an interesting edge case where consumers that use a composite destination do not correctly work dynamically included destinations with a network of brokers. The issue is the composite destination that is used by the consumer causes the bridge to not be able to correctly create conduit subscriptions as the logic used to to check for matching subscriptions fails.

Note: This is referring to a consumer that uses a composite destination string when consuming to subscribe to multiple topics, NOT virtual topics or the composite destination feature in the broker itself.

The end result is that duplicate subscriptions will be created for both topic/queue subscriptions even if conduit subscriptions is enabled. In the durable subscription case this is actually even worse because an exception occurs as it tries to create the same durable more than once which is not allowed of course.

An example like the following fails because the network bridge tries to create the same durable twice and it already exists.

final ActiveMQTopic compositeTopic = new ActiveMQTopic(testTopic1 + "," + testTopic2);
TopicSubscriber durSub1 = session1.createDurableSubscriber(compositeTopic, subName + "1");
TopicSubscriber durSub2 = session1.createDurableSubscriber(compositeTopic, subName + "2");

I looked at a few ways to fix this and the simplest/best way I found is to split the composite destination into individual destinations and create a network demand subscription per destination instead of 1 for the entire composite destination. This solves the issue and allow conduit subscriptions to work and having demand be generated as intended. It also works correctly for durable subs as well. 

I have a PR and tests I will push up, the one caveat is the dynamically include destinations that are allowed need to use a wild card for the filter because of how the advisory filters work for consumers. Ie, the dynamically included list config should have a destination added such as my.topic.>. This will allow composite consumers to work that use something like my.topic.test.1,my.topic.test.2. Listing out individual topics do not work and would require much more work to fix.

Lastly, I did not add a flag to optionally disable/enable this feature. I was thinking about it but this seems like a a bug that should just be fixed and I don't see a reason to keep the old broken behavior. The way it is now conduit subscriptions are completely broken so I think breaking the composite destination into individual for network subs is the correct fix and likely what we should just do. It's also probably an edge case since no one has reported a bug with it so probably not a big deal to change this behavior.