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

Surprising behaviour with ConnectFuture

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0.6
    • Fix Version/s: 2.0.8
    • Component/s: Core
    • Labels:
      None
    • Environment:
      Linux 3.5.5 amd64, OpenJDK 6 (IcedTea6 1.11.4) 6.b24_1.11_4-1_x86_64

      Description

      The following server does not appear to receive any of the data sent by the client:

      http://waste.io7m.com/2012/10/07/Server.java
      http://waste.io7m.com/2012/10/07/Client.java

      The output from the client is:

      Connecting
      session-created: (0x00000001: nio datagram, client, /127.0.0.1:33868 => /127.0.0.1:2300)
      Connected
      Session (0x00000001: nio datagram, client, /127.0.0.1:33868 => /127.0.0.1:2300)
      Writing HeapBuffer[pos=0 lim=8 cap=8: 00 00 00 02 00 00 00 03]
      Writing HeapBuffer[pos=0 lim=8 cap=8: 00 00 00 02 00 00 00 03]
      Writing HeapBuffer[pos=0 lim=8 cap=8: 00 00 00 02 00 00 00 03]
      Writing HeapBuffer[pos=0 lim=8 cap=8: 00 00 00 02 00 00 00 03]
      Writing HeapBuffer[pos=0 lim=8 cap=8: 00 00 00 02 00 00 00 03]
      Writing HeapBuffer[pos=0 lim=8 cap=8: 00 00 00 02 00 00 00 03]
      Writing HeapBuffer[pos=0 lim=8 cap=8: 00 00 00 02 00 00 00 03]
      Writing HeapBuffer[pos=0 lim=8 cap=8: 00 00 00 02 00 00 00 03]

      The output from the server is:

      Binding...
      Bound

      I'd expect to see messages regarding session creation and messages received on the server side.

      Emmanuel Lecharny had this to say:

      > Your code is correct, and, yes, there is something subtile that make
      > your code not working.
      >
      > You have to add :
      >
      > future.awaitUninterruptibly();
      > just after this line in your UDPClient :
      >
      > final ConnectFuture future =
      > this.connector.connect(new InetSocketAddress("127.0.0.1", 2300));
      >
      > Yes, I know, it sounds weirdo. I have no idea why the
      >
      > if (conn_future.isConnected()) {
      >
      > does not wait for the same kind of event than the await() method does.
      >
      > I suggest you fill a JIRA, so that we can fix this strange behavior

        Activity

        Hide
        elecharny Emmanuel Lecharny added a comment -

        I have investigated a bit further.

        When you connect to the server, under the hood a session is created. This session will have many states before being able to send data to the server :

        • at first, it does not exist
        • then it switches to CREATED
        • then it switches to OPENED
        • later on, it will be CLOSING and CLOSED

        Anyway, the listener attached to the ConnectionFuture will be triggered when the session is in a CREATED state. Now, and this is were it's a bit crappy, what happens is that the listener will try to write something in the session, but the session won't be OPENED yet, thus nothing will be sent. It does not block though : the messages get enqueued. he bad news is that the queue will grow up to a point you'll get a OOME...

        Soooo, what can we do ? The best would be to attach the listener to the OPENED event, because you then will be able to write into the session. Bad news again : this is not possible...

        We definitively have to look at this part of the code, because, frankly, it stinks...

        Show
        elecharny Emmanuel Lecharny added a comment - I have investigated a bit further. When you connect to the server, under the hood a session is created. This session will have many states before being able to send data to the server : at first, it does not exist then it switches to CREATED then it switches to OPENED later on, it will be CLOSING and CLOSED Anyway, the listener attached to the ConnectionFuture will be triggered when the session is in a CREATED state. Now, and this is were it's a bit crappy, what happens is that the listener will try to write something in the session, but the session won't be OPENED yet, thus nothing will be sent. It does not block though : the messages get enqueued. he bad news is that the queue will grow up to a point you'll get a OOME... Soooo, what can we do ? The best would be to attach the listener to the OPENED event, because you then will be able to write into the session. Bad news again : this is not possible... We definitively have to look at this part of the code, because, frankly, it stinks...

          People

          • Assignee:
            Unassigned
            Reporter:
            io7m Mark Raynsford
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:

              Development