[jboss-jira] [JBoss JIRA] Commented: (JGRP-1043) UNICAST: high contention
[
https://jira.jboss.org/jira/browse/JGRP-1043?page=com.atlassian.jira.plug...
]
Bela Ban commented on JGRP-1043:
--------------------------------
ack() has been changed to:
public void ack(long seqno) {
long prev_lowest=0;
synchronized(this) {
if(seqno < lowest) return; // not really needed, but we can avoid the max()
call altogether...
prev_lowest=lowest;
lowest=Math.max(lowest, seqno +1);
}
for(long i=prev_lowest; i <= seqno; i++) {
msgs.remove(i);
retransmitter.remove(i);
}
}
#1 Synchronization is only around setting lowest to max(lowest, seqno+1), so removal from
the messages hashmap and the retransmitter is concurrent
#2 'lowest' always goes up, never down, saving us unneeded iterations
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