Re: Software Caused Connection Abort (10053) on Client

Please note that this is a rare intermittent problem that only seems to
occur when Windows is the server (this isn't confirmed however).

Another tidbit of info, the error always seems to occur when marshalling
the same object over to the server. This object has a field that
serializes a UnicastRemoteObject. However, the field is declared as the
interface, so I'm not sure why this should be a problem (and an
intermittent one at that -- DGC?). The UnicastRemoteObject is a
singleton that the client send the server a stub too. Just some
additional info.

R.

-----Original Message-----
From: Robert DiFalco [mailto:[email protected]] 
Sent: Monday, November 28, 2005 12:00 PM
To: [email protected]
Subject: Re: Software Caused Connection Abort (10053) on Client

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

===========================================================================
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