[ 
https://issues.apache.org/jira/browse/AMQ-9262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17730072#comment-17730072
 ] 

ASF subversion and git services commented on AMQ-9262:
------------------------------------------------------

Commit 04cb6585bde51818eff089a2823b20e9e4a62991 in activemq's branch 
refs/heads/activemq-5.18.x from Christopher L. Shannon
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=04cb6585bd ]

AMQ-9262 - Fix network subscriptions for composite consumers (#1014)

This fixes network subscriptions that are generated on demand when a
consumer uses composite destinations. Before this fix conduit
subscriptions didn't work correctly. This fix now splits up the
composite dest and generates correct demand for each of the individual
destinations.

(cherry picked from commit 901956d4ddb6a0ea9fe5fedf39732117ab68f087)


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

Reply via email to