Thanks Claus! Based on the requirements, I believe it's ok that seda is in-memory only (but this will be tested of course). There is an implicit persistence in the triggering mechanism that would survive a restart of the JVM if it were to fail during the route, and there are no real transactions or anything, it's a relatively simple ETL-style process that could just overwrite any partial results from a previous attempt.
I hadn't even considered doing anything with the route lifecycle for this situation, it seems like a very good option...thank you for the suggestions! Bob -----Original Message----- From: Claus Ibsen [mailto:claus.ib...@gmail.com] Sent: Thursday, July 17, 2014 3:07 AM To: users@camel.apache.org Subject: Re: blocking a route due to external conditions Hi Mind the seda queue is in-memory only. But you can suspend/stop the Camel routes that consumes for the seda endpoint. And then resume/start the route when its okay again. For that see the controlbus eip Or there is API on CamelContext and JMX operations as well to control the routes. Also there is route policy that allows you to hook code into a route, and control the lifecycle of the route. On Wed, Jul 16, 2014 at 5:56 PM, Robert Rich <rr...@gsti.net> wrote: > Hi folks, > > Just getting started with Camel and EIP/ESB/integration in general. > > I have several processes that include a shared portion that is not > thread-safe. Right now I have routes for each variant of the process that > consume its trigger (schedule, ad hoc, conditions, etc), build a message > indicating what type of process it is and then send it to a SEDA queue. I > have a single SEDA listener route that pulls those messages and executes the > shared non-thread-safe portion. > > This works well for me so far, but there are cases where the product I'm > integrating will kick off the non-thread safe process itself, outside of my > control. I can test for the presence of this process by looking for specific > job/status files and the process itself in the process list. I'm trying to > figure out the best way to halt the SEDA route processing in this scenario. > Options I've come up with are: > > - Implement a blocking processor in the SEDA route that just waits > until the process completes and then continues. The processor is on a > timer, and if the timer expires it throws an exception (or kills the > external process, which has a tendency to hang). I have this > implemented and it seems to work OK so far > - Immediately fail the route and just wait until I retry > - Test for the presence of the process before pulling the message from > the SEDA queue > - Ask you folks for a better idea > > Thanks! > > Bob -- 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 hawtio: http://hawt.io/ fabric8: http://fabric8.io/
