Re: Serious Bonobo Problem for Sun

[Darin Adler <darin eazel com>]

on 4/4/01 7:54 AM, Michael Meeks at michael ximian com wrote:

>       Ok, so, there are several problems here. The first problem is
> built into the referencing scheme. An object has a reference count, but
> this contains no concept of ownership whatsoever. ie. it is impossible to
> tell who owns the 5 references it has. Consequently if someone comes
> along, references the server and then crashes or just leaks the reference,
> there is no possible way to detect this.

That's true in theory, but not in practice. In practice, the Bonobo objects
we serve have a single owner. For example a Control has its control frame.
While in theory other objects can be holding references, the reference count
really does us no good here. A control without its control frame is usually
not a useful thing to have.

>       Looked at from another angle, a process can be serving 10 other
> processes with controls. Should 1 process die, it is not correct to go
> round killing all the processes that it communicated with - even if this
> were possible.

Of course you wouldn't want to kill the process, but you'd want to kill the
objects owned by objects in the dead process. Then the server process would
go away on its own if it's not serving 10 other processes.

>       Consequently, in the case of pathalogical component failure, it
> will be the case that we get process leaks. The only solution to this is
> to minimise the liklihood of component failure.
> 
>>  This may not be a serious problem for single user machines, but on
>> multi-user servers this quickly becomes critical.  We have seen
>> multi-user servers with hundreds and sometimes thousands of oaf
>> processes left behind,
> 
>       Now, I suspect that the more telling problem is that AFAIK oafd
> doesn't time out after a while and shut down - and oafd can chew some
> serious resources ~ 1Mb + per process on my system.
>
>       So, I suspect that 'oafd' proliferation is the real problem -
> could this be the case ? in which case we need to ensure that it shuts
> itself down after a while [ this may already have been done ].

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.

>> In both cases, the Bonobo architecture should be robust enough to
>> handle the situation.  When the program that launched the oaf process
>> exits (whether by choice or by crash), the oaf processes should
>> recognize this and quit.
> 
>       I agree that oafd should timeout after a while and exit.

Maciej told me that he is planning to fix this so that oafd will exit if
it's not handling any processes after a timeout (as gconfd does). But oafd
can't time out and quit if it thinks there are active server processes that
it needs to continue to monitor and pass out references too. (Right?) It can
only time out if it thinks the objects are all gone.

>> It would be very useful if we could ship a version of Bonobo without
>> this problem with the Sun version of Gnome 1.4.  If it is possible to
>> correct this problem in the very near future, then perhaps we could
>> explore the possibility of doing this.  Any other ideas/suggestions
>> would be appreciated.
> 
>       It should be relatively simple in fact, a few hacks in oaf/oafd,
> but perhaps it has been done already and / or is underway; Maciej ?

I don't think your proposal (just do some hacks in oafd) will work. We'll
still have objects that think they need to stay around. How will oafd know
that they are "really dead" and it can go away?

Maybe if you make a more-specific proposal, I'll be able to figure out if
it's really workable.

    -- Darin