Should the bus be able to deliver OOM on replies?

[Havoc Pennington]

On Thu, 2004-03-11 at 19:00, Richard Hult wrote:
> 
> In order to beef up the bus tests, I added to the message dispatch test
> to make it send an Echo method and check for a reply.
> 
> After sending the Echo message, the client occasionally gets no reply
> back from the bus, due to OOM failures. I'm wondering whether the bus
> should be able to reply with an OOM error

This could be done easily enough by adding a preallocated OOM reply to
BusPendingReply, at some efficiency cost. I don't think we should do
this though, see below.

>  or if a reply could
> (correctly) be lost in those cases, leaving it to the client side in all
> cases to generate a synthetic timeout, instead of getting an OOM error
> from the bus.

This is a pretty ugly case, since the method call has in fact been
processed, it's just that there's no memory to return the results over
the bus.

I'm not sure there's a right thing to do so we may as well do the simple
thing, let the client side just time out. If the server side wanted to
retry sending the reply it could, though I don't imagine any real app
ever will.

> Either way, I think we probably need a variant of the test utility
> function block_connection_until_message_from_bus() that times out,
> otherwise the tests will just hang when that happens.

Yep, with the danger that it could conceal genuine bugs... there are
lots of bugs that could cause a lack of reply. Maybe some hack to set a
"reply isn't going to come" flag on the server side when it gets this
specific OOM - that would also speed the tests up by avoiding the
timeout ;-)

Havoc