Re: Deserializing a Stored Stub Sometimes Requires a Connection?

> We have agents that register themselves with our server for callbacks.
> When an agent calls Server#regster, it is added as a node to the
> database and one of those fields contains a serialized version of the
> agent's stub. The agent registers itself every time it is started up
> (thus updating the stored stub on the server).
>
> What I have seen (just once that I have noticed) is that the act of just
> reading/deserializing this stub from the database could cause the server
> to attempt to make a DGC call to that agent. This is not great for us
> because it is ok for the agent to be intermittently connected and we
> read the Node object for other reasons than remote calls on the agent.
> Now I can work around this be NOT reading/deserializing this column
> unless a remote call needs to be performed but it did make me curious.
>
> Under what circumstances will just deserializing a remote stub result in
> a connection to the stub's host?

If the number of live remote references to the remote object in the
current VM (before deserializing this one) had been zero, then the
client-side DGC implementation will attempt to call the server-side
DGC once, synchronous with the deserialization, in an effort to
maintain referential integrity (if that attempt fails, retries will
only be attempted in the background).  Deserializing a remote stub
behaves in this respect similarly to unmarshalling one as part of a
remote call's arguments or return value.

> Another odd aside is that in this one case where the agent host was
> down, the deserialization appeared to hang. A thread dump gave us
> the following trace (which is what led me to the conclusion that
> reading a serialized stub could in some cases require a connection
> to the stub's host).
>
>  "http-443-Processor1" daemon prio=5 tid=0x017b85a0 nid=0x3d1 runnable [d32fd000..d3301998]
>    at java.net.PlainSocketImpl.socketConnect(Native Method)
>    at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305)
>    - locked <0xe288b898> (a java.net.PlainSocketImpl)
>    at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171)
>    at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158)
>    at java.net.Socket.connect(Socket.java:452)
>    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.connect(DashoA12275)
>    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.<init>(DashoA12275)
>    at com.sun.net.ssl.internal.ssl.SSLSocketFactoryImpl.createSocket(DashoA12275)
>    at com.foobar.kernel.ext.security.channel.RMISSLChannelFactory.createSocket(RMISSLChannelFactory.java:216)
>    at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:562)
[snip]

How long did it hang there?  FWIW, note that since 1.4, you can impose
a lower timeout on socket connect (than the configured TCP default) by
first creating an unconnected socket, like with the no-arg
SSLSocketFactory.createSocket() method, and then using the
Socket.connect(SocketAddress,int) method.

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