Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

Configuring the Component Thread Pools

From version 3.1, ServiceMix now uses separate and configurable thread pools for each component and flow, which allow much more tuning when needed.

...

Each thread pool has its own identifier, for example:

...

  • {{component.\[id\]}} where {{\[id\]}} is the name of the componentunmigrated-wiki-markup{{
  • flow.seda.\[id\]}} where {{\[id\]}} is the name of the component Wiki Markup{{
  • flow.jca.\[destination\]}} where {{\[destination\]}} is the name of the JMS destination used

Thread pools are configured hierarchically using these ids. It means that when an executor is created with an id of <code>foo.bar</code>, the factory will look for a configuration in the following way:

  • configs.get("foo.bar")
  • configs.get("foo")
  • defaultConfig

Examples

Following is an example configuration of the factory:

...

Note that maximumPoolSize and queueSize can be set to -1 to not bound these values.

Additional Information

The thread pools behavior is a function of how the ThreadPoolExecutor from the JavaSE works. When the ThreadPoolExecutor is configured by the ServiceMix ExecutorFactoryImpl.createService() method, it does so using the corePoolSize and the maximumPoolSize properties from the conf/servicemix.properties file. The ThreadPoolExecutor then uses the values set using those properties to influence how the size of the thread pool is adjusted at runtime. For more information, see the ThreadPoolExecutor's Javadoc.