[
https://issues.apache.org/activemq/browse/AMQ-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rainer Klute updated AMQ-1095:
------------------------------
Attachment: activemq-patch-AMQ-1095.jar
Okay, folks, here's a hack to solve this issue. With this patch the
KahaTopicMessageStore.addMessage(ConnectionContext, Message) method refuses to
add a message to those subscription containers where the message does not match
the respective subscription selector.
Unfortunately the method does not have much it can build on except for the
message itself and the subcription info. Therefore I had to re-implement the
selector matching stuff from AbstractSubscription. Another option would have
been to pass on some necessary information to the store, but I didn't want to
fiddle around with any ActiveMQ architecture issues.
Probably the ActiveMQ architects can find a better and more elegant solution to
this problem. Well, at least my JUnit test run now, and my project will
hopefully do so, too.
(As an aside, I observed that the
hash-index-topic-data_topic___TheNameOfMyTopic file in the Kaha directory grows
without paying attention to the maximum file limit. What will happen here in
the end?)
> Invalid messages selected from durable topic
> --------------------------------------------
>
> Key: AMQ-1095
> URL: https://issues.apache.org/activemq/browse/AMQ-1095
> Project: ActiveMQ
> Issue Type: Bug
> Components: Selector
> Affects Versions: 5.0.0
> Reporter: Albert Strasheim
> Assignee: Rob Davies
> Attachments: activemq-patch-AMQ-1095.jar, ActiveMQ_Testcases.jar,
> DurableTopicSelector.java
>
>
> We think we've found an issue with durable topic subscriptions and message
> selectors.
> The attached application sends messages with an int property i with values
> 0..19 to a topic. We also have a durable subscription to the topic, selecting
> messages for which i%2=0. After sending the messages, the connection is
> started, allowing the consumer to receive the messages we've published that
> match the selection criterion. The second and every subsequent time we run
> the application, we see the following:
> message.i = 19
> message.i = 0
> message.i = 2
> message.i = 4
> message.i = 6
> message.i = 8
> message.i = 10
> message.i = 12
> message.i = 14
> message.i = 16
> message.i = 18
> message.i = 19 does not match the message selector criterion but it reaches
> our message handler anyway.
> Tested with ActiveMQ from trunk, revision 486090.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
