camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pontus Ullgren <>
Subject Re: Event Driven Use Case
Date Mon, 04 Feb 2013 09:18:29 GMT
Hello Rakesh,

I would as you describe use the claimcheck EIP however I would not
create a separate seda queue for each request.

Here is a break down how I would do it.

Route A:
0. Make what you do before the call
1. Serialize the exchange just before making the service call and save it in
DB with UUID as key and a "timeout" timestamp at which point the
request times out.
2. Make the call.

Route B:
1. Listens for responses
2.  Retrieve the saved exchange state(using UUID) and enrich it with
information from the response.
Also make sure to handle cases where the UUID is not in the database
(time outs).
3. Continue to process the exchange.

Route C:
1. Use a timer to scan the database for requests that has expired.
2. Clean up the expired entries.

// Pontus Ullgren

On Sat, Feb 2, 2013 at 9:12 AM, Rakesh Sharma
<> wrote:
> I am implementing a flow(route) using camel that requires interaction with
> multiple external systems via RestFul service calls. These service calls
> provide only an ACK back. The actual response is sent by external system by
> making another service call back to my application. My app is running in
> tomcat container on multiple machines fronted by a load balancer. The
> subsequent steps of my route are dependent on the response of the external
> service call. Having a load balancer complicates it further as external
> service response may not come to the same machine where the original service
> call was made from. I also need to timeout the exchange processing in case
> external service response does not come back within a specified time
> interval. I am thinking of using following strategy to solve this problem:
> 1. Break big route into multiple small routes. The last step of each small
> route will make the service call to the external system. Essentially, I will
> have as many routes as number of calls to external systems. The endpoint of
> every small route (other than the initial one) will be the service end-point
> where external service is going to come back with its response for the
> request that was sent by the last step of the previous route.
> 2. Serialize the exchange just before making the service call and save it in
> DB with UUID as key.
> 3. Create a consumer on SEDA endpoint "seda:{uuid}" with a timeout. It is
> being created only to track if external service provided a response back
> within the expected time interval.
> 4. Make the service call to external system with UUID as part of the
> request.
> 5. Retrieve the saved exchange state(using UUID) and remove the entry from
> DB as soon as external service responds(response has the same UUID that was
> passed with the request) back by invoking the next route endpoint. The route
> has the previous state(retrieved from DB) and response from the external
> system. It can proceed further now by merging the previous state and the
> external service response. We know that response did not come within
> expected interval if DB does not have an entry for the UUID extracted from
> the service response.
> 6. The SEDA consumer will timeout and will make a check if DB still has the
> entry. If entry exists we know that external service response has not come
> within the expected interval. The entry from DB will be removed.
> This is a very heavy traffic applications and I am not sure if I am doing it
> in right way. Any suggestion will be highly appreciated. Using messaging
> system is not an option due to many factors outside of my control.
> Thanks,
> Rakesh
> --
> View this message in context:
> Sent from the Camel - Users mailing list archive at

View raw message