[
https://jira.jboss.org/jira/browse/JGRP-1043?page=com.atlassian.jira.plug...
]
Brian Stansberry commented on JGRP-1043:
----------------------------------------
Re: !added:
DOH! Good example of why I post comments rather than change code!
is this useful?
if(!added && win.smallerThanNextToRemove(seqno))
We limit the win.smallerThanNextToRemove to cases where the message isn't the
next_to_remove. Hmm, probably not a huge benefit, unless even w/ thread pools in TP
it's still the norm that messages get added to the window in seqno order.
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