[omniORB] oneway operations

[Duncan Grisby]

On Monday 5 February, jnye@micro-optics.com wrote:

> The description of what I was doing and what I observed:
> I have set up a publish/subscribe system where events get sent to a
> dispatcher and the dispatcher will forward them to all registered consumers
> (similar to an event channel). All registered consumers contain an operation
> called notify that takes a parameter of type Event (a struct with lots of
> interesting goodies). This operation was originally coded as oneway. When
> running both the publisher and the consumers on one machine, the consumers
> received all events. When running them on separate machines, the consumers
> did not receive any events. When the operation was changed to be a normal
> operation, all consumers received all events.

That should not have happened. omniORB sends oneways using a normal
TCP send, so TCP should ensure that the message really gets there,
doing retries if necessary. You should almost never lose a oneway, no
matter where the client and server are located.

There are one or two circumstances where a oneway can be lost, in a
way that omniORB cannot detect. Consider the case where a client sends
a oneway request and, while it is in-flight, the server decides to
close the connection. Some time after it has finished sending the
oneway, the client receives a close connection message, and the TCP
connection is dropped. omniORB has no way to know whether the oneway
was received before the connection was closed, or whether it was lost.

This means that you should not use oneways for messages which are
essential, since there is always a small risk that they will vanish.

I don't know why you are losing all your oneways. Try running client
and server with -ORBtraceInvocations -ORBtraceLevel 30, and look at
what's going on.

Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --