Claus to the rescue ;) While waiting for the fix Enalposi maybe you can try a slightly uglier wiretap to do the processing or something similar. This will keep the request/response cycle theoretically low.
On Thu, Jul 7, 2011 at 11:10 AM, Claus Ibsen <claus.ib...@gmail.com> wrote: > The JmsConsumer will wait for the Exchange to complete. > > There is a ticket to improve this by supporting the async routing > engine on the consumer level for InOnly JMS consumers. > https://issues.apache.org/jira/browse/CAMEL-3632 > > On Thu, Jul 7, 2011 at 6:01 PM, enalposi <enalp...@yahoo.com> wrote: > > Hi Tim - > > > > Using Camel 2.7.2. > > I actually had the ExchangePattern before threads() originally - the > above > > is just one permutation of several I tried (just moved it back - same > > result). > > Yes, I guess it should block if the 'consumer'/publisher is expecting a > > response. But it's using OutOnly ExchangePattern. Additionally I set > > disableReplyTo=true which Claus pointed out in some other post to really > > make this one-directional. > > > > Regarding ack - shouldn't in this configuration the ack be returned by > the > > jms consumer thread, before handing it over to the worker thread pool? > From > > what I read it defaults to AUTO_ACKNOWLEDGE. I opened up both Camel and > > Spring with DEBUG log level but see nothing related. On the Camel API > side I > > am not sure how to get a handle on anything to acknowledge given the > > transport agnostic level of abstraction if I wanted to try out > CLIENT_ACK. > > > > Cheers. > > > > -- > > View this message in context: > http://camel.465427.n5.nabble.com/Each-concurrentConsumer-on-JMS-Topic-receives-ALL-msgs-tp4558687p4561538.html > > Sent from the Camel - Users mailing list archive at Nabble.com. > > > > > > -- > Claus Ibsen > ----------------- > FuseSource > Email: cib...@fusesource.com > Web: http://fusesource.com > Twitter: davsclaus, fusenews > Blog: http://davsclaus.blogspot.com/ > Author of Camel in Action: http://www.manning.com/ibsen/ >
