[
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