[jboss-jira] [JBoss JIRA] Commented: (JGRP-1043) UNICAST: high contention
Brian Stansberry (JIRA)
jira-events at lists.jboss.org
Fri Sep 11 15:49:36 EDT 2009
[ https://jira.jboss.org/jira/browse/JGRP-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12485416#action_12485416 ]
Brian Stansberry commented on JGRP-1043:
----------------------------------------
Further to the above comment, the issue of setting "lowest" to a lower number doesn't just apply to the case of acks of retransmissions. ACKs are issued in sequence, but very well may not be received in sequence.
For anyone watching this JIRA, please understand that the issue I'm discussing on this/previous comment is not the main focus of this JIRA; it's a small side aspect Bela asked me to document here.
> 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
More information about the jboss-jira
mailing list