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.htm
> 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