MINA
  1. MINA
  2. DIRMINA-638

DefaultSocketSessionConfig creates some connection to itself.

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Blocker Blocker
    • Resolution: Unresolved
    • Affects Version/s: 1.1.7
    • Fix Version/s: 1.1.8
    • Component/s: None
    • Labels:
      None

      Description

      For some unknown reason, the DefaultSocketSessionConfig class is creating a ServerSocket, and create a connection :

      static {
      initializeTestAddresses();

      boolean success = false;
      for (Entry<InetSocketAddress, InetAddress> e : TEST_ADDRESSES.entrySet()) {
      success = initializeDefaultSocketParameters(e.getKey(), e.getValue());
      if (success)

      { break; }

      }

      private static void initializeTestAddresses() {
      try {
      TEST_ADDRESSES.put(new InetSocketAddress(0), InetAddress.getByAddress(new byte[]

      { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,0, 0, 0, 0, 1 }

      ));
      TEST_ADDRESSES.put(new InetSocketAddress(0), InetAddress.getByAddress(new byte[]

      { 127, 0, 0, 1 }

      ));
      } catch (UnknownHostException e)

      { ExceptionMonitor.getInstance().exceptionCaught(e); }

      }

      private static boolean initializeDefaultSocketParameters(InetSocketAddress bindAddress, InetAddress connectAddress) {
      ServerSocket ss = null;
      Socket socket = null;

      try

      { ss = new ServerSocket(); ss.bind(bindAddress); socket = new Socket(); socket.connect(new InetSocketAddress(connectAddress, ss.getLocalPort()), 10000); initializeDefaultSocketParameters(socket); return true; }

      catch (IOException ioe)

      { return false; }

      finally {
      if (socket != null) {
      try

      { socket.close(); }

      catch (IOException e)

      { ExceptionMonitor.getInstance().exceptionCaught(e); }
      }

      if (ss != null) {
      try { ss.close(); } catch (IOException e) { ExceptionMonitor.getInstance().exceptionCaught(e); }

      }
      }
      }

      The only reason why this code exists is to setup the default values for the socket configuration.

      Not only is this bad code, but also a totally wrong thing to do : in many environment, creating sockets this way will lead to breakages (Applet, etc).

      It as to be fixed urgently.

        Issue Links

          Activity

          Hide
          John Costello added a comment -

          Proposed changes to prevent NioSocketAcceptor from setting the socket receive buffer to 1024 bytes by default

          Show
          John Costello added a comment - Proposed changes to prevent NioSocketAcceptor from setting the socket receive buffer to 1024 bytes by default
          Hide
          John Costello added a comment -

          Removing the socket testing code from the DefaultSocketSessionConfig has had an unintended side effect for stand alone applications that use the NioSocketAcceptor. Before binding to the port, the receive buffer size on the ServerSocket is always set to value from the DefaultSocketSessionConfig, which previously would have been the OS default, but is now 1024 bytes. Upgrading from 2.0.0-M2 to 2.0.0-M4 caused a huge drop in read performance in several applications which previously had no trouble keeping up with the rate of incoming messages. I was able to observe the receive buffer size on the server app staying pegged at close to 1400 bytes, and confirmed using a debugger that the socket recieve buffer size was being set to 1024 bytes, which is a rather small default.

          As a fix, I propose changing NioSocketAcceptor.open to check DefaultSocketSessionConfig.isReceiveBufferChanged before setting the receive buffer size on the ServerSocket. This will let the OS default be used in most cases which I think should be the expected behavior. I've attached a tar file containing patches with the proposed changes for NioSocketAcceptor, DefaultSocketSessionConfig and AbstractSocketSessionConfig

          Show
          John Costello added a comment - Removing the socket testing code from the DefaultSocketSessionConfig has had an unintended side effect for stand alone applications that use the NioSocketAcceptor. Before binding to the port, the receive buffer size on the ServerSocket is always set to value from the DefaultSocketSessionConfig, which previously would have been the OS default, but is now 1024 bytes. Upgrading from 2.0.0-M2 to 2.0.0-M4 caused a huge drop in read performance in several applications which previously had no trouble keeping up with the rate of incoming messages. I was able to observe the receive buffer size on the server app staying pegged at close to 1400 bytes, and confirmed using a debugger that the socket recieve buffer size was being set to 1024 bytes, which is a rather small default. As a fix, I propose changing NioSocketAcceptor.open to check DefaultSocketSessionConfig.isReceiveBufferChanged before setting the receive buffer size on the ServerSocket. This will let the OS default be used in most cases which I think should be the expected behavior. I've attached a tar file containing patches with the proposed changes for NioSocketAcceptor, DefaultSocketSessionConfig and AbstractSocketSessionConfig
          Hide
          Emmanuel Lecharny added a comment -

          This has been fixed in 2.0.0-M4

          Show
          Emmanuel Lecharny added a comment - This has been fixed in 2.0.0-M4
          Hide
          Matthew McMahon added a comment -

          I am new to Mina and the whole environment. Anyway, I am creating a project that began with 2.0.0-M3 and is now using 2.0.0-M4. I have this issue, where my server and client is creating a lot of loopback threads, that I believe must be related to this issue. Any word on whether it will be fixed?

          Show
          Matthew McMahon added a comment - I am new to Mina and the whole environment. Anyway, I am creating a project that began with 2.0.0-M3 and is now using 2.0.0-M4. I have this issue, where my server and client is creating a lot of loopback threads, that I believe must be related to this issue. Any word on whether it will be fixed?
          Hide
          Emmanuel Lecharny added a comment -

          Just kept 1.1.7 as the problem is fixed for 2.0.0-M3 (hopefully)

          Show
          Emmanuel Lecharny added a comment - Just kept 1.1.7 as the problem is fixed for 2.0.0-M3 (hopefully)
          Hide
          Emmanuel Lecharny added a comment -

          It should be fixed in 2.0.0-M3-SNAPSHOT

          Show
          Emmanuel Lecharny added a comment - It should be fixed in 2.0.0-M3-SNAPSHOT
          Hide
          Emmanuel Lecharny added a comment -

          Funny enough, we had the very same problem back in 1.1.2, and it was 'solved' by catching all the exceptions. Except that I don't think it solves anything...

          Show
          Emmanuel Lecharny added a comment - Funny enough, we had the very same problem back in 1.1.2, and it was 'solved' by catching all the exceptions. Except that I don't think it solves anything...
          Hide
          Emmanuel Lecharny added a comment -

          Yeah, I just created a lonk on it.

          It may be reliable, but the problem is that when used in an Applet, it will simply not work. We are 'happy' that Alexander not only have had the problem, but was clever enough to dig it and found what was the problem ! I was totally unaware that this class was doing such a socket connection...

          Show
          Emmanuel Lecharny added a comment - Yeah, I just created a lonk on it. It may be reliable, but the problem is that when used in an Applet, it will simply not work. We are 'happy' that Alexander not only have had the problem, but was clever enough to dig it and found what was the problem ! I was totally unaware that this class was doing such a socket connection...
          Hide
          Edouard De Oliveira added a comment -

          I would bet that this issue is related with https://issues.apache.org/jira/browse/DIRMINA-628 (quote = " Windows Firewall dialog complaining about our software trying to perform an operation that needs to be blocked / unblocked before continuing").

          I remind an old thread discussion saying that it was the reliable way to test if some socket opts where available but it is ?

          Show
          Edouard De Oliveira added a comment - I would bet that this issue is related with https://issues.apache.org/jira/browse/DIRMINA-628 (quote = " Windows Firewall dialog complaining about our software trying to perform an operation that needs to be blocked / unblocked before continuing"). I remind an old thread discussion saying that it was the reliable way to test if some socket opts where available but it is ?
          Hide
          Emmanuel Lecharny added a comment -

          It affects also 1.1.7, and the Datagram support.

          Show
          Emmanuel Lecharny added a comment - It affects also 1.1.7, and the Datagram support.

            People

            • Assignee:
              Emmanuel Lecharny
              Reporter:
              Emmanuel Lecharny
            • Votes:
              1 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:

                Development