Re: DGCClient$EndpointEntry stuck

I too am having problems with DGC threads, though in my case they get stuck
in endless loops creating sockets, eventually starving the machine of
resources.  The application uses socket factories (and also subclasses
Socket so I can track them) and of course has hashCode and equals methods on
the socket factory class.  The machine where the problem has occurred is
actually the server; lots of clients make RMI calls to the server for info.
 Separately, the server connects to each client occasionally to pull data up
(which makes load management on the server much easier).  It is this process
that somehow triggers the 'runaway' socket creation process.  In the custom
socket class, I log socket creation time and a stack trace so I can see that
sometimes a DGC thread on the server (actually being an RMI client) creates
sockets to a client (acting as an RMI server) every 20 minutes.  In one
instance the interval was just seconds.  And the sockets don't get closed
either, so doing a netstat comes up with a long list of unconnected sockets.
 Has anyone seen this?  I don't think it's anything to do with IP address
changes on the client machines.  I'm not using RMI callbacks, though RMI can
happen in both directions.

Paul B


On Mon, 6 Dec 2004 13:53:23 -0600, Mike Martin <[email protected]> wrote:

>Peter wrote:
>> >   "RMI
>RenewClean-[146.74.221.74:32779,com.sun.wbem.client.adapter.rmi.CIMOMClientS
>ocketFactory@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.
>
>Yep, you wouldn't.  That package is part of WBEMServices which
>has been modified for use in our product.  A client socket
>factory has been added but all it does is delegate to the
>default factory and then call setSoTimeout().
>
>> > 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?
>
>Oooooh, nice catch!  I hadn't thought of that one.  The key
>of course is, where might the 'somewhere' be?  But at first
>blush that theory seems a lot more plausible because we're
>doing nothing on the server side that should result in a
>fixed port number.
>
>We're still struggling to reproduce the problem in-house but
>I'm going to add a little more logging to try to detect that
>situation if it occurs.  Thanks, Peter!
>
>Mike
>
> ==========================================================================
>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

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