Does nobody use Topics with Camel? They don't seem to work as expected.
JB
On 5/30/14 10:48 AM, "Jeff Bischoff" <jbisch...@wdtablesystems.com> wrote:
>Correction:
>
>1) Why would *CACHE_CONSUMER* on the ActiveMQComponent cause endless
>external
>redeliveries of a (filtered out) topic message, when with other cache
>settings (like CACHE_SESSION) this does not occur?
>
>
>
>
>On 5/30/14 10:39 AM, "Jeff Bischoff" <jbisch...@wdtablesystems.com> wrote:
>
>>Maybe I need to narrow my questions:
>>
>>1) Why would CACHE_SESSION on the ActiveMQComponent cause endless
>>external
>>redeliveries of a (filtered out) topic message, when with other cache
>>settings this does not occur?
>>
>>2) Why would <rollback/> prevent the external redeliveries, but <stop/>
>>does not prevent them?
>>
>>
>>Did I provide enough info below to answer these questions? Topics just
>>aren't working in Camel the way that I would expect!
>>
>>Thanks,
>>
>>Jeff Bischoff
>>WDTS
>>
>>On 5/29/14 4:25 PM, "Jeff Bischoff" <jbisch...@wdtablesystems.com> wrote:
>>
>>>Hi all,
>>>
>>>Please forgive me if this is a basic question.
>>>
>>>Working with Camel and JMS Topics has seemed very finicky for me so far.
>>>If I make slight configuration changes, I see the same message repeated
>>>endlessly. Using jconsole, I now know these messages are "external
>>>redeliveries", i.e. the same message is being sent from JMS to Camel
>>>repeatedly without ever getting through. It happens in the case of
>>>messages that I am intentionally not processing due to some criteria.
>>>What I don't understand is why these external redeliveries keep
>>>occurring, when I simply want this message to be dropped.
>>>
>>>For example, if I use CACHE_SESSION or lower cache level, the following
>>>route works just fine for me:
>>>
>>>
>>> <route id="topics-out">
>>> <from uri="topic-jms:topic:projectx.>"/>
>>> <log message="Picked up message with id: ${id},
>>>destinationType: ${header.DestinationEntityType}" loggingLevel="INFO"/>
>>> <choice>
>>> <when>
>>> <simple>${header.DestinationEntityType} not in
>>>'FOO,BAR'</simple>
>>> <log message="Detected new ${header.Name} topic
>>>message on ${header.JMSDestination} with id: ${id}, destinationType:
>>>${header.DestinationEntityType}" loggingLevel="INFO"/>
>>> <recipientList ignoreInvalidEndpoints="false">
>>> <simple>lc-jms:${header.JMSDestination}</simple>
>>> </recipientList>
>>> </when>
>>> </choice>
>>> </route>
>>>
>>>
>>>However, if I switch to CACHE_CONSUMER and I have even one message
>>>addressed to 'FOO' or 'BAR', I will see the endless external
>>>redeliveries. Note that I am using a SingleConnectionFactory
>>>specifically
>>>for this route.
>>>
>>> <route id="topics-out">
>>> <from uri="topic-jms:topic:projectx.>"/>
>>> <log message="Picked up message with id: ${id},
>>>destinationType: ${header.DestinationEntityType}" loggingLevel="INFO"/>
>>> <choice>
>>> <when>
>>> <simple>${header.DestinationEntityType} not in
>>>'FOO,BAR'</simple>
>>> <log message="Detected new ${header.Name} topic
>>>message on ${header.JMSDestination} with id: ${id}, destinationType:
>>>${header.DestinationEntityType}" loggingLevel="INFO"/>
>>> <recipientList ignoreInvalidEndpoints="false">
>>> <simple>lc-jms:${header.JMSDestination}</simple>
>>> </recipientList>
>>> </when>
>>> </choice>
>>> </route>
>>>
>>>Now, if I add an Otherwise clause with a Rollback, everything works fine
>>>again (albeit with a handful of log messages due to the rollbacks):
>>>
>>> <route id="topics-out">
>>> <from uri="topic-jms:topic:projectx.>"/>
>>> <log message="Picked up message with id: ${id},
>>>destinationType: ${header.DestinationEntityType}" loggingLevel="INFO"/>
>>> <choice>
>>> <when>
>>> <simple>${header.DestinationEntityType} not in
>>>'FOO,BAR'</simple>
>>> <log message="Detected new ${header.Name} topic
>>>message on ${header.JMSDestination} with id: ${id}, destinationType:
>>>${header.DestinationEntityType}" loggingLevel="INFO"/>
>>> <recipientList ignoreInvalidEndpoints="false">
>>> <simple>lc-jms:${header.JMSDestination}</simple>
>>> </recipientList>
>>> </when>
>>> <otherwise>
>>> <rollback markRollbackOnly="true" />
>>> </otherwise>
>>> </choice>
>>> </route>
>>>
>>>But if I change that Rollback to a Stop instead, I get the endless
>>>external redeliveries again:
>>>
>>> <route id="topics-out">
>>> <from uri="topic-jms:topic:projectx.>"/>
>>> <log message="Picked up message with id: ${id},
>>>destinationType: ${header.DestinationEntityType}" loggingLevel="INFO"/>
>>> <choice>
>>> <when>
>>> <simple>${header.DestinationEntityType} not in
>>>'FOO,BAR'</simple>
>>> <log message="Detected new ${header.Name} topic
>>>message on ${header.JMSDestination} with id: ${id}, destinationType:
>>>${header.DestinationEntityType}" loggingLevel="INFO"/>
>>> <recipientList ignoreInvalidEndpoints="false">
>>> <simple>lc-jms:${header.JMSDestination}</simple>
>>> </recipientList>
>>> </when>
>>> <otherwise>
>>> <stop/>
>>> </otherwise>
>>> </choice>
>>> </route>
>>>
>>>Why does rolling back prevent the unwanted message from being
>>>redelivered, while using "stop" causes the redelivery to occur?
>>>Intuitively, I would have thought it would work the opposite way.
>>>Rolling
>>>back should put the item back on the "from" endpoint, allowing it to be
>>>processed again. "Stop" should just drop the message, preventing further
>>>redelivery. What I'm actually seeing is the opposite of this. Am I
>>>misunderstanding?
>>>
>>>I also get the same exact symptoms if I leave the cache level at
>>>CACHE_SESSION, but I make the subscription durable. In that case the
>>>rollbacks prevent the problem, but otherwise I get the eternal external
>>>redeliveries.
>>>
>>>Using a Filter element also produces the same results as using the
>>>Choice
>>>element above:
>>>
>>> <route id="topics-out">
>>> <from
>>>uri="topic-jms:topic:projectx.>?durableSubscriptionName=testdurasub"/>
>>> <log message="Picked up message with id: ${id},
>>>destinationType: ${header.DestinationEntityType}" loggingLevel="INFO"/>
>>> <filter>
>>> <simple>${header.DestinationEntityType} not in
>>>'FOO,BAR'</simple>
>>> <recipientList ignoreInvalidEndpoints="false">
>>> <simple>lc-jms:${header.JMSDestination}</simple>
>>> </recipientList>
>>> </filter>
>>> </route>
>>>
>>>When I look at the topic in JMS, I see the topic "projectx.>" appearing
>>>and disappearing in the list rapidly. I assume that's caused by the
>>>Camel
>>>polling frequency. It seems a little disturbing to me; is that normal?
>>>
>>>Thanks so much for taking the time to help!
>>>
>>>Jeff Bischoff
>>>WDTS
>>
>
________________________________
Please take note: This email, including attachments, contains information which
may be confidential or legally privileged and is only for the use of the
individual or entity to whom it is properly addressed. Any unauthorized review,
use, disclosure, copying, or distribution is prohibited. If you have reason to
believe that you have received this communication in error, or that it may be
misaddressed or not intended for you, please destroy it and notify the sender
immediately. Thank you.
