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

Peter,

As always, thanks for the great attention and amount of information you
provide people with. FWIW, we haven't seem this problem for a long time.

>> If so, then this shouldn't happen without removal or replacement
>> of the registry binding or DGC communication failure, which seems
>> unlikely.  

Is this really unlikely. Given that there are 1,000 agents, it seems
possible, but then again, I have not seen any other exceptions logged.

>> Are these remote objects exported with custom client socket
factories?

Yes, a pretty standard implementation of an RmiSslChannelFactory with an
appropriately defined #equals method. Again, it's been sometime since
I've seen this error and since so much has been going on here I feel
somewhat comfortable moving on to other issues and calling this one some
kind of unknown pilot error. I have some more recent questions on TCP
KeepAlive and Deserializing Stubs stored in a database. :)

R.

-----Original Message-----
From: Peter Jones - JavaSoft East [mailto:[email protected]] 
Sent: Thursday, September 29, 2005 11:44 PM
To: Robert DiFalco
Cc: [email protected]
Subject: 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