[
https://issues.jboss.org/browse/JGRP-2150?page=com.atlassian.jira.plugin....
]
Bela Ban commented on JGRP-2150:
--------------------------------
Better algorithm for a bounded MessageBatch:
{code:java}
protected final MessageBatch batch=new MessageBatch(BATCH_SIZE);
protected final AtomicInteger counter=new AtomicInteger(0);
protected void add(MessageBatch mb) {
int size=add(mb); // adds mb to this.batch
if(size > 0)
drain(size);
}
protected void drain(int num) {
if(counter.getAndAdd(num) == 0) {
final MessageBatch delivery_batch=new MessageBatch(num);
do {
delivery_batch.reset();
removed_msgs=_transfer(delivery_batch);
cnt++;
// deliver delivery_batch
} while(counter.addAndGet(-removed_msgs) != 0);
}
}
{code}
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)