This forum has been archived. Please start a new discussion on GitHub.

Equivalent of TAO's buffered twoway?

The Event Distribution Performance comparision includes a comparison
of Ice's batchOneway and TAO's buffered twoway. Unfortunately,
batchOneway, like simple oneway, does not seem to guarantee delivery
order under stress. Is there a way to get ordered delivery with the
performance gain implied by batching/buffering?


  • matthew
    matthew NL, Canada
    No, there is no way to do this directly in IceStorm. However, its pretty easy to do it yourself by sending sequences of data.

    If you have a commercial need for this please contact
  • I'm not sure I understand - are you suggesting that we bypass IceStorm entirely
    if we want ordered batched delivery of events (effectively writing our own IceStorm
    replacement) or attaching a sequence id to events through IceStorm so the
    subscriber can defer internal delivery of items that have a too-high sequence id,
    in hopes that the lower ones will show up soon?

  • matthew
    matthew NL, Canada
    No, what I was suggesting is that if you have a method such as

    void sendTelescopeUpdate(Position pos);

    then you could instead have

    sequence<Position> PositionSeq;
    void sendTelescopeUpdate(PositionSeq pos);

    I realize that this is some additional burden on the application, and therefore might not be ideal. If this is a pain and you would rather have an IceStorm specific solution then I refer to my later suggestion :)
  • benoit
    benoit Rennes, France
    Although we indeed don't have anything equivalent to TAO buffered twoway requests as Matthew pointed out, if your concern with batch oneway is only about the risk to receive out of order updates, it's possible to prevent this from happening.

    This is described in the Ice manual, section 30.11 "Oneway invocations" (and this applies for batch oneways as well). In short, you need to configure the thread pool of your subscriber to only have one thread (or use a dedicated object adapter with a thread pool of one thread for your subscriber object). You have the guarantee that your batch of oneway requests won't be re-ordered if there's only one thread to read the incoming batchs over the connection.

    Let us know if you need more information!

  • You can find an FAQ about oneways and out-of-order dispatch here: