Does onException() happen within the transaction too? If so then your rollback will rollback your DLC put also. On Jun 7, 2012 9:18 AM, "gramanero" <graman...@gmail.com> wrote:
> 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. >
