[omniORB] Lost one-way calls

[Sai-Lai Lo]

>>>>> Helge Penne writes:

> This is all quite interesting.  If I have a server that sends oneway
> messages to a client (subscriber) at a fixed frequnecy (set by the
> subscriber), what would I have to do to make this reliable (for all
> practical purposes)?  (This question applies to omniORB 2.7.1 only, not
> to ORBs in general as specified in the standard...)

> Would I have to set disable the "incoming connection shutdown"
> (scavenger) on the client (receiver) side by setting
> idleConnectioScanPeriod to zero, or would it be enough to set this period
> an order of magnitude higher than what it is for outgoing connections on
> the sender side, as suggested by Nick Reeves in his message yesterday?

Set the idleConnectionScanPeriod to zero is my recommendation. Setting the
period to a higher value only reduce the chance of message loss but does
not eliminate the possibility of this from happening. I've explained the
reason in my previous postings.

> However, if messages are lost even if the socket connection is perfectly
> OK (ORB internal/related issues not included) and both client and server
> are alive and well, and the message is actuallu lost due to some more or
> less rare timing glitch in the ORB (as seems to be the case here), this
> can only be regarded as an ORB bug that should be carefully diagnosed and
> corrected.

As I've explained earlier, the loss of one-way messages is the price to pay
when one allows the server to unilaterally shutdown a connection. There are
ways to reduce the chance of message loss, such as increase the timeout and
make the scavenger starts counting when a request is received. But the
bottom line is these methods cannot completely eliminate one-way message loss. 
It may be possible to tune the TCP layer so that ACKs are received before
send() system call is returned but this is very much OS dependent and throw
away any benefit of throughput you may want to have with one-way calls.

The point is connection shutdown is an ORB feature than can be turned
off. And if you want reliable one-way invocation, it should be turned off.
Personally, I would prefer not to use one-way if I want reliable delivery.

Sai-Lai

-- 
Sai-Lai Lo                                   S.Lo@uk.research.att.com
AT&T Laboratories Cambridge           WWW:   http://www.uk.research.att.com 
24a Trumpington Street                Tel:   +44 223 343000
Cambridge CB2 1QA                     Fax:   +44 223 313542
ENGLAND