"run id" & other data 4 a given route invocation - OR- required route steps

[unwired]

Hi,

We have been contemplating ways to address a requirement we have, and are trying to decide on the best solution. This seems like something virtually everyone would need to do, so thought we'd see what the best proposed solution is.

Our requirement is that for every invocation of a route, we need to track a number of "metadata" about the route invocation, such as the start time, the complete time, and some additional details that are specific to each bundle that determine whether or not the invocation of the route was "successful".  This data would be tracked against a unique identifier (e.g. run_id) which would track this information for each instance and allow us to historically track the success (or not success:) of every invocation.

For a hypotherical example, let's say a bundle is on a timer every 5 hours. We might log to the db:

run_id: 5
bundle_id: 10
start_time: 2010-08-24 17:00:00
end_time: 2010-08-24 17:07:17
count_of_records_processed:5715
count_of_exceptions:17

The problem we are having is that to my knowledge there's no inherent "state" for a given route invocation.  Currently each of our routes has a "begin" and an "end" step that we have it go through that logs the start and end time. However, this is clearly not safe for asynchronous processing if multiple route invocations are occurring at the same time as with our current solution the next invocation would over-write the last start time or at a minimal we would have two (or more) start times without end times set and it would not be clear which to "end" at the end of the route if they operate asynchronously. We've known we had an issue with this for a while.

Further, I don't really want to have "cookie-cutter" code that every route has to include. 

We've considered addressing this by passing through a header with the "run id" so that each invocation knows the run id PLUS have a "mandatory" step of the route that always gets executed (addresses the cookie-cutter issue) - but not sure if this is even possible.

The problem with this is that it requires us to pass the run id throughout the route, and also requires us to have the Exchange in our signature for various route steps so that we can "pass on" the "run id" - or the unique identifier for the particular instance of the route run.  However, we are trying to avoid camel-specific references in our code by using  bean binding, so this is not ideal.

I've also had a quick squiz of the "Interceptor" and it seems like it might be able to help us out but I haven't seen any examples doing what we are trying...

Does anyone have some alternative solutions to this?  Perhaps thinking out of the box we can address this in a completely different manner; because it seems like such a common reqt perhaps there is a way to track each invocation we are not aware of?

thanks much for any thoughts.

Edited by: unwired on Aug 24, 2010 8:12 AM

[davsclaus]

You can store stuff on the Exchange as properties. Then you can just store the run id, start time, end time etc. The data will then be per Exchange specific.

[unwired]

Hi,

Thanks for the feedback but that's not really what we're after because

a) it requires us to use an exchange whereas we prefer bean binding so that we don't have to deal with camel specific classes and

b) we're not looking for tracking about the exchange but rather the entire route which might and often does consist of multiple exchanges.

If anyone has any ideas about how to uniquely track data about the entire route that'd be great - or if I've lost the plot and you can do this with the  Exchange (preferably without having to deal directly with the exchange) then please let me know.

thanks!

[davsclaus]

You can use the @Properties Map props for bean binding.

[unwired]

Great thanks for that I'll investigate the Properties annotation but we still have the bigger hurdle of tracking the entire route versus only individual exchanges.  If you have any ideas around that they'd be much appreciated.

thanks much