Hi Claus,
sorry for getting back this is so late but I had to work on other
projects in the mean time.
2.9
Your ideas for camel 3.0 are rather small changes that can mostly be
done in 2.9.
> We could move ThreadPoolProfile from org.apache.camel.spi to
org.apache.camel and have it in the root package
As you wrote we can do this in 2.9. I will take care of it
> We could introduce a ThreadPoolProfileBuilder for support builder
style creation of profiles.
I already implemented this and will shortly commit. As this is a pure
addition it does not have to wait for 3.0
>The API for ExecutorServiceManagement could add support for creating
new thread pools based on a profile. Then people can use the builder
style to set the settings they want for the thread pool, and have the
ExecutorServiceManagement create the thread pool.
This already works using ExecutorService newThreadPool(Object
source, String name, ThreadPoolProfile profile);
Additionally I would like to centralize the logic for using default
profiles again. I had very nice logic in place that you rolled back. At
the moment this logic is spread over several places.
3.0
So I would rather like to discuss the more involved changes we could do
in 3.0. Of course implementation for this has to wait a bit but it is
important to start designing this now.
Some goals from my side:
- Have a common model for default thread pool profiles that works with
all dsl elements and components
- Keep the threading config out of the individual dsl elements and
components as far as possible or at least make it work in the same way
for all
- Keep the whole thread handling out of the processors and the compoents
as far as possible.
This is much more difficult than the previous step but could give
us a lot more advantages. We could try to introduce something like an
actor model so the implementations do not have to use an executorService
at all. Unfortunately I am not so experienced with this.
Christian
Am 13.08.2011 12:44, schrieb Claus Ibsen:
I took the liberty of adding some notes to the Camel 3.0 roadmap
https://cwiki.apache.org/confluence/display/CAMEL/Camel+3.0+-+Roadmap
See the section - Improvements to ThreadPoolProfile for thread management
In fact I think we could possible make a compromise with the changes
from Christian and the old/current API in the next Camel 2.9 release.
A minor API change IMHO could be to move the ThreadPoolProfile from
the spi package to the root package.
This is to empower its importance. Also its a class now, it used to be
an interface.
We can make it final and serializable as well.
I would be okay with this API change between 2.8 -> 2.9 as no Camel
components or 3rd party components were using them to create thread
pools and thus no really breakage here. The XML DSL will not be
affected as the factory beans in camel-core-xml can just be adjusted
accordingly.
However it could also be okay to leave it as is. But its a bit odd
since ThreadPoolProfile is now a class in the SPI package. SPI is
really only for interfaces, for 3rd party to plugin custom behavior.
As Christian noted a bit that the ThreadPoolBuilder should have been
named ThreadPoolProfileBuilder.
In fact why not introduced a new ThreadPoolProfileBuilder that only
creates profiles. And keep the existing ThreadPoolBuilder as is.
And then people can use this ThreadPoolProfileBuilder builder to
create profiles, which they can use the new ExecutorServiceManager to
create thread pools. Then people can pick and chose. And there is no
backwards compatibility issues as old and new API can co-exist.
Also as Christian noted he wanted the threads DSL to accept a
ThreadPoolProfile. We can add that to the fluent builder, so you can
do this from the Java DSL. (XML DSL can already support this using the
executorServiceRef).
So in Java DSL you can do
ThreadPoolProfile myProfile = ...
.threads(myProfile)
Will this help Christian?
--
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
