[
https://issues.jboss.org/browse/JGRP-2150?page=com.atlassian.jira.plugin....
]
Bela Ban commented on JGRP-2150:
--------------------------------
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.
\[1\]
https://github.com/belaban/pluscal/blob/master/MessageBatchDrainTest2.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)