https://issues.apache.org/bugzilla/show_bug.cgi?id=54086
Casey Lucas <clu...@e-miles.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |---
--- Comment #2 from Casey Lucas <clu...@e-miles.com> ---
I verified that this problem still exists in 7.0.41. I tracked down and fixed
the problem.
Problem:
During shutdown, NioReceiver.close() is called which ultimately calls
NioReceiver.closeSelector(). selector.keys() is called and an iteration is
performed - closing the existing channels and canceling the keys. Per the
Selector javadocs, the set cannot be modified during iteration by another
thread or else a ConcurrentModificationException will be thrown. The set is in
fact being modified by another thread (NioReceiver thread) when existing
connections are closed (see listen() and canceledKey(SelectionKey) methods).
The problem is difficult to reproduce because of timing. I was able to reliably
reproduce the problem but I had to add a sleep in the closeSelector() method
and or set breakpoints during testing. Ultimately, I couldn't come up with a
test case that didn't need a sleep in closeSelector() so I don't have a test
case for the attached patch.
The attached patch loops (up to 3 times) catching
ConcurrentModificationException during close and sleeps for a brief period
(100ms * attempt number) allowing the NioReceiver thread to finish it's loop.
After the sleep, it attempts to close channels again.
--
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
