https://issues.apache.org/bugzilla/show_bug.cgi?id=51240
--- Comment #3 from Tim Whittington <t...@apache.org> 2011-05-25 10:37:48 UTC
---
It looks like there's a race condition between the acceptor thread being
permitted to accept a connection and updating the connection counter.
Two acceptor threads can pass the awaitConnection() condition, accept a
connection, and then both call countUp(). The connection count then goes above
the signal level and awaitConnection() blocking condition will never be met as
long as the connections stays above max (since CounterLatch appears to be
designed to count both up and down, it compares the signal level exactly).
The fix could be to remove countUp()/countDown(), change CounterLatch.await()
to an CounterLatch.awaitAndIncrement()/CounterLatch.awaitAndDecrement() pair
and have the connection count atomically updated in Sync.tryAcquireShared()
using AtomicLong.compareAndSet() with the +1/-1 delta passed in as the
argument.
e.g:
protected int tryAcquireShared(int delta) {
while (true) {
final long current = count.get();
if (!released && (current == signal)) {
return -1;
}
if (count.compareAndSet(current, current + delta)) {
return 1;
}
}
}
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
