camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Rich <>
Subject RE: blocking a route due to external conditions
Date Thu, 17 Jul 2014 08:20:12 GMT
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!


-----Original Message-----
From: Claus Ibsen [] 
Sent: Thursday, July 17, 2014 3:07 AM
Subject: Re: blocking a route due to external conditions


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 <> 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.
Twitter: davsclaus
Author of Camel in Action:
View raw message