Mailing-List: contact dev-help@mina.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@mina.apache.org
Date: Tue, 15 Feb 2011 03:11:59 +0000 (UTC)
From: "John R. Fallows (JIRA)" <jira@apache.org>
To: dev@mina.apache.org
Message-ID: 
 <1618384214.16610.1297739519117.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1759675994.16590.1297739037445.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] Updated: (DIRMINA-819) Synchronous behavior while adding and
 removing connections
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ 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

> 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