Hi I am posting this to user so Camel end users have a chance to make an impact on this matter.
I am working on making configuring thread pools in Camel much easier. https://issues.apache.org/activemq/browse/CAMEL-1588 In light of this work we are introducing a ThreadPoolProfile which contains settings to be used when a thread pool is to be created. The idea currently is that there is a *default* profile that is used normally, and its has the following options private Integer poolSize = 10; private Integer maxPoolSize = 20; private Long keepAliveTime = 60L; private TimeUnit timeUnit = TimeUnit.SECONDS; private Integer maxQueueSize = 1000; private ThreadPoolRejectedPolicy rejectedPolicy; And the rejectedPolicy will default to use: CallerRuns. There are 4 options: Abort, CallerRuns, DiscardOldest, Discard; I am currently wondering if these default settings is matching what you would expect / like to be default in Camel 2.3 onwards. How this works in Java is that the thread pool will have as min 10 threads in the pool and a worker queue with a 1000 capacity. And only when its exhausted, eg the capacity has been hit, it will grow the pool up till 20 threads to help. And if threads is idle for more than 60 seconds it will be terminated. There are two options which I may want to adjust change - maxQueueSize = 1000 - rejectedPolicy = CallerRuns Is the default capacity of 1000 to high? For example having 100, will let the thread pool to grow sooner to help out. Or is 100 to low. Also mind that the task queue is in memory so if the server crashes those tasks are gone. And the rejectedPolicy with CallerRuns allows to let the caller thread execute the task instead of handing it over to the thread pool. This is like a last resort if the thread pool is really exhausted and otherwise would have to either abort or discard a task. However the good point is that by doing this its automatically throttling the caller as it cannot at the same time send new tasks to the thread pool. We could also add a new option: Wait. Which lets the caller wait a bit to see if the task queue has room to handover the task. But when waiting you have to cater for timeout to avoid potentially waiting for a long time. And this requires custom code to write, as the existing 4 options is provided out of the box from JDK. So when are these thread pools being used? - EIPs (splitter, aggregator, multicast, wiretap etc. etc.) - ProducerTemplate having a cached pool of Producer - Threads DSL - toAsync DSL The various components may have their own thread pool, such as Jetty, Mina, Spring JMS etc. Any thoughts? -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
