🚀 go-pugleaf

On Tue, 18 May 1999 18:29:45 GMT, 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...

I can't (and thus won't) speak for RMI.  From a CORBA point of view,
though, there is *no* distributed reference counting, so there is no
relationship between client-side and server-side reference counts.  Thus,
all server-side memory management issues are solely handled from the
server.  Whether you want to provide interfaces in your IDL to let clients
delete objects remotely is up to you.  Of course, this can be dodgy in
scenarios where the same objects are used by multiple clients...

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

In the CORBA vernacular, the client invokes on a proxy object.  This
proxy handles communication with the server.  The server skeleton
can either delegate requests to a back-end object (this is known as the
tie method), or the implementation object can acutually inherit from
the CORBA idl-compiler generated skeletons.

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

If you're using inheritance, your server-side objects won't be gc'd unless
you set them to null.  Also, with inheritance, skeletons are simple classes
which are defined as pure virtual.  It is true the ORB must maintain
tables of its objects, but you (as a developer) aren't typically allowed
access to this table.  Just set objects to null (this is of course Java) when
you're done with 'em.  With the tie method, you may need to set the
"pointed to" object to null, as well as the tie object.  I'm a bit foggy in
my recollection of this case.

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

Again, the client's crashing doesn't affect the server.  CORBA servers,
if they run for a long time, will tend to accumulate lots of objects, as
they're never gc'd until you explicitly set them to null (deleting them
first if you're using C++).  The classic evictor pattern is a common
server-side strategy for CORBA servers, and lets the server implementor
decide how and when to punt server-side objects.  With proper hooks
to a persistent back end, the clients are blissfully unaware of anything
which is going on w.r.t memory management on the back end.

RMI may be different.  I haven't ever worked with it.

-B

>Vladimir
>
>
>--== Sent via Deja.com http://www.deja.com/ ==--
>---Share what you know. Learn what you don't.---

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