WebObjects 4: Understanding Worker Threads and WOWorkerThreadCount

When a request arrives at the WebObjects application, the request data is held in a socket stream. In multi-threaded mode, the pool of worker threads is idle until a socket is queued, whereupon they wake up and one grabs the active socket. The worker thread reads a request from the active socket and creates a WORequest object. It then invokes the dispatchRequest method, which determines the appropriate request handler and invokes the handleRequest method on it. In single-threaded mode, of course, all of the above operations is done by one thread.

At this point, in protected multi-threaded mode, lockRequestHandling is called. This protects user code from the ambiguity problems inherent in multi-threaded environments. Bear in mind that if you override the dispatchRequest method to set some application variables before calling super's dispatchRequest method, those variables may get out of sync and cause undesirable side effects.

A worker thread processes an individual request and generates a response, via the usual takeValuesFromRequest, invokeAction and appendToResponse methods. It's worth pointing out that resource requests are handled without locking request handling, and therefore do not impact any TPM limits which may be imposed on you by your licence.

About WOWorkerThreadCount

The WOWorkerThreadCount setting controls the number of worker threads started by the default WebObjects adaptor, WODefaultAdaptor. By default, WOWorkerThreadCount is set to 8. What this means is that eight worker threads will be started when the application is launched. The adaptorsDispatchRequestsConcurrently method of WOApplication determines whether requests are processed concurrently or not. It also doubles as a flag to indicate single-threaded operation vs. multi-threaded operation. Remember that setting adaptorsDispatchRequestsConcurrently to true requires that the application be thread-safe.

Setting WOWorkerThreadCount to 0 will force your application to run in single-threaded mode. In this mode, a single thread is responsible for polling for new requests on the listen socket, running the main runloop (for timers, D.O. activity, etc.) and processing the requests that arrive and generating responses, as described above.

Performance Considerations

Finally, a few notes on the performance implications of threads in WebObjects 4:

• A static resource which doesn't require a request/response cycle, such as a JPEG image file, will be served directly by the Web server without involving any WebObjects worker threads. However, a WebObjects resource, such as a WOImage dynamic element representing a JPEG image, becomes part of the request/response loop and will be affected by WOWorkerThreadCount settings.
• Using WOWorkerThreadCount=0 only makes sense if your app is not at all multi-threaded. If your application is written in Java or uses NSThread elsewhere, you are better off using the default setting.
• Garbage collection runs differently in single-threaded mode than it does in multi-threaded mode. For more information on how multi-threaded garbage collection works, see article 70086.
• In multi-threaded mode, all socket I/O is multi-threaded.