[ https://issues.jboss.org/browse/JGRP-2417?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2417: --------------------------- Description: When users do their own memory management, the message passed to {{Channel.send()}} might have a reference to a memory area that's allocated from a pool, and that needs to be returned when done. However, {{Channel.send()}} does not necessarily mean that the memory area can be reused. If, for example, NAKACK2 or UNICAST3 have the message in their retransmission tables (to potentially retransmit it), then the memory cannot be reused until that message has been purged from the retransmission table. Add a reference-counting mechanism to {{Message}} (implemented in {{BaseMessage}}) that allows NAKACK2 or UNICAST3 to increment a ref-count. When a message is purged from the retransmission table, decrement its ref-count. When the ref-count is 0, a callback could be called. The callback could for example return the associated memory chunk back to the memory pool. This could possibly be a trait, with a no-op implementation as default. This could be overwritten, ie. {code:java} Message release() { if(refcount <= 0) // give associated memory area back to pool } {code} See if this needs to be integrated with {{MessageFactory}} as well. was: When users do their own memory management, the message passed to {{Channel.send()}} might have a reference to a memory area that's allocated from a pool, and that needs to be returned when done. However, {{Channel.send()}} does not necessarily mean that the memory area can be reused. If, for example, NAKACK2 or UNICAST3 have the message in their retransmission tables (to potentially retransmit it), then the memory cannot be reused until that message has been purged from the retransmission table. Add a reference-counting mechanism to {{Message}} (implemented in {{BaseMessage}}) that allows NAKACK2 or UNICAST3 to increment a ref-count. When a message is purged from the retransmission table, decrement its ref-count. When the ref-count is 0, a callback could be called. The callback could for example return the associated memory chunk back to the memory pool. This could possibly be a trait, with a no-op implementation as default. See if this needs to be integrated with {{MessageFactory}} as well. -- This message was sent by Atlassian Jira (v7.13.8#713008)