I've added dynamic thread pools to the JWS, using the
java.util.concurrentthread pool APIs. The way these APIs works is not necessarily intuitive, so let me explain a bit. Basically, there's a distinction made between threads (which actually execute tasks), and
Runnableobjects (which are the tasks to be executed). In the JWS, the main thread creates a
Runnableobject for each incoming connection. That object goes into a thread-safe queue (the task queue) and awaits a thread that will run it.
And this is where the thread pool comes in. The thread pool (
ThreadPoolExecutor) has N threads in it. Its job is to find an idle thread, pull a
Runnableobject from the task queue, and use the thread to execute the object's
run()method. The thread continues to execute
run()until it completes and exits. That object is then presumed to be completely processed, so it is thrown away. Also, the thread is idle again. So now the thread pool can recycle that thread to process the next object from the task queue. And so it goes.
Now, I chose to use a dynamic thread pool, which can also do things like noticing if there aren't enough threads to keep up with the objects coming in, and start up more. Or notice that there are way too many threads, and kill some of them. These are all variables you can control when you construct the
(Incidentally, I also used an
ArrayBlockingQueuefor the JWS's thread-safe task queue, because I wanted a hard upper bound on the number of incoming connections that could be queued before the JWS decided it was too busy and began rejecting new connections.)
( Which is all great, but I have some nitpicks about the thread pool APIs.Collapse )