[jboss-jira] [JBoss JIRA] Commented: (JGRP-1043) UNICAST: high contention

[Brian Stansberry (JIRA)]

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

Brian Stansberry commented on JGRP-1043:
----------------------------------------

As discussed on our chat, a semi-related issue is if a retransmission of a message that's already been acked comes in to a receiver, the receiver acks it resulting in an ack messages with a seqno lower than the highest. When that ack is received the current AckSenderWindow.ack will reset it's "lowest" field to that lower seqno, with the result that the *next* normal ack will loop a lot trying to remove already removed entries. The following is a potential impl that handles this:

    /**
     * Removes all messages <em>less than or equal</em> to seqno from <code>msgs</code>, and cancels their retransmission.
     */
    public synchronized void ack(long seqno) {
        if(lowest == 0) {
            Long tmp=getLowestSeqno();
            if(tmp != null)
                lowest=tmp;
        }
        
        if (seqno >= lowest)
        {
           for(long i=lowest; i <= seqno; i++) {
               msgs.remove(i);
               retransmitter.remove(i);
           }
           lowest=seqno +1;
        }
        else
        {
           // We already received an ack for a higher seqno; this should
           // be an ack for a retransmission. We should have already
           // cleaned up when we got the higher seqno ack, but as a
           // second line of defense, do it again
           msgs.remove(seqno);
           retransmitter.remove(seqno);
        }
    }

> UNICAST: high contention
> ------------------------
>
>                 Key: JGRP-1043
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1043
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.6.13, 2.8
>
>
> If UNICAST receives a high number of messages *and* sends a high number of messages concurrently, there will be a lot of retransmissions. Reason is contention on 'connections', with up- and down messages accessing it concurrently. Both up- and down- messages impede each other and thus messages are not received in time, causing retransmissions (ACKs to be resent).
> SOLUTION:
> #1 Reduce contention and turn 'connections' from HashMap into ConcurrentHashMap
> #2 Break 'connections' into a send-table and receive-table: sends and acks access the send-table, receives the receive-table

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira