Re: Software Caused Connection Abort (10053) on Client
Robert DiFalco <[email protected]>
| Newsgroups | gmane.comp.java.sun.rmi |
|---|---|
| Message-ID | <[email protected]> |
I have some more data on this.
On my server side trace I see this at the moment the exception occurs on
the client. On the clients side I get the Software Caused Connection
Abort while it is trying to "marshal an argument over to a server side
method."
Nov 28, 2005 10:27:58 AM
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler run
FINER: RMI TCP Connection(20)-192.168.54.152: (port 9898) client using
192.168.54.152:0
7RMI TCP Connection(23)-192.168.54.152, READ: TLSv1 Handshake, length
= 111
72*** ClientHello, TLSv1
2RandomCookie: GMT: 1116432438 1bytes = { 11348, 873 , 1111, 1133C,
C39 , 66 , .205., .85., 81178, J108J, .133., .95., .20., Z
RMI TCP Connection(20)-192.168.54.152, READ: TLSv1 Application Data,
length = 236
Nov 28, 2005 10:27:58 AM sun.rmi.transport.tcp.TCPTransport
handleMessages
FINE: RMI TCP Connection(20)-192.168.54.152: (port 9898) op = 80
Nov 28, 2005 10:27:58 AM sun.rmi.transport.StreamRemoteCall
getInputStream
FINER: RMI TCP Connection(20)-192.168.54.152: getting input stream
Nov 28, 2005 10:27:58 AM sun.rmi.transport.StreamRemoteCall
getOutputStream
FINER: RMI TCP Connection(20)-192.168.54.152: getting output stream
Z149.RMI TCP Connection(24)-192.168.54.152, READ: TLSv1 Handshake,
length = 111
.RMI TCP Connection(20)-192.168.54.152, WRITE: TLSv1 Application Data,
length = 441
Nov 28, 2005 10:27:58 AM sun.rmi.transport.tcp.TCPTransport
handleMessages
FINE: RMI TCP Connection(20)-192.168.54.152: (port 9898) op = 115
Nov 28, 2005 10:27:58 AM sun.rmi.transport.tcp.TCPTransport
handleMessages
FINE: RMI TCP Connection(20)-192.168.54.152: (port 9898) exception:
java.io.IOException: unknown transport op 115
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:477)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.ja
va:701)
at java.lang.Thread.run(Thread.java:534)
Nov 28, 2005 10:27:58 AM sun.rmi.transport.tcp.TCPConnection close
FINE: RMI TCP Connection(20)-192.168.54.152: close connection
Note the exception because of an unknown transport op of 115. That
corresponds to this code:
void handleMessages(Connection conn, boolean persistent) {
int port = getEndpoint().getPort();
try {
DataInputStream in = new
DataInputStream(conn.getInputStream());
do {
int op = in.read(); // transport op
if (op == -1) {
if (tcpLog.isLoggable(Log.BRIEF)) {
tcpLog.log(Log.BRIEF, "(port " +
port + ") connection closed");
}
break;
}
if (tcpLog.isLoggable(Log.BRIEF)) {
tcpLog.log(Log.BRIEF, "(port " + port +
") op = " + op);
}
switch (op) {
case TransportConstants.Call:
// service incoming RMI call
RemoteCall call = new StreamRemoteCall(conn);
if (serviceCall(call) == false)
return;
break;
case TransportConstants.Ping:
// send ack for ping
DataOutputStream out =
new DataOutputStream(conn.getOutputStream());
out.writeByte(TransportConstants.PingAck);
conn.releaseOutputStream();
break;
case TransportConstants.DGCAck:
DGCAckHandler.received(UID.read((DataInput) in));
break;
default:
---> throw new IOException("unknown transport op " + op);
}
} while (persistent);
} catch (IOException e) {
// exception during processing causes connection to close
(below)
if (tcpLog.isLoggable(Log.BRIEF)) {
tcpLog.log(Log.BRIEF, "(port " + port +
") exception: ", e);
}
} finally {
try {
conn.close();
} catch (IOException ex) {
// eat exception
}
}
}
Any thoughts on what might be going on? I was thinking that if something
when wrong in StreamRemoteCall that this 115 could be residual data
before the socket is closed. But then again, you can see that if
serverCall( call ) returns false,k the socket is closed in the finally
block, so that seems unlikely.
R.
-----Original Message-----
From: Robert DiFalco
Sent: Friday, November 18, 2005 4:30 PM
To: [email protected]
Subject: Software Caused Connection Abort (10053) on Client
Sorry, but I'm really stumped and I think I have a Windows issue here.
We have a VMWare stack simulating many agents connecting to a Windows
server. We are running jobs in batches of 25 agents at a time. When a
job is sent to an agent, it then calls back to the server to post
results.
Sometimes, some or all of the 25 agents in a batch will fail with
Software Caused Connection Abort as the agent is trying to WRITE to the
server.
My initial thought was that the backlog value was too low on the Windows
Server. However, wouldn't this give me a Connection Refused exception
rather than a Connection Abort on Write exception?!?
Taking a look at a snoop on the server, what I do notice is that after
accepting the socket from the agent, the server sends a FIN and then
immediately afterwards a RST. Normally there is an ACK in between, but
in this case the FIN doesn't even appear to wait for one before calling
RST. What causes this sort of sequence on the server socket? Could it be
the backlog or some stupid SYN ATTACK code windows has slipped into it's
2003 Server?
Any ideas appreciated. And remember this is intermittent and it only
seems to happen with Windows Servers. If I use Linux or Solaris as a
server we do not get this intermittent issue.
R.
===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff RMI-USERS". For general help, send email to
[email protected] and include in the body of the message "help".
For a list of frequently asked RMI questions please refer to:
http://java.sun.com/j2se/1.3/docs/guide/rmi/faq.html
To view past RMI-USERS postings, please see:
http://archives.java.sun.com/archives/rmi-users.html