mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Michelberger (JIRA) <j...@apache.org>
Subject [jira] Created: (DIRMINA-818) Loosing connects on NioSocketConnector
Date Fri, 11 Feb 2011 17:04:04 GMT
Loosing connects on NioSocketConnector

                 Key: DIRMINA-818
                 URL: https://issues.apache.org/jira/browse/DIRMINA-818
             Project: MINA
          Issue Type: Bug
          Components: Core
    Affects Versions: 2.0.2
         Environment: WinXP JDK 1.6.1_23
            Reporter: Jörg Michelberger

I implemented a reconnection mode, which initiates a immediate NIOSocketConnector.connect
after connection is broken. This works fine for a while, but NioSocketConnector thread stops
performing connects on TCP/IP level after a while. Connects are then lost in MINA and the
corresponding connect future listener is never called... Connector thread is no longer in
thread list of target VM (listet by Netbeans Debugger or VisualVM) My Automatic doesn't work
any longer... Connection requests are done by a scheduler thread in my API, or direct in the
thread running the DisconnectFuture.operationComplete() callback, "NioProcessor-X" thread
AFAIK. In MINA-Core 2.0.2 I found NioSocketConnector and AbstractPollingIoConnector which
iterate with a MINA provided Iterator implementation over the keys() and selectedKeys() Set
provided by the selector. Iterator remove is also used. Both Set provided by the Selector
are NOT THREAD SAFE as the java API doc says. What happens if another thread adds a connection
request to the selector and MINA AbstractPollingIoConnector.Connector is processing the Set
with its Iterator and calls remove on the Iterator? Concurrent modification error or some
other inconsistence? I think iteration should be done with a copy of the Set and remove should
be done on the original keys() and selectedKeys() Set synchronized with a concurrency protecting
lock. What do you think about?

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


View raw message