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.
