Executor Configuration

Executor Configuration

Dempsy allows fine tuning of the number of threads that are used for processing. These threads apply to all processing taking place inside the message processor including message handling and output processing.

Note: In 0.7.2 the output processing has it's own executor with it's own threads. The intention is to eventually use the same DempsyExecutor instance for both. The documentation here assumes that.

The default is based on the number of cores available on the machine. Often the default will not be appropriate. If the MP is I/O intensive, or the message sizes are large and therefore create an I/O bottleneck in the framework, it could be advantageous to explicitly set or tune the thread pool size.

By default the thread pool is set using the following formula:

number of threads = m * number of cores + additional threads

m defaults to 1.25 and additional threads defaults to 2.

Configuring the Thread Pool

You can set the number of threads through one of two alternative methods. The relative (to the number of cores) method is by setting m and additional threads. The absolute method is to simply supply the number of threads directly.

Relative configuration

The setting can be configured at either the ApplictionDefinition level, or the ClusterDefinition level. When set at the ApplicationDefinition level it applies to all ClusterDefinitions in the application.

        <property name="executor">
            <bean class="com.nokia.dempsy.executor.DefaultDempsyExecutor">
                <property name="additionalThreads" value="45"/>
                <property name="coresFactor" value="2.0"/>
            </bean>
        </property>

The above results in setting the number of threads to 2 * number of cores + 45 so if, for example, the number of cores is 8, the total number of threads will be 71.

Absolute Configuration

Alternatively you can simply set the number of threads on the executor directly. Again, the setting can be configured at either the ApplictionDefinition level, or the ClusterDefinition level. When set at the ApplicationDefinition level it applies to all ClusterDefinitions in the application.

In the following example we set the number of threads to 45:

        <property name="executor">
            <bean class="com.nokia.dempsy.executor.DefaultDempsyExecutor">
                <constructor-arg value="45"/>
                <constructor-arg value="-1"/>
            </bean>
        </property>

Note: the second constructor argument is the maxNumberOfQueuedLimitedTasks discussed below.

Message Queue Limits

The Executor is also the place where processing queue limits are handled. For example, if the node is getting behind and there are too many tasks queued up to execute, then the Executor will handle the shedding of messages.

When messages come into a node they are queued for delivery to the appropriate message processors but by default there are limits set. When the limits are exceeded the oldest queued messages are discarded, and all of the appropriate monitoring bookeeping is done.

By default the limit is derived from the number of threads and is currently set to 20 * thread pool size. This can be explicitly set using either:

1. The second constructor parameter
2. The maxNumberOfQueuedLimitedTasks property on the DefaultDempsyExecutor.

If this value is set to '< 0' (it's set to -1 in the above constructor arg. example) then the formula will be used to calculate the value.

Blocking and Unbounded Queueing

It may be advantageous in certain testing situations to force the message processor message handling to either block on message submission, or set the limiting queue to unbounded. It is not recommended that either option be used in a production scenario for what should be obvious reasons.

If blocking is set to true then submitting message processing tasks, once the maxNumWaitingLimitedTasks is reached, will block until room is available. This will create back pressure on the transport.

To set blocking use:

                <property name="blocking" value="true"/>

Setting unlimited to true allows for an unbounded queue to handle message processing. This instructs the DefaultDempsyExecutor to effectively ignore the maxNumWaitingLimitedTasks setting. The default behavior is for the oldest message processing tasks to be rejected when the maxNumWaitingLimitedTasks is reached.

Setting unlimited effectively causes the Executor to ignore the blocking setting.

To set the DefaultDempsyExecutor to unlimited use:

                <property name="unlimited" value="true"/>

Next Section: [Message Routing and Microsharding](Message Routing and Microsharding)