Folks,
We have discovered some blocking behavior in the Mina
AbstractPollingIoProcessor that is triggered while adding and removing
connections.
This class manages an internal worker that must be started when the first
connection is added, and stopped when the last connection is removed.
The code achieves this by using a synchronized block in startupProcessor()
as follows:
public final void remove(T session) {
scheduleRemove(session);
startupProcessor();
}
private void scheduleRemove(T session) {
removingSessions.add(session);
}
private void startupProcessor() {
synchronized (lock) {
if (processor == null) {
processor = new Processor();
executor.execute(new NamePreservingRunnable(processor,
threadName));
}
}
// Just stop the select() and start it again, so that the processor
// can be activated immediately.
wakeup();
}
Each call to session.close() triggers the "filterClose" event on the filter
chain, ending in a call to removeSession (shown above) where the
synchronized lock is obtained to verify that the processor is running in
order to close the connection. When a large number of connections are
closed at the same time, they will contend for the synchronized lock.
Similar behavior occurs when new connections are established via addSession
(not shown here). Both removeSession and addSession synchronize on the same
lock, so they also contend with each other as connections come and go.
If you agree that this is an issue and add it to your issue tracker, then we
would be happy to upload a patch with a suggested solution using atomic data
structures instead for your consideration.
Note that we have found similar behavior in AbstractPollingIoAcceptor
and AbstractPollingIoConnector will gladly include suggested patches for
those as well.
Kind Regards,
John Fallows
--
>|< Kaazing Corporation >|<
John Fallows | CTO | +1.650.960.8148
444 Castro St, Suite 1100 | Mountain View, CA 94041, USA
