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