[jboss-jira] [JBoss JIRA] Resolved: (JGRP-962) NAKACK / UNICAST: verify that concurrent access to NakReceiverWindows / AckReceiverWindows is handled correctly

[Bela Ban (JIRA)]

     [ https://jira.jboss.org/jira/browse/JGRP-962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-962.
---------------------------

    Resolution: Done


Highly unlikely, but if this happens then the orphaned NakReceiverWindow will get reset on the next view change

> NAKACK / UNICAST: verify that concurrent access to NakReceiverWindows / AckReceiverWindows is handled correctly
> ---------------------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-962
>                 URL: https://jira.jboss.org/jira/browse/JGRP-962
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> In both UNICAST and NAKACK, when we merge, we update the local digests and potentially reset / remove / re-create NakReceiverWindows or Ack{Sender,Receiver}Windows. This is currently not synchronized enough, we need to synchronize correctly.
> For example, prevent the following (in NAKACK): 
> - A message M is received and the ref to win (NRW) is retrieved from xmit_table
> - The NRW is reset() and removed from xmit_table
> - However, M is inserted into the NRW because we still had a ref to it !
> - GC probably collects the NRW instance, but we should prevent this anyway...

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