Re: DGCClient$EndpointEntry stuck

> > > I'm in a situation where this happens to us consistently on a
> > > particular endpoint, i.e. we get duplicate RenewClean threads and
> > > the number grows over time.
> >
> > By "duplicate RenewClean threads", do you mean for the same host,
> > port, and (possibly null) client socket factory values running
> > simultaneously?
>
> Yep.  Although a client socket factory *is* in use I'm 100% sure it
> has a proper hashCode() and equals().  Since toString() is not
> overridden the thread name pretty much confirms it.  Each dup had
> this exact name:
>
>   "RMI RenewClean-[146.74.221.74:32779,com.sun.wbem.client.adapter.rmi.CIMOMClientSocketFactory@493e0]"

OK.

Do you happen to have source code for this class?  I was pointed at an
internal source repository for the com.sun.wbem.client.adapter.rmi
package, but it did not have a class named CIMOMClientSocketFactory.

> > > I suspect the root cause is that the RMI server process on that host
> > > is being occasionally (and too frequently) killed.  This bug would
> > > seem to be the only plausible explanation.
> >
> > Do you know what exception (that is not a ConnectException) is getting
> > thrown on the attempt to communicate with that host (i.e. the
> > condition for this bug)?
>
> I've sprinkled some printlns in DGCClient, particularly in
> makeCleanCalls(), in an attempt to find out exactly that.  The
> problem is that this all occurred at a customer site and we haven't
> yet reproduced it in-house.  We've tried killing the server JVM in
> various grisly ways and we always get a nice ConnectException on the
> client side.
>
> The thing is, that port number (32779) was apparently persistent
> across restarts of the server JVM, and I don't see how that could
> happen.  We're not seeing it happen in-house.

If the remote object indeed does not get exported explicitly on that
same fixed port-- could what is happening be that an old, stale remote
reference to that endpoint (which persists somewhere) is repeatedly
getting unmarshalled in the client VM (in which the above "RenewClean"
threads are observed) and then getting garbage collected?

The condition under which bug 6199638 causes multiple "RenewClean"
threads for the same endpoint (identical host, port, and client socket
factory) to stick around is if the number of live remote references to
the endpoint that are reachable in the VM transitions between zero and
greater than zero multiple times (and DGC clean calls to that endpoint
fail with an exception other than ConnectException, etc.).

> In case it matters the O/S was Solaris 8 on the server and RH 2.4.20
> on the client, JRE 1.4.1_03 on both.

Thanks.

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