[ 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. 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. 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, messages would get dropped. This should not be a big issue as they will get retransmitted anyway, and flow control should actually kick in to throttle senders (this is done now, to prevent Table from growing out of bounds). 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)