[jboss-jira] [JBoss JIRA] (JGRP-1577) UNICAST / UNICAST2: add better synchronization around ReceiverEntries

[Bela Ban (JIRA)]

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

Bela Ban resolved JGRP-1577.
----------------------------

    Resolution: Migrated to another ITS


Will be done in UNICAST3 (JGRP-1589)
                
> UNICAST / UNICAST2: add better synchronization around ReceiverEntries
> ---------------------------------------------------------------------
>
>                 Key: JGRP-1577
>                 URL: https://issues.jboss.org/browse/JGRP-1577
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.3
>
>
> When A gets unicast messages from B, then A creates a ReceiverEntry in its recv_table for B. The creation (or fetching of the existing ReceiverEntry) is done under a lock, however, the adding and subsequent removal of messages is not done under a lock (well, actually, adding messages to ReceiverEntry.win is locked).
> What could happen is the following:
> * B sends messages 1,2,3 (conn-id=5)
> * B closes the connection to A
> * B sends messages 1,2,3 to A (new conn-id=6)
> * A receives messages 1,2,3 with conn-id=5
> * A grabs the ReceiverEntry for B and starts adding 1,2,3 to win
> * Messages 1-3 from B with conn-id=6 are received
> * This creates a new ReceiverEntry for B
> * A now starts removing and passing up messages 1-3 from B with the old conn-id 5
> * A receives messages 1-3 from B with conn-id=5
> * Subsequently, A also receives messages 1-3 from B with conn-id=6
> Not sure if this really constitutes a bug, but I nevertheless need to take a look.
> Possible solution:
> * Create receiverEntry for B only *once*
> * Remove ReceiverEntry for B only when the view excludes B, but *not* when B sends messages with a different conn-id
> * Instead, lock on the ReceiverEntry for B when messages are received:
> ** When a message with a different conn-id is received, only change the contents of ReceiverEntry (e.g. conn-id, reset win etc), but *don't* remove the ReceiverEntry from recv_table and create a new one

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira