Re: hang in gconfd

[Michael Meeks <michael ximian com>]

Hi Havoc,

On 9 Dec 2001, Havoc Pennington wrote:
> FWIW this has been happening (rarely) for a long time, even in gconf 1
> with ORBit 1. It is unreproduceable as far as I can tell. I asked for
> assistance with it on orbit-list once before, I think, as I have no
> idea what would cause an ORBit outgoing oneway call to stick like
> this.

        Well - it seems easily possible to me that the buffer in the
transfer process is full, and the other end is not processing the data.

        Clearly - unless you want to delay the oneway call invocation -
which as you suggest will cause:

        oneway_method (foo, ev);
        exit (0);

        Not to work [ not that this is an issue, since clearly shutdown
methods are the way to make this work ].

        Then you have to block at some stage; it is not possible to write
an inifinite amount of 'ping' data to a remote component that is not
responding (for whatever reason).

> If oneway calls can hang, then we have a big problem, because I have
> no idea how to make a server robust if any client can hang it.

        Well - oneway _helps_ avoid the server hanging; but - if, as I
suggested previously, instead of using 'ping' - you use the connection
status; available via:

        CORBA_Object_non_existant.

        you win every way; since it involves you in no CORBA method calls
to remote servers, no contexts switches to handle that data, no redundant
data going into buffers, etc. etc. etc.

        Of course - if you don't want to have a timeout sitting there
polling things, you can use ORBit_small_[un]listen_for_broken, which will
give you a notification as soon as the remote end dies - saving ugly
timeouts and less efficient polling.

>  Or if they only hang in avoidable circumstances, I'd like to know
> what those are.

        Well - when the buffer is full; as I said, writes are blocking; it
would be possible to work around this in ORBit2 with relative ease in
fact; simply marking buffers as blocking, queueing all further data on
that connection and waiting till we get an event on the socket to write
more data;

> My understanding is that is not supposed to block.

        It's not possible to make it fully non blocking without the above
ORB changes. I've put them on my TODO - but my TODO is growing in an
unbounded sort of way ... I'm happy to help point you / someone at the
bits to hack though ... it would be wonderful to have this feature.

        Regards,

                Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot