[jira] Commented: (DIRMINA-819) Synchronous behavior while adding and removing connections

["Emmanuel Lecharny (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DIRMINA-819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12994794#comment-12994794 ] 

Emmanuel Lecharny commented on DIRMINA-819:
-------------------------------------------

Ok, applied. It's in the 2.0.3 branch, so you'll have to build it from there.

Thanks !l 

> 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
>            Assignee: Emmanuel Lecharny
>             Fix For: 2.0.3
>
>         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