[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=13343639#comment-13343639 ] 

Bela Ban commented on JGRP-2150:
--------------------------------

In pseudo-code, this could look like this (similar code for single messages):

{code:java}
final AtomicInteger counter=new AtomicInteger(0);
void add(MessageBatch batch) {
    int size=batch.size();
    if(counter.getAndAdd(size) == 0) {
        do {
            if(batch != null) { // initial batch
                  deliver(batch);
                  batch=null;
            }
            else {
                batch=table.remove();
                if(batch == null) --> continue
                size=batch.size();
            }
        } while(counter.decrementAndGet(size) != 0);
    }
    else {
         table.add(batch); // queues batch
         return;
    }
}
{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)