Re: Object Reference counting idea.

["Dirk-Jan C . Binnema" <bulkmail dds nl>]

Hi Michael,

On Tue Oct 10, 2000 at 11:06:44AM -0400, Michael Meeks wrote:

->  
->         Of course; if we try to do anything more for Gnome 2.0, I'd like  
-> to read up on distributed garbage collection, everyone keeps claiming this
-> is an unsolved problem and clearly there would be a load of issues. If    
-> anyone has some nice links on the subject I'd much appreciate them.


To quote Don Box (who is like the Michael Meeks of COM ;-) from a
posting to comp.object.corba: "I've lived with both protocols for a
long time now. I am convinced that there is no significant technical
advantage to either protocol in terms of raw method invocation or
"object activation." The primary technical difference between the
protocols is related to lifecycle management - aggregate pinging is
the (optional) default for DCOM - GIOP has no support,so folks do the
Henning/Vinoski trick of evicting objects based on inactivity or other
metrics. The former makes writing applications somewhateasier, the
latter makes the plumbing easier to implement and arguably
morescalable."

In Henning/Vinoski this is discussed (12.7). They discuss various
strategies: 

1) periodically shutting down all servants, or, slightly
more advanced, shutting down servers after a certain period of idle
time

2) using the 'evictor' pattern, which means you only keep so many
servants alive, and de-activate idle ones to some queue, from which
they can be recreated on demand (transparently to the client) This is
similar to virtual memory page aging. After some time on the
inactivity queue you can decide to remove the object from the
queue. (Note that the 'evictor' is not only for garbage collection, in
fact it's a strategy for saving memory space, by moving servant from
memory to some persistant state. Also note that instead of looking at
the idle period you can also look at eg. mem consumption).

3) timers that er reset at any method invocation; difference with 1) is that yoy can do this on a per-servant basis, for example by some parameter to a factory object.

4) demand that client do a periodic 'ping'. 
4a) demand a callback interface at the client to 'ping' the client for every object 
4b) demand a global callback interface at the client to 'ping' the client for all objects

5) let the orb notify you when connections go down 

6) distributed reference counts. 

Unfortunately, all of these alternatives have serious drawbacks, as
you may have noticed.  It's just that distributed garbage collection
is hard. The evictor pattern is probably the most sophisticated. Note
that 6) and 4) could be done by Bonobo, 1), 2), 3) and 5) and maybe 4)
should be done by ORBit.

--Dirk-Jan.