[jboss-jira] [JBoss JIRA] (JGRP-2150) More efficient message adding and draining

[Bela Ban (JIRA)]

    [ https://issues.jboss.org/browse/JGRP-2150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13346532#comment-13346532 ] 

Bela Ban edited comment on JGRP-2150 at 1/11/17 9:23 AM:
---------------------------------------------------------

Unfortunately, the above two algorithms are incorrect! 

I modeled them in TLA+ and the problem is that we can have multiple consumers... Well, this isn't a problem for MaxOneSenderPerThreadPolicy, but it would destroy the FIFO semantics in NAKACK2 and UNICAST3, where only 1 message (or batch) per sender is delivered at a time!

See \[1\] for details. \[2\] contains the correct solution.

\[1\] https://github.com/belaban/pluscal/blob/master/MessageBatchDrainTest2.tla

\[2\] https://github.com/belaban/pluscal/blob/master/MessageBatchDrainTest3.tla


was (Author: belaban):
Unfortunately, the above two algorithms are incorrect! 

I modeled them in TLA+ and the problem is that we can have multiple consumers... Well, this isn't a problem for MaxOneSenderPerThreadPolicy, but it would destroy the FIFO semantics in NAKACK2 and UNICAST3, where only 1 message (or batch) per sender is delivered at a time!

See \[1\] for details. \[3\] contains the correct solution.

\[1\] https://github.com/belaban/pluscal/blob/master/MessageBatchDrainTest2.tla

\[2\] https://github.com/belaban/pluscal/blob/master/MessageBatchDrainTest3.tla

> More efficient message adding and draining
> ------------------------------------------
>
>                 Key: JGRP-2150
>                 URL: https://issues.jboss.org/browse/JGRP-2150
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>              Labels: CR1
>             Fix For: 4.0
>
>
> In NAKACK2, UNICAST3 and in MaxOneThreadPerSenderPolicy, we have a pattern where one or more producers add messages (to a table in NAKACK2 and UNICAST3, or to a MessageBatch in MaxOneThreadPerSenderPolicy) and then only *a single thread* can remove and deliver messages up the stack.
> This requires synchronization around (1) determining the thread which will remove messages, (2) adding messages to the table (or batch) and (3) removing messages from the table or batch.
> Unit tests DrainTest and MessageBatchDrainTest show how a simple AtomicInteger can be used to do this.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)