camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <claus.ib...@gmail.com>
Subject [HEADS UP - About my latest commits]
Date Sat, 23 May 2009 07:32:51 GMT
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

Mime
View raw message