Hi all,
I'm seeing a strange issue with a (practically, for these purposes) stock
Mina 2.0.7. Basically, every once in a while (in production only, of
course), a couple of threads will go off into the weeds, consuming 100%
CPU, and never come back. They're sitting in an infinite loop that looks
something like this:
* We're chugging merrily along in the main processing loop
(AbstractPollingIoProcessor.java:1070)
* Decide to flush the single session in flushingSessions
(AbstractPollingIoProcessor.java:773, :1129)
* According to "SessionState state = getState(session)", the session is
OPENED, which I think is a lie, and perhaps the root of the problem.
* Enter "flushNow" (AbstractPollingIoProcessor.java:821, :789, :1129)
* Begin processing a queued message (AbstractPollingIoProcessor.java:861,
:789, :1129)
* Try to write out the message in writeBuffer
(AbstractPollingIoProcessor.java:931, :861, :789, :1129)
* Catch an IOException ("Broken pipe") in writeBuffer
(AbstractPollingIoProcessor.java:935, :861, :789, :1129), call
"session.close(true)"
* Next time around the loop at (AbstractPollingIoProcessor.java:1070), the
session is put back in flushingSessions, because apparently the session is
still writable (liar!) (AbstractPollingIoProcessor.java:671, :653, :1124)
* Repeat, Ad Infinitum!
Unfortunately, I don't know how it first gets into that loop - which I
think has a lot to do with how the first call to AbstractIoSession.close()
is processed.
Any idea on how to further debug this? Is there a simple fix - perhaps
something that's already scheduled for the next release? I'd love to try
2.0.8, but sadly, since this is only thus far reproducible in production,
I'll probably need significant evidence that this is fixed in that
version...
Thanks,
Joshua
