[
https://issues.apache.org/jira/browse/AMQ-9262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher L. Shannon updated AMQ-9262:
----------------------------------------
Fix Version/s: 5.18.2
(was: 5.18.1)
> Composite consumers do not work properly with a network of brokers
> ------------------------------------------------------------------
>
> Key: AMQ-9262
> URL: https://issues.apache.org/jira/browse/AMQ-9262
> Project: ActiveMQ
> Issue Type: Bug
> Components: Network of Brokers
> Affects Versions: 5.18.1
> Reporter: Christopher L. Shannon
> Assignee: Christopher L. Shannon
> Priority: Major
> Fix For: 5.19.0, 5.17.5, 5.18.2
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> 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.
> {code:java}
> final ActiveMQTopic compositeTopic = new ActiveMQTopic(testTopic1 + "," +
> testTopic2);
> TopicSubscriber durSub1 = session1.createDurableSubscriber(compositeTopic,
> subName + "1");
> TopicSubscriber durSub2 = session1.createDurableSubscriber(compositeTopic,
> subName + "2");{code}
> 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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
