Home Duet/Cafe Duet

SocketException: errno = 0x44

PhreaKPhreaK Senior MemberPosts: 966
When attempting to create a connect a socket within a duet module I'm getting a rather odd SocketException thrown intermittently. I have not being able to isolate what is causing the exception to occur. Without modifying any external factors successful connection is seemingly random.

Here's the top of the stack trace (from where it enters java.net):
(0000069317) java.net.SocketException: errno2: 68, error: errno = 0x44 for fd: 38
(0000069323)    at java.net.PlainSocketImpl.socketConnect(Native Method)
(0000069326)    at java.net.PlainSocketImpl.doConnect(Unknown Source)
(0000069329)    at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
(0000069366)    at java.net.PlainSocketImpl.connect(Unknown Source)
(0000069372)    at java.net.Socket.connect(Unknown Source)
The block throwing the exception is as below:
socket = new Socket();
socket.connect(addr, CONNECT_TIMEOUT);
Where addr is a java.net.SocketAddress.

Can anyone provide some insight into what errno 0x44 is?

Comments

  • a_riot42a_riot42 AMX Wizard Posts: 1,619
    PhreaK wrote: »
    When attempting to create a connect a socket within a duet module I'm getting a rather odd SocketException thrown intermittently. I have not being able to isolate what is causing the exception to occur. Without modifying any external factors successful connection is seemingly random.

    Here's the top of the stack trace (from where it enters java.net):
    (0000069317) java.net.SocketException: errno2: 68, error: errno = 0x44 for fd: 38
    (0000069323)    at java.net.PlainSocketImpl.socketConnect(Native Method)
    (0000069326)    at java.net.PlainSocketImpl.doConnect(Unknown Source)
    (0000069329)    at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
    (0000069366)    at java.net.PlainSocketImpl.connect(Unknown Source)
    (0000069372)    at java.net.Socket.connect(Unknown Source)
    
    The block throwing the exception is as below:
    socket = new Socket();
    socket.connect(addr, CONNECT_TIMEOUT);
    
    Where addr is a java.net.SocketAddress.

    Can anyone provide some insight into what errno 0x44 is?

    Not sure about errno 0x44, but there doesn't appear to be anything wrong with those two lines of code. Where is the code with the addr and timeout defined?

    Unknown Source sounds like there is a problem on the client side, like the timeout is too short, connection was closed suddenly by the client, etc. You might need Wireshark to figure it out.
    Paul
  • PhreaKPhreaK Senior Member Posts: 966
    'Unknown Source' shows in that stack trace as the java.net classes are not compiled with debug info, this shows correctly further up the stack but switches to unknown when it enters the java.net methods.

    CONNECT_TIMEOUT is a static member with value of 5000 during this testing and addr is a SocketAddress which contains an InetSocketAddress.

    I handle timeouts explicitly in a separate catch clause so I know that isn't happening. If it was a name resolution issue this would throw an exception when I create the InetSocketAddress and I have not noticed anything odd happening at the network level so at the moment I have this cryptic error to play with and that's it.
  • PhreaKPhreaK Senior Member Posts: 966
    Ok, now this is weird. I've swapped out the connect method for one that is sans explicit timeout:
    socket = new Socket();
    socket.connect(addr);
    
    and it now intermittently throws NoRouteToHostException's with errno = 0x3c.

    My initial reaction was 'awesome, its a network issue' i.e. fault identified. However, with multiple instantiations connecting to devices that share subnets some are successful and some fail. All devices can also be pinged from the NI, even those that have failed to connect.
  • a_riot42a_riot42 AMX Wizard Posts: 1,619
    PhreaK wrote: »
    'Unknown Source' shows in that stack trace as the java.net classes are not compiled with debug info, this shows correctly further up the stack but switches to unknown when it enters the java.net methods.

    Right, its been a while since I've looked at stack traces.

    It still seems like a network issue from what you've described, especially with the NoRouteToHost error. If you post more of the relevant code it might be beneficial.
    Paul
  • PhreaKPhreaK Senior Member Posts: 966
  • a_riot42a_riot42 AMX Wizard Posts: 1,619
    PhreaK wrote: »

    If the connection fails, are you cleaning up and closing the socket or waiting for the timeout? You might want to call close in your catch for an IOException, or in a finally clause. In VXWorks that error number corresponds to EINPROGRESS telling you that a read is still in progress and to try later. You didn't post the calling code, but are you reading/writing to the socket when its currently reading/writing?

    Errno 0x3c seems to be ETIMEDOUT.
    Paul
  • PhreaKPhreaK Senior Member Posts: 966
    That module is still extremely messy when it comes to exception handling / cleanups (there basically is none, it just yells at you that something broke). I've been trying to figure out why the hell this is happening with the bare minimum of code before adding graceful handling of exceptions.

    That module instantiates SocketBuffers here and opens the streams here.
  • a_riot42a_riot42 AMX Wizard Posts: 1,619
    finally {
      try {
           in.close();
           out.close();
           socket.close();
      }
      catch(IOException ioException){
        ioException.printStackTrace();
      }
    }
    
    

    You might try throwing something like that in and see if it helps. Probably won't but it can't hurt. Wouldn't you want to be using BufferedInputStream rather than InputStream?
    Paul
  • PhreaKPhreaK Senior Member Posts: 966
    a_riot42 wrote: »
    Wouldn't you want to be using BufferedInputStream rather than InputStream?
    The implementing code wraps it (see here). Keeping these as straight io streams allows them to be wrapped as buffered io streams or PrintWriter / BufferedReader combo's depending on the device protocol.
Sign In or Register to comment.