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

[Bela Ban (JIRA)]

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

Bela Ban commented on JGRP-1043:
--------------------------------

Re: 
>> 1) if(win.smallerThanNextToRemove(seqno))
 >>              sendAck(msg.getSrc(), seqno); 

The issue with changing this to 

if(!added) sendAck() 

is the following:

#1 !added means that we (1) received a seqno < next_to_remove or (2) we received a seqno > next_to_remove which has already been received. Sending an ACK for (2) is superfluous. The ACK for a message will be sent when the message is removed.

The reason for sending ACKs on *removal* is that the ACKs are received in increasing order. Even if the ACKs pass each other, this is still correct:

ACK #1 --> ACK#2: even is ACK #2 is received before ACK #1, this is OK, because both #1 and #2 were removed from the AckReceiverWindow, therefore they can be removed by the sender !

#2 The following case would break:
Say we have 1 2 3 4 [5] 6 8 9 in the AckReceiverWindow. Seqno 7 is missing and next_to_remove is 5
- We get seqno #8
- With (!added) we send an ACK for #8
- The sender removes #8 and all seqnos below #8, including #7
==> This means that retransmission for #7 will stop and we might never receive #7 !


> 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