Duplicate topic messages received with network of brokers and selectors

• Key: AMQ-1509
• Type: Bug
• Status: Reopened
• Priority: Major
• Assignee: Rob Davies
• Reporter: Howard Orner
• Component/s: Transport, Broker
• Affects Version/s: 4.1.1
• Fix Version/s: 5.2.0

Description

If you create a network of two brokers, A and B, one publisher publishing to A, and n (where n is > 1) receivers with selectors, each receiver recieves n messages for every 1 message sent. The key here is to have a selector. It would appear that the conduitSubscriptions flag does not work when using selectors. The conduit does not properly reconcile consumers if they have selectors. A suggested soltuion would be that ather than process each selector independantly, each selector should be or'ed together and if any selector results in true then a single message should be sent to the other broker.

In doing research, it would appear that this problem was introduced with bug fix AMQ-810. Another user reported it via email back to the assignee of AMQ-810 and a short dialog transpired. See http://www.mail-archive.com/[e-mail]/msg05198.html.

Comments

[Howard Orner]

I do not see any subversion commits listed nor do I see code changes in files I would have expected to change on the main subversion trunk. Is there a way to get the code changes associated with this resolution? Thanks!

[Vui Nguyen]

Hello Rob. I have been assigned to fix this bug for a version of activemq at work. Since we need this fix fairly soon and it would be a shame to have to reinvent the wheel, I'd really appreciate it if you could share your solution to this bug. I'm actually working on this task for Howard Orner, who submitted the previous comments. Thanks.

[Giovanni Toffetti]

Hi all,

I'm also wondering how to get to the patch for this issue, it seems it's not included in the RC4 release of 5.1.0 as I can still reproduce it using 4 brokers.
Did anybody manage to solve the problem?

Thank you.

[Howard Orner]

Here's a description of how to fix it. Sorry, I don't have the source available to me right now to upload it, but it's pretty straight forward. I'm also doing this from memory so you may have to look at the code a bit and make sure I'm not missing anything.

The ideal solution would actually apply an 'or' of all selectors before forwarding message between brokers. However that appears very difficult to do because of all the classes involved and the fact that the selector is parsed and cached where its used in other places. So instead, the org.apache.activemq.network.ConduitBridge and DurableConduitBridge were modified to change all incoming subscription selectors to null before adding the subscription to the list of interested consumers. This results in excess network traffic because all messages get forwarded regardless of whether the 'other' brokers will actually deliver them after they apply individual selectors. But it works.

In ConduitBridge.addToAlreadyInterestedConsumers() remove the lines that check for a selector. Then put in a line that sets the selector to null before doCreateDemandSubscrition is called in createDemandSubcription. Do basically the same in DurableConduitBridge.

Rob - If this hasn't really been fixed (it appears not to be), I and I'm sure others would appreciate it if you would incorporate this into the code. It would be better to take my original suggestion of 'or'ing selectors together, but that looks like a lot of code changes, so this at least fixes the bug with just a few lines of code.

[Giovanni Toffetti]

Thank you Howard.

I'm afraid the temporary fix you propose wouldn't be of much use in my case. I am currently working at comparing how well our in-house distributed pub/sub solution routes packets with respect to ActiveMQ on a generic network of brokers: if I implement the temporary fix ActiveMQ performance wouldn't probably be as good as it should invalidating my test. I guess I'll have to find another MOM for the experiments while ActiveMQ gets fixed. Did any of you ever use any other JMS implementation supporting generic (cyclic) networks of brokers?

Using pub/sub on networks of brokers must not be so common after all, I would have expected this bug to receive much more comments.

Thank you again.

[Rob Davies]

Yep - not fixed

[Rob Davies]

The only 'safe' way to do this is the simple fix suggested by Howard. If we try and OR selectors together - we have to deal with the timing around updating that selector state - and this could be prone to some difficult to track down timing issues.

If you want to shape the traffic across networks, the best way would be to use destinations, wilcards and network filters.