Re: Error unmarshaling return header

Do we know from the stack trace where this is failing? Or is there
somewhere I can go to learn the different communications that go on
between a client and a server to make one complete RMI call? In some
instrumentation I can see various timeouts being set besides our "0"
read timeout in the factory. Stepping through the code I see these being
use:

        sun.rmi.transport.tcp.handshakeTimeout=60000
        sun.rmi.transport.tcp.responseTimeout=0
        sun.rmi.transport.connectionTimeout=15000

They sometimes reset the Timeout that my factory sets by default. Could
any of these be the culprit? As I said this system can be heavily
loaded; should any of these be increased? 

And finally, this stack trace happens on the client side. Is the problem
that the server is not responding? It must be the first connect because
I don't see any exceptions on the server side when this happens. So the
server must not even know that an attempt was made to contact it.

-----Original Message-----
From: Peter Jones - JavaSoft East [mailto:[email protected]] 
Sent: Friday, December 10, 2004 11:25 AM
To: Robert DiFalco
Cc: [email protected]
Subject: Re: Error unmarshaling return header

> Hi Peter, thanks for the help. Hmmmm...we set our timeout in the 
> client (and server) socket factory to 0. If I understand this setting,

> then it should wait forever and we should never see these read
timeouts.

Yes, passing zero to Socket.setSoTimeout should cause the read timeout
to be disabled.  If that's what your client socket factory is doing, I'm
stumped as to what is causing this exception.  Again I might suggest the
SSL debug tracing, looking for unexpected timeout settings, or similar
tracing in a custom socket class.

-- Peter


> -----Original Message-----
> From: Peter Jones - JavaSoft East [mailto:[email protected]]
> Sent: Tuesday, December 07, 2004 5:26 PM
> To: Robert DiFalco
> Cc: [email protected]
> Subject: Re: Error unmarshaling return header
> 
> > On a heavily loaded system I occasionally get these?
> > 
> > Anyone seen them? What's odd is that the read timeout is set to
days.
> 
> > Is this something else that is timing out? An ack rather than a
read?
> 
> > Is there a sun rmi timeout property that I should be increasing?
> 
> The exception appears to indicate that a socket read timeout set by 
> invoking setSoTimeout on the underlying socket, presumably by a client

> socket factory, has expired while waiting for the response to a remote

> invocation request.  Do you indeed have a socket factory that sets 
> such a read timeout (is that the read timeout you refer to above, set 
> to days)?  What is the exact value?
> 
> It appears that you are using 1.4.2?  The client-side RMI 
> implementation sets its own read timeout on the socket during the 
> initial handshake phase of the connection; the value is controlled by 
> the system property "sun.rmi.transport.tcp.handshakeTimeout" (default 
> one minute), as described here:
> 
> 	
> http://java.sun.com/j2se/1.4.2/docs/guide/rmi/sunrmiproperties.html
> 
> but a timeout during that handshake would cause a different exception,

> and after the handshake has completed, the socket's original read 
> timeout is restored (or if it had been zero, the value of the system 
> property "sun.rmi.transport.tcp.responseTimeout" is used instead).
> 
> > Does SSL play a part here?
> 
> Perhaps, although I'm sure how.  There is a known JSSE bug that read 
> timeouts which occur in the middle of reading an SSL record are not 
> recoverable (subsequent read throws an SSLException), but that does 
> not appear to be related to what is happening here.  Enabling JSSE's 
> SSL debug tracing might provide a clue, such as tracing invocations of

> setSoTimeout on SSL sockets:
> 
> http://java.sun.com/j2se/1.4.2/docs/guide/security/jsse/JSSERefGuide.h
> tm
> l#Debug
> 
> > java.rmi.UnmarshalException: Error unmarshaling return header;
nested exception is:
> >         java.net.SocketTimeoutException: Read timed out
> >         at
sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:203
)
> >         at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:133)
> >         at
com.me.services.ElementManagerService_Stub.addVersions(Unknown Source)
> >         at
com.me.RuleRunner$3.run(ElementSpecifierRuleRunner.java:1137)
> >         at
EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown
Source)
> >         at java.lang.Thread.run(Thread.java:534)
> > Caused by: java.net.SocketTimeoutException: Read timed out
> >         at java.net.SocketInputStream.socketRead0(Native Method)
> >         at
java.net.SocketInputStream.read(SocketInputStream.java:129)
> >         at com.sun.net.ssl.internal.ssl.InputRecord.a(DashoA12275)
> >         at
com.sun.net.ssl.internal.ssl.InputRecord.read(DashoA12275)
> >         at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA12275)
> >         at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA12275)
> >         at
com.sun.net.ssl.internal.ssl.AppInputStream.read(DashoA12275)
> >         at
java.io.BufferedInputStream.fill(BufferedInputStream.java:183)
> >         at
java.io.BufferedInputStream.read(BufferedInputStream.java:201)
> >         at
java.io.DataInputStream.readByte(DataInputStream.java:331)
> >         at 
> > sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java
> > :189)
> 
> -- Peter
> 

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