Bounded ThreadPool


Added by Jan Bartel, last edited by Christian d'Heureuse on Apr 19, 2007  (view change)

Labels

 
(None)
Contact the core Jetty developers at www.webtide.com
private support for your internal/customer projects ... custom extensions and distributions ... versioned snapshots for indefinite support ... scalability guidance for your apps and Ajax/Comet projects ... development services from 1 day to full product delivery

Thread Pools

A thread pool ensures threads are used efficiently within the container. A number of threads are created at initialization and placed in the pool. When there is work to be done, for example to service a request, a free thread from the pool is allocated and then returned to the pool when the work has been completed.

Bounded Thread Pool

The thread pool implementation availabile in Jetty is called org.mortbay.thread.BoundedThreadPool. It is called "Bounded" because it manages the size of the thread pool based on configurable minimum and maximum numbers of threads.

If there are no free threads when one is required, a new thread will be created and placed in the pool if the maximum pool size has not been reached. If the maximum pool size is reached, jobs wait for a free thread. Idle threads in the pool will timeout and terminate until the minimum number of threads are running.

It is configured like so:

<Set name="ThreadPool">
 <New class="org.mortbay.thread.BoundedThreadPool">
  <Set name="minThreads">10</Set>
  <Set name="maxThreads">100</Set>
 </New>
</Set>

where:

  • minThreads is the minimum number of threads allowed in the pool
  • maxThreads is the maximum number of threads allowed in the pool

Change the minimum and maximum threads in accordance with the load profile of your installation.

Comments (1)

 

  1. Mar 13, 2007

    Anatoliy Salistra says:

    BoundedThreadPool has a problem when set as a specific pool of a SocketConnector...

    BoundedThreadPool has a problem when set as a specific pool of a SocketConnector. Namely, it takes  a very long to stop the server. The SocketConnector is programmed to stop the pool before it close its acceptor ServerSocket. As a programming pattern it is correct: first stop the components, then the container. However in this particular case the acceptor thread is created by the pool too - and simple Thread.interrupt() will be ignored by ServerSocket.accept(). The pool will then wait for the acceptor thread to die which can never happen until the socket is closed. Eventually the thread pool gives up, but it takes 8 something minutes per connector. Clearly some hack is needed here to close the socket.