In Web Server, acceptor threads on a listen socket accept connections and put them into a connection queue. Request processing threads in a thread pool then pick up connections from the queue and service the requests.
A request processing thread might also be instructed to send the request to a different thread pool for processing. For example, if the request processing thread must perform some work that is not thread-safe, it might be instructed to send part of the processing to the NativePool. Once the NativePool completes its work, it communicates the result to the request processing thread and the request processing thread continues processing the request.
At startup, the server only creates the number of threads defined in the thread pool minimum threads, by default 16. As the load increases, the server creates more threads. The policy for adding new threads is based on the connection queue state.
Each time a new connection is returned, the number of connections waiting in the queue (the backlog of connections) is compared to the number of request processing threads already created. If the number of connections waiting is greater than the number of threads, more threads are scheduled to be added the next time a request completes.
The process of adding new session threads is strictly limited by the maximum threads value. For more information on maximum threads, see Maximum Threads (Maximum Simultaneous Requests).
You can change the settings that affect the number and timeout of threads, processes, and connections in the Admin Console, on the configuration's Performance tab (HTTP settings), and on the HTTP listener. You can also use the wadm commands set-thread-pool-prop and set-http-listener-prop and set-keep-alive-prop.
The server can run in one of two modes, depending upon the load. It changes modes to accommodate the load most efficiently.
In low latency mode, for keep-alive connections, session threads themselves poll for new requests.
In high concurrency mode, after finishing the request, session threads give the connection to the keep-alive subsystem. In high concurrency mode, the keep-alive subsystem polls for new requests for all keep-alive connections.
When the server is started, it starts in low latency mode. When the load increases, the server moves to high concurrency mode. The decision to move from low latency mode to high concurrency mode and back again is made by the server, based on connection queue length, average total sessions, average idle sessions, and currently active and idle sessions.
If a thread pool is disabled, no threads are created in the pool, no connection queue is created, and no keep-alive threads are created. When the thread pool is disabled, the acceptor threads themselves process the request.
In addition to the settings discussed above, you can edit the following directives in the magnus.conf file to configure additional request-processing settings for NSAPI plug-ins:
KernelThreads – Determines whether NSAPI plug-ins always run on kernel-scheduled threads (Windows only)
TerminateTimeout – Determines the maximum amount of time to wait for NSAPI plug-ins to finish processing requests when the server is shut down
For detailed information about these directives, see the Sun Java System Web Server 7.0 Administrator’s Configuration File Reference.
For the safest way to edit configuration files such as magnus.conf, use the wadm commands get-config-file and set-config-file to pull a local copy for editing and push it back to the Web Server. For more information on these commands, see the help for these commands.