jcb
jcb

Reputation: 195

DefaultJmsListenerContainerFactory / DefaultMessageListenerContainer Dynamic Scaling: How does it work?

I am trying to get my Spring 4 JMS application to dynamically scale down after a lot of messages were processed. I currently have a concurrency of 1-3 consumers and I am able to see a successful scaling up toward the maximum consumers, but once the consumers have been created, they don't go away. They stay there in a WAIT state. I would like to know if there is a setting or configuration that enables the consumers to shutdown after the load subsides. Does anyone know?

Thanks,

Juan

Upvotes: 1

Views: 1103

Answers (1)

Artem Bilan
Artem Bilan

Reputation: 121282

Take a look to this option:

/**
 * Specify the limit for idle executions of a consumer task, not having
 * received any message within its execution. If this limit is reached,
 * the task will shut down and leave receiving to other executing tasks.
 * <p>The default is 1, closing idle resources early once a task didn't
 * receive a message. This applies to dynamic scheduling only; see the
 * {@link #setMaxConcurrentConsumers "maxConcurrentConsumers"} setting.
 * The minimum number of consumers
 * (see {@link #setConcurrentConsumers "concurrentConsumers"})
 * will be kept around until shutdown in any case.
 * <p>Within each task execution, a number of message reception attempts
 * (according to the "maxMessagesPerTask" setting) will each wait for an incoming
 * message (according to the "receiveTimeout" setting). If all of those receive
 * attempts in a given task return without a message, the task is considered
 * idle with respect to received messages. Such a task may still be rescheduled;
 * however, once it reached the specified "idleTaskExecutionLimit", it will
 * shut down (in case of dynamic scaling).
 * <p>Raise this limit if you encounter too frequent scaling up and down.
 * With this limit being higher, an idle consumer will be kept around longer,
 * avoiding the restart of a consumer once a new load of messages comes in.
 * Alternatively, specify a higher "maxMessagesPerTask" and/or "receiveTimeout" value,
 * which will also lead to idle consumers being kept around for a longer time
 * (while also increasing the average execution time of each scheduled task).
 * <p><b>This setting can be modified at runtime, for example through JMX.</b>
 * @see #setMaxMessagesPerTask
 * @see #setReceiveTimeout
 */
public void setIdleTaskExecutionLimit(int idleTaskExecutionLimit) {

Also you can study all other options of the DefaultMessageListenerContainer via their JavaDocs.

Upvotes: 1

Related Questions