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

Emmanuel Lecharny updated DIRMINA-818:
--------------------------------------
    Fix Version/s: 2.0.8

> 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
>             Fix For: 2.0.8
>
>
> 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 was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to