Hi Try using a 2nd JMS component for sending. Then its separated from the 1st component.
On Sat, Oct 31, 2009 at 12:26 AM, jonathanq <[email protected]> wrote: > > I am having an issue with JMS queues and transactions. > > I have the following route: > > from("queue:incomingqueue") > .process(getSomeTranslationProcessor()) > .process(getMyPersistanceProcessor()) > .process(getSomeOtherTransformerProcessor()) > .to("queue:outgoingqueue"); > > The first and third processor just do some simple transformation on the > exchange. The middle processor (myPersistanceProcessor) is the key piece. > > It is a processor that sends part of the exchange to another queue and > requests a reply back. It uses a ProducerTemplate and looks like: > > Long recordDBId = (Long)producer.sendBody("queue:persistancequeue", > ExchangePattern.InOut, objectToPersist); > > It is a synchronous process - so the myPersistanceProcessor will wait for a > reply back before continuing. > > Now - the issue I have is this. If that InOut part of the route fails for > any reason (such as a time out, returns an error etc). I want to > essentially NOT acknowledge the message from the original incoming JMS queue > (meaning it will go back on the front of the queue). > > > I know that if you just do a "queue:incomingqueue?transacted=true" - it will > put the message back on the queue if the exchange failed. However If you > add "transacted=true" to the incoming queue in my route - it will never send > the message for the RequestReply part. > > Based on the documentation - that is because we must first commit the > transaction and then start another. However there is mention of the value > "transactedInOut=true" which seems to imply it will create a transaction > that wraps the WHOLE process (including the requestreply). > > In practice - using "transactedInOut=true" means that if the > producer.sendBody() timesout, it sends an eviction notice for that message - > but the original exchange does NOT get put back on the incoming queue. In > fact it disappears altogether. The Camel JMX bean does not record it as a > "Failed Exchange" - even through the log message says it was a failed > exchange. The exposed Camel JMX thinks it was a successful exchange. > > Is that how the "transactedInOut=true" is supposed to operate? Is there any > way to tell the incoming queue that we did NOT process the message and have > it put back there if it failed? Is there an error route that would put the > original message back on the queue? Or is that where using the: > > onException(Exception.class) > .maximumRedeliveries(-1) > > comes into play - as that will cause it to just be re-tried constantly? > > Thanks for any help you can offer! > -- > View this message in context: > http://old.nabble.com/JMS-Transactions-and-RequestReply---transactedInOut%3Dtrue-not-working--tp26138285p26138285.html > Sent from the Camel - Users mailing list archive at Nabble.com. > > -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
