[omniORB] oneway calls delivery sequence

[Duncan Grisby]

On Thursday 31 March, "Ivanov, Roumen" wrote:

> we have been using omniORB 3.0.3 for a long time in our implementation of
> something similar to the notification service.
> The messages have seq-numbers assigned to them and are sent using oneway
> calls from the same thread.
>  
> After migrating to omniORB 4.0.3 (all default policies and flags) I'm
> observing, that sometimes, newer messages from same client come on the other
> side after older ones.

[...]
> This happens only when a bunch of messages has been sent.
> Indeed I still could not confirm on which side this happens.
>  
> Guessing something, I tried setting maxGIOPConnectionPerServer = 1 for both
> sides, but it didn't help.
>  
> Reading the CORBA specification I couldn't find anything, that confirms or
> negates some sequence break for oneway calls.

There are no guarantees about the ordering of oneways (or even if
they're delivered at all). What you're seeing is that omniORB has chosen
to use a different thread to service some of the oneways, meaning they
come out of order. In general you shouldn't rely on strict ordering of
oneways, but you can get back the old omniORB behaviour by using the
thread per connection model, and setting maxServerThreadPerConnection = 1.

Cheers,

Duncan.

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