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

Bela Ban created JGRP-1577: ------------------------------ Summary: 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