After further reading it appears that as Camel's default message acknowledgement mode is 'auto' I would have to switch to 'transacted acknowledge mode' (use <transacted/> on the route).
Therefore am I correct in assuming that to in order to avoid 'losing' messages that I would have to implement XA transaction handling as there are effectively two resources that need to be orchestrated, namely the database and the broker? If not, why not? If true, what is the right choice of error handler for the client to use bearing in mind that I cannot turn on redelivery in the broker (therefore any message sent to a DLQ would just stay there)? Is there a simpler approach that I've overlooked? Thanks, Paul On Wed, Jan 15, 2014 at 4:06 AM, Claus Ibsen <claus.ib...@gmail.com> wrote: > On Tue, Jan 14, 2014 at 4:59 PM, Paul Gale <paul.n.g...@gmail.com> wrote: >> Hi, >> >> What is the recommended way to handle the following scenario. >> >> I intend to embed Camel in a client (a standalone Java process). The >> client receives messages from a queue on an ActiveMQ 5.8.0 broker. The >> client's processor is expected to save each message to a database >> (amongst other things). >> >> I need for my client's behavior to satisfy the following criteria: >> >> 1. If the database goes offline the client's error handling logic >> should retry the database save indefinitely. >> 2. The client should not send an ACK to the broker for a given message >> until it is saved in the database. >> 3. The client should not process subsequent messages until the >> processing of the current one is successful. >> 4. The implementation of the client's retry logic should not require >> the involvement of the broker from which the message came. >> >> Questions: >> >> 1. What is the correct pattern for implementing dead letter handling >> in the client (for handling database retries) so that all of the above >> criteria can be satisfied? >> > > Sounds like you only want the client to do dead letter handling / retry etc. > >> 2. What gotchas should I be aware of, if any? >> > > If I knew all the gotaches in the world I would be rich > >> 3. It is my understanding that Camel's dead letter handling is >> separate and distinct from that of ActiveMQ's even when the Camel >> context is running inside a broker. Is that correct? (Seems obvious >> but I thought I'd check.) >> > > Yes > > >> 4. Is the approach I am proposing to take flawed to the extent that >> some other approach must be taken? >> >> Thanks, >> Paul > > > > -- > Claus Ibsen > ----------------- > Red Hat, Inc. > Email: cib...@redhat.com > Twitter: davsclaus > Blog: http://davsclaus.com > Author of Camel in Action: http://www.manning.com/ibsen > Make your Camel applications look hawt, try: http://hawt.io
