Re: What causes an object to be removed from the ObjectTable?

This thread from December:
    http://archives.java.sun.com/cgi-bin/wa?A2=ind0512&L=rmi-users&P=3905
made some further progress offline; here is a (belated) followup for
the list:

> Ugh, yeah, I can't make the two examples act differently, so that
> doesn't seem to be the issue.

That would seem to eliminate the 4114579 suspicion.

> Again, seemingly with every problem I have, this is very
> intermittent. :)
>
> Yes, the registry is in the same JVM as the service. We are using
> our own RMISSLChannelFactory and this has never been an issue. Just
> bizarre.  I'm pretty sure policy isn't an issue. Also remember this
> is a rare occurrence. However, I know it happens because I will
> rarely and inexplicably see a "remove target" call for my Service's
> ObjID in that service's JVM.

As determined from offline discussion, the problem appears to be that
the VM is getting hung for 5+ minutes in a way[*] that causes all
Object.wait timers to get delayed by a corresponding amount of time,
causing the necessary DGC lease renewal to occur too late, if the
expired lease checker happens to run first.  The problem is compounded
by the fact that the DGC lease renewal code doesn't believe that the
lease could have expired yet, so it doesn't provide enough information
in the renewal request to re-establish the lease on the particular
remote object, in case it hasn't been garbage collected yet (this
aspect could be improved by checking the current time before
constructing the renewal request and after it completes, in case a
grossly-delayed timer wakeup like this occurs-- I will file a bug
about this).  Thus, with no known remote references and no strong
local references, the remote object is eventually garbage collected.

[*] The exact mechanism for this Object.wait delay was not entirely
clear, but it seemed related to VM wrapper software.

> So if there is a strong reference to my service in the local JVM,
> then it seems like DGC problems couldn't impact this either --
> i.e. a faulty connection dropping dgc ack, clean, or dirty calls?
> Neither example kept it's own strong reference to the service.

Yes, a strong reference to the remote object reachable from some root,
like a running thread or a static field, would prevent the remote
object from being garbage collected regardless of DGC activity.

>> It's not obvious to me why either version wouldn't work,
>> because the registry binding should keep the remote object
>> alive through DGC.
>
> Ok, so if there WAS a networking failure that temporarily interfered
> with DGC, could the Target then be incorrectly removed (in either
> example) from the ObjectTable? Would keeping a strong reference to
> the Service (say making it a singleton with a static reference to
> itself) mitigate any side effects of DGC protocol failures?

As above, yes.

> But if that is the case, wouldn't I have seen DGC protocol failures
> in my DGC trace output?

Perhaps, but as described above, the problem was not a communication
failure per se, but an unexpected large delay of the lease renewal.

> It would be cool if the logging gave more information (such as
> logging in the reference queue) before the logging of #removeTarget.

Yes.  There is also an unfortunate lack of logging in the client side
of the DGC implementation:
    http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6210174

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