[jboss-jira] [JBoss JIRA] (JGRP-2150) More efficient message adding and draining
Bela Ban (JIRA)
issues at jboss.org
Thu Jan 5 11:34:00 EST 2017
[ https://issues.jboss.org/browse/JGRP-2150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13343852#comment-13343852 ]
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)
More information about the jboss-jira
mailing list