camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ShlomiJ <shlomij...@gmail.com>
Subject Re: WireTap threads number keeps on growing
Date Tue, 13 Mar 2012 14:18:48 GMT

Claus Ibsen-2 wrote
> When you provide an existing thread pool to any Camel EIPs, such as
> the WireTap, then
> YOU are in control of the lifecycle of the thread pool. So you have to
> shutdown this thread pool yourself,
> when its no longer in-use.
I understand your point about the life cycle. But I have a problem with the
*executorServiceRef*.
I use executorServiceRef(WIRETAP_THREADPOOL), the thread pool (TP) is at the
registry, and I'm in control of its life cycle.
But actually each call to *wireTap creates its own TP*, NOT using the one
from the registry.

I would expect executorServiceRef to use the TP it is giving, not create a
new TP. It will also allow me to use the registry-key to get hold of the TP
and release it.


ShlomiJ wrote
> ThreadPoolBuilder tpBuilder = new ThreadPoolBuilder(this.context); 
> ExecutorService wiretapThreadpool =
> tpBuilder.poolSize(1).maxPoolSize(1).maxQueueSize(1).build("WireTap"); 
> registry.put(WIRETAP_THREADPOOL, wiretapThreadpool);
BTW, I also checked it with /registry.put(WIRETAP_THREADPOOL,
java.util.concurrentExecutors.newCachedThreadPool())/ (in case there was
something wrong with the way I used the ThreadPoolBuilder).

In anyway, in that particular place (many quartz-routes that are removed and
created again) I switch for using multicast.

thanks for the help
SJ

--
View this message in context: http://camel.465427.n5.nabble.com/WireTap-threads-number-keeps-on-growing-tp5557827p5561055.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Mime
View raw message