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 is not thread-safe if processing the request requires interaction between a number of threads. A part of the request which is not thread-safe is transferred to a NativePool, which is a collection of threads which can interact with each other. The NativePool processes the request and communicates the request back to the request processing thread.
At startup, the server only creates the number of threads defined in the thread pool minimum threads, by default set to number of processors. 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 request is created, the number of requests waiting in the queue, often considered the backlog of connections, is compared to the number of request processing threads already created. If the number of requests is greater than the number of threads, more threads are created.
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 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:
For detailed information about these directives, see the Sun Java System Web Server 7.0 Update 3 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.