[jboss-jira] [JBoss JIRA] Commented: (JBREM-690) Once the socket of a callback server timeouts, it starts to silently discard traffic

[Ron Sigal (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBREM-690?page=comments#action_12351965 ] 
            
Ron Sigal commented on JBREM-690:
---------------------------------

It seems that when one end of a TCP connection shuts down, it doesn't automatically inform the other side unless there's an ACK or NAK going out anyway.  In particular, I think that it's possible for the first socket write() to succeed after the other end disconnects. 

Example:

    public class SocketTest
    {
       public static void main(String[] args)
       {
          new Thread()
          {
             public void run()
             {
                try
                {
                   ServerSocket ss = new ServerSocket(2345);
                   Socket s = ss.accept();
                   InputStream is = s.getInputStream();
                   System.out.println("read: " + is.read());
                   s.close();
                   ss.close();
                }
                catch (IOException e)
                {
                   System.out.println("server: " + e);
                }
             }
          }.start();
         
          try
          {
             Socket s = new Socket("localhost", 2345);
             OutputStream os = s.getOutputStream();
             os.write(3);
             System.out.println("wrote 3");
             os.write(5);
             System.out.println("wrote 5");
             os.write(7);
             System.out.println("wrote 7");
             s.close();
          }
          catch (IOException e)
          {
             System.out.println("client: " + e);
          }
       }
    }

You might expect os.write(5) to fail, but, in fact, the output (at least in Windows and I think this would be the case in linux as well) is:

    wrote 3
    read: 3
    wrote 5
    client: java.net.SocketException: Software caused connection abort: socket write error

There's no problem for an ordinary invocation because the client waits for a response.  For an asynchronous invocation, however, the client may never know that an invocation failed.

One workaround is to use the connection checking facility of the socket transport, which does preliminary i/o on a socket to determine if the connection is still working.  Alternatively, the application can verify that an intended invocation has succeeded.

> Once the socket of a callback server timeouts, it starts to silently discard traffic
> ------------------------------------------------------------------------------------
>
>                 Key: JBREM-690
>                 URL: http://jira.jboss.com/jira/browse/JBREM-690
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: callbacks
>    Affects Versions: 2.2.0.Alpha6
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ron Sigal
>            Priority: Blocker
>             Fix For: 2.2.0.Alpha7
>
>
> Please write the following test (and I actually mean it, please do, and keep it your test suite):
> Create a "socket" transport client and register a listener to it, so the push callback server is initialized.
> Send a callback to the client, to make sure a socket is created and traffic is sent over it.
> Wait enough for the callback socket to timeout (a little bit longer than ServerInvoker.DEFAULT_TIMEOUT_PERIOD).
> Send a new callback to the client.
> The callback will be silently discarded, never to be heard of again. 
> For the Messaging version of this bug, please see http://jira.jboss.org/jira/browse/JBMESSAGING-371 and the associated RemotingTest.test testMessageListenerTimeout()

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira