Hi As you might have noticed I have been cut from the internet for the last 3 days. But now its all running again.
And as such I have worked offline with the camel codebase and as often I endavour into different paths and thus my list of changed files got rather big. So it can be a hassle to split and make sure each tiny changes in files belong to the correct changelist. So at the end I have commited 3 tickets in one go. I have created ticket: CAMEL-1638, 1639 and 1640 that covers the major parts of the commit So here is a short summary (also with general observations). ============================================= - Gert V. I managed to create the ExecutorService that is "submit order" ordered. So the code in MulticastProcessor is a bit easier as the parallel processing uses the same code, just a different executor service depending if streaming() is enabled or not. See the SubmitOrderedCompletionService class. - Threads created by Camel now uses the ExecutorServiceHelper to ensure consistent thread names. This was mostly already done. But please remember to use this helper when creating threads using ExecutorService. And please do not use TimerTask as its kinda @deprecated according to Brian Goetz a leading Java Concurrency specialists. See his book about this. AFAIR we dont have TimerTask anymore. And in Camel 2.1 we have on the roadmap for much easier configuration of thread pools in Camel. - AggragatorStrategy. It took me a bit with surprise that the first callback was not invoked. So it makes it painful for end users if they need to do some work on the exchange before its aggregated. Or for example if they need to sum up an amount based on figures from each new exchange being aggregated. So I changed it to be invoked also at first call. Eg if you aggregate 10 exchanges you get 10 callbacks. Before you only got 9 callbacks. This is still up for debate, see CAMEL-1638. PS: I am wondering if we could also add a feature to allow using a POJO as AggregationStrategy to avoid being dependent on Camel API. - OnCompletion handover. This is part on the work with the new async API in Camel. What it means with the handover is that when a route turns into async using the *async* DSL it hands over the onCompletion callbacks registered as well. So its the new async thread that actually invokes the onCompletion callbacks when its complete. This allows us for instance with the file component to only delete/move the files when the async thread is actually complete. And in case the async thread failed the file component will do a rollback. Without this handover the sync thread will do the on completion and thus the files is moved/deleted to early. We should also start migrating existing camel components that uses a strategy for commit/rollback work. I have also adjusted the idempotent consumer in Camel for this. But there might be other components that has this kind of strategy. Anyone remember any component? As a side note I am in doubt if we should also handover when you use the SEDA component. So when you route a message to a seda queue should the original thread or the new thread do the onCompletion work? Current it does *not* do that. I added a TODO in the SEDA component. Any thoughts? I guess that covers my latest commits. -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
