> From: Harshad Kamat [mailto:[email protected]]
> Subject: Tomcat Acceptor Thread goes into wait() to never come back -
> Tomcat 6.0
>
> I believe I've found a race condition in Tomcat that causes the http
> port to be non-responsive.
I believe you are correct. To close the timing window, the lock needs to
remain up across the call to createWorkerThread() and the test for null.
Something like this would work:
protected Worker getWorkerThread() {
Worker workerThread;
// Allocate a new worker thread
synchronized (workers) {
while ((workerThread = createWorkerThread()) == null) {
try {
workers.wait();
} catch (InterruptedException e) {
// Ignore
}
}
}
return workerThread;
}
While we're at it, the synchronized clause in createWorkerThread() can now be
eliminated, and the method simplified (and a lot of useless and confusing
parentheses removed):
protected Worker createWorkerThread() {
if (workers.size() > 0) {
curThreadsBusy++;
return workers.pop();
}
if (maxThreads < 0 || curThreads < maxThreads) {
curThreadsBusy++;
if (curThreadsBusy == maxThreads) {
log.info(sm.getString("endpoint.info.maxThreads",
Integer.toString(maxThreads), address,
Integer.toString(port)));
}
return newWorkerThread();
}
return null;
}
The two methods could be combined, but it would probably be uglier. One could
also fix the symptom by putting a time limit on the wait() call, but that
offends the sensibilities.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
