Re: Serious Bonobo Problem for Sun

[Colm Smyth <Colm Smyth Sun COM>]

Hi,

Apologies, I'm a little late to this thread. I'd like to offer a summary
of some available solutions, I'm sure many have been suggested in
some form already but it may help to have an overview:

1. middleware notifies server of client death; this is the best solution
   as it is transparent and operates at the a common low level; since the
   middleware is CORBA which (I believe) has no standard that supports
   client death notification, this can't be used.

2. server pings clients; since a client normally invokes a server, this
   is a slightly unusual situation but bi-directional communication is
   supported by recent GIOP standard; technically possible, but it
   complicates the architecture by requiring clients to export a
   CORBA interface so not to be recommended; if this mechanism were
   chosen, it would be best if the Client::ping() interface were
   asynchronous.
 
3. client specifies idle timeout to server (a.k.a client leases an
   interface from a server); this is relatively straightforward, it
   would simply require adding an idle_timeout(int nsecs) method to Bonobo's
   Unknown interface; if the client does not call the interface within
   nsecs seconds, the server decrements the reference count for that
   client; this mechanism requires each object server to maintain a
   timeout value and a last-invoked time for each of it's clients; this
   could be done globally or for each object instance in an object server 
   
So far I've just listed the mechanisms available at the object distribution
level; if a server has more information about a client, other methods
are possible:

4. common resource; if the server knows about a resource that the client
   holds, it may be able to track state changes in this resource to know
   if the client has terminated;
   
   4a) Window; if the object server provides a window that appears within
       a client's frame window, the server knows if the client's containing
       window disappears
   4b) File; if the client locks a file, the server can attempt to lock
       that file at intervals; when it succeeds, it knows the client has
       terminated (options include lockf() or fcntl(F_SETLK)).
       
My personal vote would be for method 3 as it is guaranteed to work for
all cases that the middleware supports (local, remote, filesystem-independent
(in the case of the locking solution), windowing-system-independent
(works for Bonobo object servers that are non-visual)). It also deals
with the possibility of a hanging client, which method 1 and 4 do not.

Hope this helps!

Colm.

>Delivered-To: gnome-components-list gnome org
>To: Darin Adler <darin eazel com>
>Cc: Michael Meeks <michael ximian com>, Maciej Stachowiak <mjs eazel com>, 
Miguel de Icaza <miguel ximian com>, <brian cameron ireland sun com>, Gnome 
Components <gnome-components-list gnome org>, Brian Cameron 
<Brian Cameron Sun COM>
>Subject: Re: Serious Bonobo Problem for Sun
>From: Soeren Sandmann <sandmann daimi au dk>
>User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7
>MIME-Version: 1.0
>X-BeenThere: gnome-components-list gnome org
>X-Loop: gnome-components-list gnome org
>X-Mailman-Version: 2.0beta5
>List-Id: component/document model <gnome-components-list.gnome.org>
>
>Darin Adler <darin eazel com> writes:
>
>> I suspect you're wrong. While fixing this problem in oafd also sounds
>> important, the additional processes themselves are also a major problem.
>> These server processes are accumulating dead objects inside them and the
>> processes will never die and just keep getting bigger each time a host
>> process is terminated.
>> 
>> And this "abnormal termination" includes the cases where the user kills the
>> process from the session manager, or uses kill, or Ctrl-C. I think the
>> underlying problem must be fixed.
>
>Doesn't both JavaEB and DCOM (or is it COM+? -- I can never remember
>the difference) handle this with leases instead of ref-counting?  That
>is, a client requests that the server stays alive for, say, two
>minutes, and then, after two minutes, the client must either renew its
>lease, or the CORBA reference to the server will (potentially) become
>invalid.
>
>With a simple g_timeout_add (2 min, renew()), this would take care of
>garbage collection when clients die.  This doesn't solve the problem
>that cycles in the component graph are bad, nor will it solve problems
>with connections going down (but this is less of a problem when client
>and server live on the same machine).
>
>_______________________________________________
>gnome-components-list mailing list
>gnome-components-list gnome org
>http://mail.gnome.org/mailman/listinfo/gnome-components-list