Page History

...

Currently Camel uses thread pools in camel-core in the following areas:

• DefaultComponent - Optional thread pool for components in need of such
• DefaultEndpoint - Optional thread pool for endpoints in need of such
• DefaultProducerTemplate - Used by the Async API of this template
• ScheduledPollConsumer - Needs a ScheduledExecutorService to schedule its tasks
• RecipientListDefinition - The Recipient List EIP pattern
• SplitDefinition - The Splitter EIP pattern
• ThreadsDefinition - The threads DSL
• ToDefinition - Used by the toAsync variation
• WireTapDefinition - The Wire Tap EIP pattern
• MulticastProcessor - The underlying thread pool
• OnCompletionProcessor - For sending async on completion routes
• SendAsyncProcessor - The toAsync processor variation
• ThreadsProcessor - The underlying thread pool
• WireTapProcessor - For sending async wire taps
• SedaConsumer - To support the concurrentConsumers and multipleConsumers options (uses separate pools)

Existing configuration

You can configure the thread pool using the setExecutorService setter methods that usually exists on those places where its in use. Some EIP patterns offer a executorServiceRef option to refer to some pool to be looked up in the Registry.

...

Where it will match against route first, so if we got a route3 then it will pick among those
It should be possible to use wildcard and reg exp in the route and source attributes.

Status: Consider for the future

Default thread pool profile

It should be possible to set a default ThreadPoolProfile which Camel will use when creating thread pools for the EIPs and whatnot. Then you can set default settings and have that leveraged out of the box.

<threadPoolProfile id="myDefaultProfile"
                           defaultProfile="true"
                           poolSize="5" keepAliveTime="25" maxPoolSize="15" maxQueueSize="250" rejectedPolicy="Abort"/>

If none defined, then Camel should use a sensible default of

• poolSize = 10
• maxPoolSize = 20
• keepAliveTime = 60 seconds
• maxQueueSize = 1000
• rejectedPolicy = CallerRuns

And it should validate that only one defaultProfile=true can be set.

Status: DONE

The problem with shutdown and restarting pools

...

Check whether the thread pools is managed by default and avail in JConsole. If not we should probably at least expose some read-only data about the pools. DONE

Spring Factory for creating custom pools

...

Using the DefaultExecutorServiceStrategy we can let Camel keep track of the created pools, and thus also it can shutdown those when CamelContext is shutting down. Then Camel is handling the lifecycle for the pools it creates. And if you pass in a thread pool from an external system then you manage that lifecycle. Camel will in those cases not shut it down. IN PROGRESS DONE

Sensible defaults

The CachedExecutorService by the JDK is maybe a bit aggressive as its unbounded thread pool which essentially can create 1000s of threads if the sever is not busy. But end users may want to have a reasonable max size, lets say 100. So we should offer some sort of rule which you can configure what the default settings should be for thread pools created by Camel. DONE

Rejection policy

We should add configuration about rejection policies for new tasks submitted to a pool. The JDK has options for ABORT, RUN, WAIT, DISCARD etc. DONE