anchor.diff:  [[ThreadingModel-ThreadingModel]]
   = Threading Model
   
  -*Since Camel 2.3*
  -
  -The threading model in Camel is based on leveraging the JDK concurrency
  -API which provides thread pools, named `ExecutorService`.
  -
  -Camel leverages thread pools in the following places:
  +The threading model in Camel is based on a pluggable reactive routing engine,
  +and thread pools from the JDK concurrency API.
  +
  +This page focuses on thread pools.
  +Camel leverages thread pools in several places such as:
   
   * several xref:{eip-vc}:eips:enterprise-integration-patterns.adoc[EIP] patterns supports using thread pools for
   concurrency
   * xref:components::seda-component.adoc[SEDA] component for asynchronous connectivity
  -* xref:async.adoc[Threads DSL] in the Camel route
  -* And some component provide thread pools by nature such as
  -xref:components::jms-component.adoc[JMS], xref:components::jetty-component.adoc[Jetty]
  -
  -[[ThreadingModel-Threadpoolprofiles]]
  +* xref:{eip-vc}:eips:threads-eip.adoc[Threads] EIP in Camel routes
  +* Some components use thread pools out of the box, such as
  +xref:components::jms-component.adoc[JMS] or xref:components::jetty-component.adoc[Jetty]
  +
   == Thread pool profiles
   
  -By default when a thread pool is to be created then its based on the
  -default thread pool profile which is:
  -
  -[source,xml]
  ---------------------------------------------------------------------------------------------------------
  -    <threadPoolProfile id="defaultThreadPoolProfile" defaultProfile="true"
  -                       poolSize="10" maxPoolSize="20" maxQueueSize="1000" allowCoreThreadTimeOut="true"
  -                       rejectedPolicy="CallerRuns"/>
  ---------------------------------------------------------------------------------------------------------
  -
  -NOTE: From Camel 3.4 onwards the default thread pool profile has `allowCoreThreadTimeOut=true` while
  -it was `allowCoreThreadTimeOut=false` in older Camel versions.
  +By default, when a thread pool is to be created by Camel, then the pool configuration
  +is based upon a profile, the _default thread pool profile_
  +
  +The default profile is pre-configured out of the box with the following settings:
  +
  +[width="100%",cols="25%,25%,50%",options="header",]
  +|===
  +| Option | Default | Description
  +| *poolSize* | `10` | Sets the default core pool size (threads to keep minimum in pool)
  +| *keepAliveTime* | `60` | Sets the default keep alive time (in seconds) for inactive threads
  +| *maxPoolSize* | `20` | Sets the default maximum pool size
  +| *maxQueueSize* | `1000` | Sets the default maximum number of tasks in the work queue. Use -1 for an unbounded queue.
  +| *allowCoreThreadTimeOut* | `true` | Sets default whether to allow core threads to timeout
  +| *rejectedPolicy* | `CallerRuns` | Sets the default handler for tasks which cannot be executed by the thread pool. Has four options:
  +`Abort, CallerRuns, Discard, DiscardOldest` which corresponds to the same four options provided out of the box in the JDK.
  +|===
   
   What that means is that for example when you use
   xref:{eip-vc}:eips:multicast-eip.adoc[Multicast] with `parallelProcessing=true` enabled,
  -then it would create a thread pool based on the profile above. The
  -`rejectedPolicy` has four options:
  -`Abort, CallerRuns, Discard, DiscardOldest` which corresponds to the
  -same four options provided out of the box in the JDK.
  -*Notice:* option allowCoreThreadTimeOut is a new option from *Camel
  -2.15* onwards.
  +then it would create a thread pool based on the profile above.
   
   You can define as many thread pool profiles as you like. But there must
   only *one* default profile. A custom thread pool profile will inherit
  
positive.code: explicit define will fallback and use the option from the default
  profile.
  
  You can use `-1` in maxQueueSize to indicate a unbounded queue.
  
  In Java DSL you can configure the default thread pool profile from the
  `ExecutorServiceStrategy`/`ExecutorServiceManager` which you access from
  `CamelContext`.
  
  [[ThreadingModel-Usingthreadpoolprofiles]]
  == Using thread pool profiles
  
  Suppose you want to use a custom thread pool profile for a Multicast EIP
  pattern in a Camel route you can do it using the `executorServiceRef`
  attribute as shown:
  
  [source,xml]
  ---------------------------------------------------------------------------
  <camelContext ...>
      ...
      <threadPoolProfile id="fooProfile" 
                         poolSize="20" maxPoolSize="50" maxQueueSize="-1"/>
      ...
  
      <route>
         ...
         <multicast strategyRef="myStrategy" executorServiceRef="fooProfile">
            ...
         </multicast>
        ...
      <route>
  </camelContext>
  ---------------------------------------------------------------------------
  
  What Camel will do at runtime is to lookup in the
  xref:registry.adoc[Registry] for a `ExecutorService` with the id =
  fooProfile. If none found it will fallback and see if there is a
  `ThreadPoolProfile` defined with that id. And in this example there is
  and so the profile is used for creating a new `ExecutorService` which is
  handed back to the xref:{eip-vc}:eips:multicast-eip.adoc[Multicast] EIP to use in the
  route.
  
  [[ThreadingModel-Createcustomthreadpool]]
  == Create custom thread pool
  
  You can also use the <threadPool/> tag in Spring XML to create a
  specific thread pool (eg `ExecutorService`). Notice that any options you
  do not explicit define, will have Camel to use the default thread pool
  profile as fallback. For example if you omit setting the `maxQueueSize`
  then Camel will fallback and use the value from the default thread pool
  profiles, which by default is 1000.
  
  [[ThreadingModel-Management]]
  == Management
  
  All the thread pools that Camel creates are managed and thus you can see
  them in JConsole under the `threadpools` category.
  
  [[ThreadingModel-ExecutorServiceStrategy]]
  == ExecutorServiceStrategy
  
  *Since Camel 2.3 to 2.8.x* +
   Camel provides a pluggable strategy to hook in your own thread pool
  provider, for example from a WorkManager in a J2EE server etc. +
   See the `org.apache.camel.spi.ExecutorServiceStrategy` interface which
  you should implement and hook into the WorkManager.
  
  See
  xref:advanced-configuration-of-camelcontext-using-spring.adoc[Advanced
  configuration of CamelContext using Spring] for how to configure it.
  
  You can configure it on the `CamelContext` from Java DSL using the
  getter/setter.
  
  [[ThreadingModel-ExecutorServiceManager]]
  == ExecutorServiceManager
  
  *Since Camel 2.9*
  
  In camel 2.9.0 the `ExecutorServiceManager` replaces the
  `ExecutorServiceStrategy`. It is renamed to manager as is not only
  provides a strategy for thread pool creation but also keeps track of
  thread pools and thread pool profiles.
  
  To hook in custom thread pool providers (e.g. for J2EE servers) a
  `ThreadPoolFactory` interface can be implemented. The implementation can
  be set in the `ExecutorServiceManager`. The Factory interface is much
  simpler then the former `ExecutorServiceStrategy` and makes the job of
  integrators much easier.
  
  See
  xref:advanced-configuration-of-camelcontext-using-spring.adoc[Advanced
  configuration of CamelContext using Spring] for how to configure it.
  
  [[ThreadingModel-Customizingthreadnames]]
  == Customizing thread names
  
  On the `ExecutorServiceStrategy`/`ExecutorServiceManager` you can
  configure the thread name pattern using the `setThreadNamePattern`
  method, which defines the thread names used when a thread pool creates a
  thread.
  
  The default pattern is for:
  
  * *Camel 2.9.x or older:*
  `Camel ($\{camelId}) thread #$\{counter} - $\{name}`
  * *Camel 2.10 onwards:* `Camel (#camelId#) thread ##counter# - #name#`
  
  Notice we renamed the tokens from Camel 2.10 onwards to not clash with
  tokens by the xref:using-propertyplaceholder.adoc[Property Placeholder].
  
  In the pattern you can use the following placeholders
  
  * $\{camelId} *Camel 2.6:* is the xref:camelcontext.adoc[CamelContext]
  name
  * $\{counter} is a unique incrementing counter.
  * $\{name} is the regular thread name.
  * $\{longName} is the long thread name which can includes endpoint
  parameters etc.
  
  Notice the pattern name has changed from Camel 2.10 onwards, use #name#
  instead.
  
  In Camel 2.11 onwards its easier to set the thread name pattern on the
  CamelContext using the threadNamePattern attribute in the XML files as
  shown below:
  
  [source,xml]
  --------------------------------------------------------------------------------------------------------------
    <camelContext xmlns="http://camel.apache.org/schema/spring" threadNamePattern="Riding the thread #counter#">
      <route>
        <from uri="seda:start"/>
        <to uri="log:result"/>
        <to uri="mock:result"/>
      </route>
    </camelContext>
  --------------------------------------------------------------------------------------------------------------
  
  [[ThreadingModel-Componentdevelopers]]
  == Component developers
  
  If you develop your own Camel component and are in need of a thread
  
negative.code: `ExecutorServiceStrategy`/`ExecutorServiceManager` to create the thread
  pool you need.
  
  === ExecutorServiceStrategy
  
  Camel provides a pluggable strategy to hook in your own thread pool
  provider, for example from a WorkManager in a J2EE server etc. +
  See the `org.apache.camel.spi.ExecutorServiceStrategy` interface which
  you should implement and hook into the WorkManager.
  
  === ExecutorServiceManager
  
  To hook in custom thread pool providers (e.g. for J2EE servers) a
  `ThreadPoolFactory` interface can be implemented. The implementation can
  be set in the `ExecutorServiceManager`.
  