Hi Yeah you can configure the broker to move the message to a DLQ. Often the broker has a way of doing that. As the broker knows how many times a message has been redeliveried etc.
On the JMS spec / JMS message all Camel would know is that a message is redelivered or not, there is a only a boolean http://docs.oracle.com/javaee/6/api/javax/jms/Message.html#getJMSRedelivered() So sometimes you can find a counter also in the JMSX headers which is broker specific. So you may be able to grab the counter and handle the move to DLQ from Camel also. On Wed, Sep 10, 2014 at 8:47 AM, Jörn Gersdorf <[email protected]> wrote: > Hi camel experts, > > we have a problem with redeliveries/exception handling when an exception > occurs within the JPA commit/flush at transaction end. > > In a camel route we are using JMS on the receiving side and JPA on the sink > side. Transaction management is performed using JTA. > > <route id="myroute"> > <from uri="jms:input.queue"/> > <transacted /> > <to uri="bean:mybean?method=persist"/> > </route> > > Within the bean JPA is used to persist some objects. > > Now, in case we persist something which will lead to a Unique Constraint > Violation this will happen only at transaction commit time (maybe in the > JPA flush performed as part of that commit). This will lead to a rollback > both on JPA as well as on JMS side (which is okay and required). > > Now, JMS will try to redeliver the message, which will lead to a loop. > > How is this in general handled in the camel world? Is there a way - or is > the only way to configure our JMS provider to move failing messages finally > to a dead letter queue? > > Thank you. > > Kind regards, > Jörn -- Claus Ibsen ----------------- Red Hat, Inc. Email: [email protected] Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen hawtio: http://hawt.io/ fabric8: http://fabric8.io/
