[omniORB] Re: oneway callback gets lost

[Jonathan Biggar]

Duncan Grisby wrote:
> 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.

Actually, it's an issue of a design choice in omniORB.

> 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.

You designed omniORB to not have anything actively listening for input 
on the client side of a connection unless there is an outstanding 
two-way request.  (I'm ignoring bidir connections for now.)

That's a reasonable design choice, but it has the downside of the 
behavior you describe.  It's not really a flaw in the underlying CORBA 
specification.

-- 
Jon Biggar
Levanta
jon at levanta.com
650-403-7252