[omniORB] oneway callback gets lost

[Duncan Grisby]

On Thursday 8 March, Serguei Kolos wrote:

> I'm using omniORB 4.0.7 on SLC4 Linux (kernel 2.6.9-42).  I have a
> system with server and subscriber which subscribes to the server and
> periodically receives callbacks (defined as oneway method) from the
> server.  I have set the scanGranularity parameter to 0 on the server
> and I'm using default settings on the subscriber.

> I have noticed the following problem - if the server sends callback to
> subscriber and then waits for several minutes before sending another
> one then this new callback is not properly processed on the subscriber
> side and in fact it never goes to the user code. This is the ouput
> which appears on the subscriber side when the callback should have
> been received:
> omniORB: throw giopStream::CommFailure from
> giopStream.cc:838(0,NO,COMM_FAILURE_UnMarshalArguments)

It's a fundamental limitation of CORBA oneway messages.

The "server" in your case is acting in the role of a client; the
"subscriber" is the server. The client is making oneway requests to the
server, meaning that it just sends messages and never looks for replies.
After a while of sending no messages, the server closes the connection
coming from the client. Because the client is only sending oneway
messages, it doesn't notice the connection closure until the OS fails a
send() call, which can be after a large number of calls if the calls are
small.

With a two-way call, the client would notice the connection closure as
soon as it tried to get a reply, and would retry the call with a new
connection.

The reason you don't see the problem unless you set your client's
scanGranularity to 0 is that by default omniORB clients close idle
connections earlier than servers do, meaning that this situation of a
client not noticing a closed connection never occurs.

This situation is the main reason that CORBA oneways are described as
"unreliable oneways". If it is essential that calls get through, you
shouldn't use oneways, or you should add some higher-level protocol to
confirm that they are received.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --