Return-Path: X-Original-To: apmail-camel-users-archive@www.apache.org Delivered-To: apmail-camel-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 6B284118C9 for ; Thu, 19 Jun 2014 15:04:30 +0000 (UTC) Received: (qmail 64882 invoked by uid 500); 19 Jun 2014 15:04:30 -0000 Delivered-To: apmail-camel-users-archive@camel.apache.org Received: (qmail 64832 invoked by uid 500); 19 Jun 2014 15:04:30 -0000 Mailing-List: contact users-help@camel.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@camel.apache.org Delivered-To: mailing list users@camel.apache.org Received: (qmail 64821 invoked by uid 99); 19 Jun 2014 15:04:29 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 19 Jun 2014 15:04:29 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of jbischoff@wdtablesystems.com designates 207.46.163.244 as permitted sender) Received: from [207.46.163.244] (HELO na01-by2-obe.outbound.protection.outlook.com) (207.46.163.244) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 19 Jun 2014 15:04:25 +0000 Received: from BLUPR04MB290.namprd04.prod.outlook.com (10.141.23.13) by BLUPR04MB290.namprd04.prod.outlook.com (10.141.23.13) with Microsoft SMTP Server (TLS) id 15.0.969.15; Thu, 19 Jun 2014 15:04:03 +0000 Received: from BLUPR04MB290.namprd04.prod.outlook.com ([10.141.23.13]) by BLUPR04MB290.namprd04.prod.outlook.com ([10.141.23.13]) with mapi id 15.00.0969.007; Thu, 19 Jun 2014 15:04:02 +0000 From: Jeff Bischoff To: "users@camel.apache.org" Subject: Re: Why do I get so many "external redeliveries" when using Camel with JMS topics? Thread-Topic: Why do I get so many "external redeliveries" when using Camel with JMS topics? Thread-Index: AQHPe3wfONcT6PUfVEihN9JmBP+AIptY7/gAgAACdQCAGxaQAIAAbI4AgADwO4D//9CYgIAATBYA///N3ACAAMHSgIAAs8cAgAHBvoD//924gA== Date: Thu, 19 Jun 2014 15:04:02 +0000 Message-ID: References: <39B3F7D5-54A9-4A09-A2B5-0F82ED4D46E5@gmail.com> <2C75DB08-DAF1-4C63-B905-75538A6D9D06@gmail.com> In-Reply-To: <2C75DB08-DAF1-4C63-B905-75538A6D9D06@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [47.22.128.211] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02475B2A01 x-forefront-antispam-report: SFV:NSPM;SFS:(6009001)(428001)(164054003)(57704003)(479174003)(377454003)(35754003)(24454002)(51704005)(189002)(199002)(54356999)(76176999)(50986999)(64706001)(87936001)(551934003)(20776003)(2656002)(83072002)(74662001)(85852003)(31966008)(101416001)(85306003)(95666004)(81342001)(99396002)(106116001)(99286002)(105586002)(93886003)(80022001)(66066001)(81542001)(15975445006)(21056001)(19580405001)(19580395003)(83322001)(4396001)(86362001)(79102001)(92726001)(92566001)(74502001)(77982001)(36756003)(76482001)(15202345003)(46102001)(94096001)(579004)(559001);DIR:OUT;SFP:;SCL:1;SRVR:BLUPR04MB290;H:BLUPR04MB290.namprd04.prod.outlook.com;FPR:;MLV:sfv;PTR:InfoNoRecords;MX:1;A:1;LANG:en; received-spf: None (: wdtablesystems.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=jbischoff@wdtablesystems.com; Content-Type: text/plain; charset="iso-8859-1" Content-ID: <25B13E340590B14DBBA12B57DB82EB25@namprd04.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: wdtablesystems.com X-Virus-Checked: Checked by ClamAV on apache.org Thanks for this tip. I did notice in some cases that behavior of the route improved if I explicitly set a transaction manager, though I wasn't sure why that was the case. As for clientID, I do not have one set on the older (non-Camel) configuration. I'll try setting one and seeing if that helps. Thanks, Jeff On 6/19/14 9:06 AM, "Minh Tran" wrote: >Somewhere along the line, you=B9ll need a clientId for topic subscriptions= . >I see one set for your camel connection factory and I suspect you have a >client id for your non-camel subscriber on your Spring >DefaultMessageListenerContainer. Make sure this is not the same client id >as the one you put on your camel connection factory. I am guessing if you >have the same client ids, you might see the behaviour you are seeing >where one subscription=B9s rollback/commit is affecting the other. > >Also I suggest enabling local transaction. It=B9s the =B3transacted=B2 opt= ion >on the activemq endpoint and the =B3sessionTransacted=B2 property on the >DMLC. Pretty sure I read somewhere camel uses a DMLC underneath the JMS >endpoint and according to the spring docs for DMLC, > >"It is strongly recommended to either set "sessionTransacted" to "true" >or specify an external =B3transactionManager"" > > >On 19 Jun 2014, at 12:17 am, Jeff Bischoff >wrote: > >> Same JVM, different connection factory. >> >> Do I need to explicitly set the clientId on each connectionFactory? >> >> This is what I have: >> >> >> > class=3D"org.apache.activemq.camel.component.ActiveMQComponent"> >> >> >> >> >> >class=3D"org.apache.activemq.ActiveMQConnectionFactory"> >> >> >> >> >> >> >> >> >> > class=3D"org.apache.activemq.ActiveMQConnectionFactory"> >> > >>value=3D"#{T(org.apache.commons.lang.StringEscapeUtils).unescapeXml('${ac= ti >>ve >> mq.brokerUrl}')}" /> >> >> >> >> >> > class=3D"org.springframework.jms.connection.CachingConnectionFactory" >> destroy-method=3D"destroy"> >> >> >> >> > alias=3D"topicConnectionFactory"/> >> >> >> >> Thanks, >> >> Jeff >> >> On 6/17/14 7:33 PM, "Minh Tran" wrote: >> >>> Is your non-camel subscriber running in the same JVM and using the same >>> connection factory with the same client id? >>> >>> On 18/06/2014, at 1:59 AM, Jeff Bischoff >>> wrote: >>> >>>> Not using a queue, just an AMQ topic. Was working fine before I >>>> introduced >>>> Camel, so I think I must be misconfiguring something in Camel. >>>> >>>> If I do everything works, but if I do , then my >>>> non-Camel subscriber never gets the message. It's almost as if my >>>>Camel >>>> consumer is not actually creating a subscription on the topic, but is >>>> instead stealing the message intended for my non-camel subscriber. >>>> >>>> Does it make sense that rollback would even work on this route? It >>>>isn't >>>> marked and the AMQConnector has no transaction manager >>>> defined! Yet rollback seems to work. >>>> >>>> >>>> >>>uri=3D"table-jms:topic:configuration.topic"/> >>>> >>> destinationType: ${header.DestinationEntityType}" >>>>loggingLevel=3D"INFO"/> >>>> loggingLevel=3D"INFO"/> >>>> >>>> >>>> >>>> ${header.DestinationEntityType} not in 'FOO,BAR' >>>> >>> ${header.Name} configuration.topic message on ${header.JMSDestination} >>>> for >>>> destination ${header.DestinationEntityType} with id: ${id}" >>>> loggingLevel=3D"INFO"/> >>>> >>> uri=3D"lc-jms:topic:configuration.topic?requestTimeout=3D0"/> >>>> >>> processed message with id: ${id}, destinationType: >>>> ${header.DestinationEntityType}" loggingLevel=3D"INFO"/> >>>> >>>> >>>> >>> ignoring >>>> message with id: ${id}, destinationType: >>>> ${header.DestinationEntityType}" >>>> loggingLevel=3D"INFO"/> >>>> >>>markRollbackOnly=3D"true" >>>> /> >>>> >>>> >>>> >>>> >>>> >>>> Results in: >>>> >>>> [topic-out] (Camel (camelContext) thread #9 - >>>> JmsConsumer[configuration.topic]) Picked up message with id: >>>> ID:TS-0007-jbischoff-2.local-50312-1403019963746-1:2:3:1:1, >>>> destinationType: TABLE >>>> >>>> [topic-out] (Camel (camelContext) thread #9 - >>>> JmsConsumer[configuration.topic]) (otherwise) ignoring message with >>>>id: >>>> ID:TS-0007-jbischoff-2.local-50312-1403019963746-1:2:3:1:1, >>>> destinationType: TABLE >>>> >>>> [EndpointMessageListener] (Camel (camelContext) thread #9 - >>>> JmsConsumer[configuration.topic]) Execution of JMS message listener >>>> failed. Caused by: [org.apache.camel.RuntimeCamelException - >>>> org.apache.camel.RollbackExchangeException: Intended rollback. >>>> Exchange[JmsMessage[JmsMessageID: >>>> ID:TS-0007-jbischoff-2.local-50312-1403019963746-1:2:3:1:1]]] >>>> >>>> >>>> >>>> Best, >>>> >>>> Jeff >>>> >>>> >>>> >>>> On 6/17/14 10:59 AM, "kraythe ." wrote: >>>> >>>>> A JMS topic will send a copy of each message to every topic. If not >>>>> then >>>>> the system violates basic JMS spec. If the system is a mainstream >>>>> system >>>>> like ActiveMQ, then that is not your problem. If you are trying to >>>>>use >>>>> a >>>>> queue as a topic it doesn't work that way. >>>>> >>>>> A queue is like throwing candy into the middle of a class of >>>>>elementary >>>>> kids. Each piece of candy will get consumed by only one kid but they >>>>> will >>>>> scramble for the pieces of candy as fast as they can. However, if a >>>>>kid >>>>> eats a piece of candy they can't regurgitate it and put it back into >>>>> the >>>>> pile. >>>>> >>>>> In your case if a route consumes a message on the queue, then it >>>>>can't >>>>> put >>>>> it back on the queue, the only way it gets back there is if the route >>>>> fails >>>>> and rolls back. >>>>> >>>>> Try adding a log line or a DLQ to the otherwise and see what happens. >>>>> And >>>>> don't rollback in the otherwise. If you are using a queue, create a >>>>> route >>>>> to sort the queue into 2 other queues based on the criteria and then >>>>> another route to process the queue where the relevant messages end >>>>>up. >>>>> i.e. >>>>> from(my >>>>> >>>>> >>>>>queue).choice().when(predicate).to("jms:queue:camel-processed-queue).o >>>>>th >>>>> er >>>>> wise().to("jms:queue:queue-processed-externally") >>>>> >>>>> >>>>> *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* >>>>> *Author of: Maintainable Java (Kindle >>>>> >>>>> >>>>>>>>>0A >>>>> KH >>>>> I69K>)(iTunes >>>>> >>>>> >>>>> >>>>>)* >>>>> *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 >>>>> * >>>>> >>>>> >>>>> On Tue, Jun 17, 2014 at 9:27 AM, Jeff Bischoff >>>>> >>>>> wrote: >>>>> >>>>>> Robert, thanks so much for replying. >>>>>> >>>>>>> Without that ack, the external system thinks it is not consumed and >>>>>>> in >>>>>>> good faith tries to redeliver. >>>>>> >>>>>> Okay, that seems like a good explanation for why I am getting >>>>>>external >>>>>> redeliveries! >>>>>> >>>>>> I guess the root of my problem is that it seems like my Camel >>>>>>consumer >>>>>> is >>>>>> competing with my non-Camel topic subscribers. To your question: >>>>>> >>>>>>> So the question you have to decide to solve your problem is, "What >>>>>>>is >>>>>> the >>>>>>> route I want my messages to take if they are not in the when >>>>>> condition. >>>>>>> Do >>>>>>> they end up in a dead letter queue? Routed elsewhere? Logged to a >>>>>> file? >>>>>>> But >>>>>>> they have to end up somewhere. >>>>>> >>>>>> I have non-Camel endpoints that will pick up the messages that don't >>>>>> meet >>>>>> the filter requirements. Ideally, I would have an "otherwise" that >>>>>> does >>>>>> nothing with the message (but does send the ack that it has been >>>>>> processed). These particular messages do not need to be routed by >>>>>> Camel >>>>>> in >>>>>> my system. >>>>>> >>>>>> However, it seems like Camel is competing with my non-Camel >>>>>>endpoints >>>>>> to >>>>>> consumer topic messages. I would have thought each subscriber (Camel >>>>>> and >>>>>> the other subscriber) would get their own copy of the topic message, >>>>>> and >>>>>> that they would not compete with each other. It seems like the >>>>>> non-Camel >>>>>> consumer can only process the message if I do a "rollback" in Camel. >>>>>> >>>>>> I'm building JUnit tests to try to figure out what I'm doing wrong, >>>>>> but >>>>>> any further insight would be greatly appreciated. >>>>>> >>>>>> >>>>>> Best, >>>>>> >>>>>> Jeff >>>>>> >>>>>> >>>>>> >>>>>> On 6/17/14 9:16 AM, "kraythe ." wrote: >>>>>> >>>>>>> Good suggestions but you will need to check the JMS server config >>>>>>>if >>>>>> you >>>>>>> are getting external redeliveries. Those happen when an external >>>>>> system to >>>>>>> the camel route performs a redelivery. >>>>>>> >>>>>>> As for your original route, there must always be a place for an >>>>>> exchange >>>>>>> to >>>>>>> go or it will stop routing. In the case of your when without >>>>>>> otherwise, >>>>>>> what would be the path of the exchange that fails the when >>>>>>>condition? >>>>>> It >>>>>>> is >>>>>>> probably returned to the external system in some manner and not >>>>>>>acked >>>>>> as >>>>>>> being delivered so it is sent again. Without that ack, the external >>>>>> system >>>>>>> thinks it is not consumed and in good faith tries to redeliver. >>>>>>> >>>>>>> Furthermore when you rollback, you are telling the host JMS system >>>>>>> that >>>>>>> you >>>>>>> did not consume the message, and it will try again of course. >>>>>>> >>>>>>> So the question you have to decide to solve your problem is, "What >>>>>>>is >>>>>> the >>>>>>> route I want my messages to take if they are not in the when >>>>>> condition. Do >>>>>>> they end up in a dead letter queue? Routed elsewhere? Logged to a >>>>>>> file? >>>>>>> But >>>>>>> they have to end up somewhere. >>>>>>> >>>>>>> *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* >>>>>>> *Author of: Hardcore Java (2003) and Maintainable Java (2012)* >>>>>>> *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 >>>>>>> * >>>>>>> >>>>>>> >>>>>>> On Mon, Jun 16, 2014 at 5:56 PM, Minh Tran >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>>> I have used topics in camel and they generally work the way I >>>>>>>>expect >>>>>> it. >>>>>>>> >>>>>>>> I would start by leaving the cache levels at the default and >>>>>> simplifying >>>>>>>> your route further. eg take out the choice and send it direct from >>>>>>>> topic to >>>>>>>> queue. Then add the choice but send it directly to the queue >>>>>>>>without >>>>>> the >>>>>>>> recipient list. Also enable tracing on the camel context so you >>>>>>>>can >>>>>> see >>>>>>>> what is happening to your message each step of the way. >>>>>>>> >>>>>>>> On 17/06/2014, at 6:28 AM, Jeff Bischoff >>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Does nobody use Topics with Camel? They don't seem to work as >>>>>>>> expected. >>>>>>>>> >>>>>>>>> JB >>>>>>>>> >>>>>>>>> On 5/30/14 10:48 AM, "Jeff Bischoff" >>>>>>>>> >>>>>>>> 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" >>>>>> >>>>>>>> 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 prevent the external redeliveries, but >>>>>>>> >>>>>>>>>>> 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" >>>>>> >>>>>>>> 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: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> "/> >>>>>>>>>>>> >>>>>>>>>>> destinationType: ${header.DestinationEntityType}" >>>>>>>> loggingLevel=3D"INFO"/> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ${header.DestinationEntityType} not in >>>>>>>>>>>> 'FOO,BAR' >>>>>>>>>>>> >>>>> topic >>>>>>>>>>>> message on ${header.JMSDestination} with id: ${id}, >>>>>>>> destinationType: >>>>>>>>>>>> ${header.DestinationEntityType}" loggingLevel=3D"INFO"/> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> lc-jms:${header.JMSDestination} >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 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. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> "/> >>>>>>>>>>>> >>>>>>>>>>> destinationType: ${header.DestinationEntityType}" >>>>>>>> loggingLevel=3D"INFO"/> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ${header.DestinationEntityType} not in >>>>>>>>>>>> 'FOO,BAR' >>>>>>>>>>>> >>>>> topic >>>>>>>>>>>> message on ${header.JMSDestination} with id: ${id}, >>>>>>>> destinationType: >>>>>>>>>>>> ${header.DestinationEntityType}" loggingLevel=3D"INFO"/> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> lc-jms:${header.JMSDestination} >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 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): >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> "/> >>>>>>>>>>>> >>>>>>>>>>> destinationType: ${header.DestinationEntityType}" >>>>>>>> loggingLevel=3D"INFO"/> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ${header.DestinationEntityType} not in >>>>>>>>>>>> 'FOO,BAR' >>>>>>>>>>>> >>>>> topic >>>>>>>>>>>> message on ${header.JMSDestination} with id: ${id}, >>>>>>>> destinationType: >>>>>>>>>>>> ${header.DestinationEntityType}" loggingLevel=3D"INFO"/> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> lc-jms:${header.JMSDestination} >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> But if I change that Rollback to a Stop instead, I get the >>>>>> endless >>>>>>>>>>>> external redeliveries again: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> "/> >>>>>>>>>>>> >>>>>>>>>>> destinationType: ${header.DestinationEntityType}" >>>>>>>> loggingLevel=3D"INFO"/> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ${header.DestinationEntityType} not in >>>>>>>>>>>> 'FOO,BAR' >>>>>>>>>>>> >>>>> topic >>>>>>>>>>>> message on ${header.JMSDestination} with id: ${id}, >>>>>>>> destinationType: >>>>>>>>>>>> ${header.DestinationEntityType}" loggingLevel=3D"INFO"/> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> lc-jms:${header.JMSDestination} >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 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: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>uri=3D"topic-jms:topic:projectx.>?durableSubscriptionName=3Dtestdur= asub >>>>>>>>"/ >>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> destinationType: ${header.DestinationEntityType}" >>>>>>>> loggingLevel=3D"INFO"/> >>>>>>>>>>>> >>>>>>>>>>>> ${header.DestinationEntityType} not in >>>>>>>>>>>> 'FOO,BAR' >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> lc-jms:${header.JMSDestination} >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 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. >>>>>>>> >>>>>>>> >>>>>> >>>>>> ________________________________ >>>>>> >>>>>> 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. >>>>>> >>>> >>>> ________________________________ >>>> >>>> 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. >>> >> >> ________________________________ >> >> 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. ________________________________ Please take note: This email, including attachments, contains information w= hich may be confidential or legally privileged and is only for the use of t= he individual or entity to whom it is properly addressed. Any unauthorized = review, use, disclosure, copying, or distribution is prohibited. If you hav= e 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.