camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Petter Nordlander <>
Subject CommonJ ThreadPoolFactory interface question
Date Tue, 01 Jan 2013 20:49:42 GMT

I am trying to do something I have neglected for some time now. That is to hook in a CommonJ
(WebSphere AS) thread pool for core camel features (JMS and Servlet stuff is working is just
fine but I like to have the async. core features in managed threads as well).

So I actually read up a bit on this one. I've been fiddling around with Mr Preben's tryout
( a bit. It looks pretty good although there is some
final touch needed.

However, in the new versions of Camel, the interface has changed from ExecutorServiceStrategy
to ExecutorServiceManager, so camel-commonj has to be "ported" to the new interface. When
starting, I realised that large portions of the code was shared with DefaultExecutorServiceStrategy
(even though Prebens class derives from the Deafult class, private declarations prevents reuse
to some extent). My approach is to try to do the implementation in the newer ThreadPoolFactory
interface rather than to rewrite the entire ExecutorServiceManager interface. Actually, this
is the documented approach.

newCachedThreadPool(ThreadFactory threadFactory)
newScheduledThreadPool(ThreadPoolProfile profile, ThreadFactory threadFactory)
newThreadPool(ThreadPoolProfile profile, ThreadFactory threadFactory)
Now to my question.

The agrument to these methods I need to implement is a ThreadFactory which essentially just
have one method "Thread newThread(Runnable r)". A look in the source reviels that what's actually
passed is an instance of a CamelThreadFactory configured with name, pattern and daemon flag.

public CamelThreadFactory(String pattern, String name, boolean daemon)

Those arguments is what I need to create the thread pool. I need to create the thread name,
but that is a later problem which is easier to solve). The information is there, but not in
any way reachable. If I could assume that only CamelThreadFactory was passed in this case
(which I can assume in the current code base, at least), then in theory I could use some reflection
hacking to get the private parameters, but that does not at all feel good.

So, has anyone actually used the ThreadPoolFactory to jack in Camel threads into a Java EE
thread pool/work manager before? Any hints how to come around the above "limits"?

Any help at all is appreciated.

Best Regards
Petter Nordlander

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message