Tuning the Thread Pool

The Grizzly framework provides a thread pool from which threads are obtained to process a socket event. These thread pools can be configured for attributes such as, maximum queue size, minimum thread count, and maximum thread count.

Communications Server uses ServersThreadPool and ClientsThreadPool. The threads belonging to these thread pools can be identified in the server.log by looking for using the names, SipContainer-serversWorkerThread-sip_port–0 and SipContainer-clientssWorkerThread-sip_port–0.

You can use the following commands for these attributes.

asadmin set config.sip-service.request-processing.initial-thread-count=10

asadmin set config.sip-service.request-processing.thread-count=10

asadmin set config.sip-service.request-processing.thread-increment=10

Communications Server uses the different thread pools for client tasks and server tasks. You can use one thread pool for both server and client tasks by setting the sip.network.grizzly.useServerThreadPool system property to true.

The maximum number of requests that can be queued in the thread pool can be configured through the following property:

asadmin set config.sip-service.connection-pool queue-size-in-bytes=20

By default, this attribute is set a values less than 0, and the queue is unbounded. To control the number of requests in the queue, ensure that you set this property to a value greater than 0.

The org.jvnet.glassfish.comms.sip.timer.queues system property can be used to configure the number of timer queues. By default, only one timer queue is created. If the load is high, have more than one queue so that the timer load is distributed among them.