Re: java.rmi.NoSuchObjectException: no such object in table

> If I have a server stub and I bind that stub to a local Registry, is
> that enough to keep it from being cleaned up by DGC?

It should be.  One case in which it currently isn't is when the
registry invocation is made on a registry remote object directly
instead of a stub for a registry (i.e. what's returned from
LocateRegistry.createRegistry instead of LocateRegsitry.getRegistry)
and the remote object's stub passed to the registry was returned from
RemoteObject.toStub or UnicastRemoteObject.exportObject; in this
situation, the following old bug thwarts reachability:

        http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4114579

But invoking a registry stub (like LocateRegistry.getRegistry returns)
should avoid that problem, because the remote object's stub will get
marshalled and unmarshalled and thus properly registered with DGC.

> I seem to be getting the above exception from a client (on a heavily
> loaded and scaled system) and I'm not quite sure why. My server
> simply extends AbstractRemoteObject then in the ctor does something
> basically like this:
>
>         LocateRegistry.getRegistry( getLocalServicePort() ).rebind(
>             UnicastRemoteObject.toStub( this ) );

Bug 4114579 could come into play here too if the surrounding code is
such that the local garbage collector can determine that the variable
"this" is not used after the above code and the object it refers to is
eligible for garbage collection after the UnicastRemoteObject.toStub
invocation has completed, but before the Registry.rebind has
completed.  That might seem far-fetched, but we've seen that sort of
GC behavior with the Hotspot Server VM, since JDK 5.0, on
multiprocessor machines-- in particular, there is also this bug:

        http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6181943

which could also affect the above code (regardless of 4114579).  We
haven't yet seen that bug occur with pre-5.0 JDK VMs, however.  Are
you using the Server VM?

But this would only "explain" garbage collection of the remote object
at the time of registry bind-- if it the collected remote object has
previously been looked up and invoked successfully, then the problem
must be something else; I'm not sure if that's what you meant by this:

> With ~1,000 servers, the client can get this stub and invoke methods
> on it with no problem. Looking at the server (i.e. agent) logs, all
> have been initialized and idle for at least an hour. Every once in a
> while we will see something like this:
>
>  Caused by: java.rmi.NoSuchObjectException: no such object in table

If so, then this shouldn't happen without removal or replacement of
the registry binding or DGC communication failure, which seems
unlikely.  Are these remote objects exported with custom client socket
factories?  Any other unexpected failures logged?

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