[jboss-jira] [JBoss JIRA] (JGRP-2417) Ref-counting for messages
Bela Ban (Jira)
issues at jboss.org
Thu Jan 9 07:00:45 EST 2020
[ https://issues.redhat.com/browse/JGRP-2417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bela Ban updated JGRP-2417:
---------------------------
Fix Version/s: 5.1
(was: 5.0)
> Ref-counting for messages
> -------------------------
>
> Key: JGRP-2417
> URL: https://issues.redhat.com/browse/JGRP-2417
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.1
>
>
> 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, the return of a {{Channel.send()}} call 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.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
More information about the jboss-jira
mailing list