[jboss-jira] [JBoss JIRA] Commented: (JGRP-100) Large-scale JGroups

[Bela Ban (JIRA)]

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

Bela Ban commented on JGRP-100:
-------------------------------

(doc/design/largeCluster.txt)

ConcurrentHashMap
-----------------

CCHMs have a default initial capacity (16), load factor (0.75) and concurrency level (16). These are OK for most
scenarios, but we have to investigate whether these values are sufficient for 1000 node clusters.

When for example 1000 threads from different senders access the same CCHM, we need to make sure we don't have high
contention, ie. by spreading a 1000 senders over 16 buckets.

Investigate whether we should add CCHM initial sizes, load factors and concurrency levels as properties.

With ergonomics [1], we could for example set bucket sizes for CCHMs dynamically, e.g. based on cluster size.



[1] https://jira.jboss.org/jira/browse/JGRP-1037


> Large-scale JGroups
> -------------------
>
>                 Key: JGRP-100
>                 URL: https://jira.jboss.org/jira/browse/JGRP-100
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.x
>
>
> - Run JGroups on hundreds of nodes (either physical, or simulation).
> - Determine a protocol stack that can be used for large-scale execution
> - Example:
>   - Coordinator may be SPOF. If coord is hung, messages will be sent, but no new views will
>     be generated
>   - Retransmission: retransmit from anyone (not sender, otherwise we have NAK implosion)
>   - Look at PBCAST

-- 
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