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] Updated: (DIRMINA-819) Synchronous behavior while adding and removing connections
Date Tue, 15 Feb 2011 03:13:57 GMT

     [ https://issues.apache.org/jira/browse/DIRMINA-819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

John R. Fallows updated DIRMINA-819:
------------------------------------

    Attachment: sync.patch

Patch relative to 2.0.0-RC1 where issue was first discovered.

> 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.0-RC1, 2.0.0, 2.0.1, 2.0.2
>         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
>         Attachments: sync.patch
>
>
> 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) {
>         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.
> 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

        

Mime
View raw message