Deserializing a Stored Stub Sometimes Requires a Connection?

Robert DiFalco <[email protected]>
Newsgroups gmane.comp.java.sun.rmi
Message-ID <[email protected]>
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? 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(DashoA122
75)
   at
com.foobar.kernel.ext.security.channel.RMISSLChannelFactory.createSocket
(RMISSLChannelFactory.java:216)
   at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:562)
   at
sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:185)
   at
sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:171)
   at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:313)
   at sun.rmi.transport.DGCImpl_Stub.dirty(Unknown Source)
   at
sun.rmi.transport.DGCClient$EndpointEntry.makeDirtyCall(DGCClient.java:3
28)
   at
sun.rmi.transport.DGCClient$EndpointEntry.registerRefs(DGCClient.java:27
5)
   at sun.rmi.transport.DGCClient.registerRefs(DGCClient.java:112)
   at sun.rmi.transport.LiveRef.read(LiveRef.java:274)
   at sun.rmi.server.UnicastRef.readExternal(UnicastRef.java:464)
   at java.rmi.server.RemoteObject.readObject(RemoteObject.java:420)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
   at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:324)
   at
java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:838)
   at
java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1746)
   at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1646
)
   at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
   at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324)
   at
com.foobar.space.core.persistence.db.ResultSetValues.getSerialized(Resul
tSetValues.java:222)
   at
com.foobar.space.core.node.ServerNode.readFromDataSource(ServerNode.java
:409)
   ....

===========================================================================
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.