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
