[omniORB] oneway callback gets lost

[Serguei Kolos]

Hi Duncan

Thank you for the explanation but I would tend to agree with Jonathan. 
Correct me if I'm wrong
but it looks like the Close Connection procedure works fine if it is 
initiated by a "client" application
and does not run to completion leaving connection in half-closed state 
if it is initiated by a "server".
The worst thing is that an application starts behaving incorrectly when 
some omniORB options
(like scanGranularity) are set to valid and reasonable values, i.e. the 
functional behavior of an
applications depends on those options.

Cheers,
Sergei

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