🚀 go-pugleaf

Vladimir,

RMI uses what is called a "lease" mechanism for Distributed Garbage
Collection
(DGC).  This means when a connection is established to a remote object, a
lease, which has an expiration time, is obtained.  The lease then needs to
be
periodically renewed by the client.  If this does not happen (as in the case
when
a client crashes), the lease will expire - at which point the reference
count is
decremented and the GC will collect it if reference count is at zero.

-Zeeman

puiuvlad@my-dejanews.com wrote:

> I'm just concerned about the garbage collector collecting more than
> necessary or leaving around pockets of memory than cannot be used
> (memory leaks) when a client in a distributed system crashes. This is
> just a concern, I have not experienced any problems like these yet. Has
> anyone a better idea on how garbage collection is handled when stubs and
> skeletons are involved? The feature is difficult to test and reproduce
> when it occurs. The distributed system can be RMI or CORBA based...
>
> Assume the following scenario: An applet contains a pointer to a remote
> object (i.e., a stub, which somehow is connected to a skeleton on the
> server side). The skeleton points to a server object and facilitates the
> data communication between server and client (marshalling and stuff).
>
> Assume now that the gc on the server kicks in. How does it know not to
> free the skeletons? As long as there is a client pointing to it, gc
> should leave it alone. I assume there is nothing pointing to them from
> the server side, but if I'm wrong then this is the answer. On second
> thoughts, there must be a skeleton table that contains pointers to all
> skeletons. Any insight?
>
> Assume now that the client crashes and the pointer from the client to
> the server disappears. Will the skeleton ever be garbage collected? It
> should. Does the server know that the client is no longer there such
> that to mark the skeleton as not used? If the skeleton is not garbage
> collected this is equivalent to a memory leak... Any ideas?
>
> Vladimir
>
> --== Sent via Deja.com http://www.deja.com/ ==--
> ---Share what you know. Learn what you don't.---