Uploaded image for project: 'MINA'
  1. MINA
  2. DIRMINA-818

Loosing connects on NioSocketConnector

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0.2
    • Fix Version/s: 2.0.8
    • Component/s: Core
    • Labels:
      None
    • Environment:
      WinXP JDK 1.6.1_23

      Description

      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?

        Activity

        Hide
        elecharny Emmanuel Lecharny added a comment -

        The selector is handled by one single thread. There is no way a different thread can update the selectedKeys set. Thus there is no need to copy the provided set or to synchronize the manipulation of those sets.

        Regarding the initial issue, we would need a test case to reproduce the issue (if it's still relevant, after 3 years... - sorry for that )

        Show
        elecharny Emmanuel Lecharny added a comment - The selector is handled by one single thread. There is no way a different thread can update the selectedKeys set. Thus there is no need to copy the provided set or to synchronize the manipulation of those sets. Regarding the initial issue, we would need a test case to reproduce the issue (if it's still relevant, after 3 years... - sorry for that )

          People

          • Assignee:
            Unassigned
            Reporter:
            j.michelberger Jörg Michelberger
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:

              Development