[ https://issues.jboss.org/browse/JGRP-2140?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2140: --------------------------- Description: Table does allocate memory on resizing or compaction; whereas RingBuffer doesn't. Replacing Table with RingBuffer might bring memory allocation rates even further down. However, using RingBuffer as message store means that the capacity is fixed; when the RingBuffer is full, sender threads would have to block as messages cannot be dropped. However, blocking is something that should be done in a flow control protocol, such as {{UFC}} or {{MFC}}, and some applications might choose completely non-blocking flow control, e.g. {{UFC_NB}} or {{MFC_NB}}, and blocking in {{UNICAST3}} or {{NAKACK2}} would move part of the blocking/non-blocking aspect away from the flow control protocols. Measure the impact on performance. Table is a critical class used by NAKACK2 and UNICAST3, and is battle tested. Do this only if the benefits trump the risk. was: Table does allocate memory on resizing or compaction; whereas RingBuffer doesn't. Replacing Table with RingBuffer might bring memory allocation rates even further down. However, using RingBuffer as message store means that the capacity is fixed; when the RingBuffer is full, sender threads would have to block as messages cannot be dropped. Blocking is actually something that should be done in a flow control protocol, such as {{UFC}} or {{MFC}}, and some applications might choose completely non-blocking flow control, e.g. {{UFC_NB}} or {{MFC_NB}}, and blocking in {{UNICAST3}} or {{NAKACK2}} would move part of the blocking/non-blocking aspect away from the flow control protocols. Measure the impact on performance. Table is a critical class used by NAKACK2 and UNICAST3, and is battle tested. Do this only if the benefits trump the risk. -- This message was sent by Atlassian JIRA (v7.2.3#72005)