mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John R. Fallows (JIRA)" <j...@apache.org>
Subject [jira] Created: (DIRMINA-819) Synchronous behavior while adding and removing connections
Date Tue, 15 Feb 2011 03:03:57 GMT
Synchronous behavior while adding and removing connections

                 Key: DIRMINA-819
                 URL: https://issues.apache.org/jira/browse/DIRMINA-819
             Project: MINA
          Issue Type: Bug
    Affects Versions: 2.0.2, 2.0.1, 2.0.0, 2.0.0-RC1
         Environment: java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)

            Reporter: John R. Fallows

We 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) {

    private void scheduleRemove(T session) {

    private void startupProcessor() {
        synchronized (lock) {
            if (processor == null) {
                processor = new Processor();
                executor.execute(new NamePreservingRunnable(processor,

        // Just stop the select() and start it again, so that the processor
        // can be activated immediately. 

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.

Note that we found similar behavior in AbstractPollingIoAcceptor and AbstractPollingIoConnector
as well.

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message