Sun Microsystems Sun Java System Web Server 7.0, Manual

Page: 43 / 132

3. A different thread in
my-custom-pool
, called the B1 thread in this example, picks up the
request queued by A1. B1 completes the request and returns to the wait stage.
4. The A1 thread wakes up and continues processing the request. It executes the ObjectType
SAF and moves on to the Service function.
5. Because the Service function must be processed by a thread in
my-custom-pool2
, the A1
thread queues the request to
my-custom-pool2
.
6. A different thread in
my-custom-pool2
, called C1 in this example, picks up the queued
request. C1 completes the request and returns to the wait stage.
7. The A1 thread wakes up and continues processing the request.
In this example, three threads, A1, B1, and C1 work to complete the request.
Additional thread pools are a way to run thread-unsafe plug-ins. By defining a pool with a
maximum number of threads set to 1, only one request is allowed into the specified service
function. In the previous example, if
testmod_service
is not thread-safe, it must be executed
by a single thread. If you create a single thread in the
my-custom-pool2
, the SAF works in a
multi-threaded Web Server.
For more information on defining thread pools, see “thread-pool-init” in Sun Java System Web
Server 7.0 Update 1 Administrator’s Configuration File Reference .
The Native Thread Pool
On Windows, the native thread pool (NativePool) is used internally by the server to execute
NSAPI functions that require a native thread for execution.
Web Server uses Netscape Portable Runtime (NSPR), which is an underlying portability layer
providing access to the host OS services. This layer provides abstractions for threads that are
not always the same as those for the OS-provided threads. These non-native threads have lower
scheduling overhead, so their use improves performance. However, these threads are sensitive
to blocking calls to the OS, such as I/O calls. To make it easier to write NSAPI extensions that
can make use of blocking calls, the server keeps a pool of threads that safely support blocking
calls. These threads are usually native OS threads. During request processing, any NSAPI
function that is not marked as being safe for execution on a non-native thread is scheduled for
execution on one of the threads in the native thread pool.
If you have written your own NSAPI plug-ins such as
NameTrans
,
Service
, or
PathCheck
functions, these execute by default on a thread from the native thread pool. If your plug-in
makes use of the NSAPI functions for I/O exclusively or does not use the NSAPI I/O functions
at all, then it can execute on a non-native thread. For this to happen, the function must be
loaded with a
NativeThread=
"
no
"
option, indicating that it does not require a native thread.
For example, add the following to the
load-modules Init
line in the
magnus.conf
file:
Understanding Threads, Processes, and Connections
Chapter 2 • Tuning Sun Java System Web Server 43