Yes, that is correct and actually in my case that "may" be what I want to have happen (i.e. the message gets put back onto queue A). However yesterday I did some digging into the onException clause and I'm finding it very useful. For example, if when "something bad happens" an exception is thrown, I can essentially catch that exception in Spring DSL and if it is a specific exception that I an looking for then I can decide what to do with the message. I can put it onto the deadletter queue, perhaps in the case of an argument exception, or I can stick it back onto the queue and have the route utilize my redelivery policy, especially if the exception was a connectivity issue with the cxfrs endpoint that I am trying to route the message to.
Putting the message onto the DLQ move "poison pills" out of the way for the good messages to be routed to the cxfrs endpoint thus allowing message to flow through the route again. Seems to work pretty well. The issue I have now is that my cxfrs endpoint is a .NET restful service and if I throw a .NET exception from the service, it does not get translated to an equivalent java exception. Makes sense because I'm not sure that there would be a simple translation, but it does make it more difficult to determine which exceptions I want to look for a then route to the DLQ. Not sure if that helps you, but it seems to be a possible approach for me. -- View this message in context: http://camel.465427.n5.nabble.com/Transacted-vs-DeadLetterQueue-tp5713992p5714128.html Sent from the Camel - Users mailing list archive at Nabble.com.
