Archived
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?
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?
0
Comments
-
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 sales@zeroc.com.0 -
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?
Thanks!0 -
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 suggestion0 -
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!
Benoit.0 -
You can find an FAQ about oneways and out-of-order dispatch here:
http://www.zeroc.com/faq/onewaysOutOfOrder.html0