[
https://jira.jboss.org/jira/browse/JGRP-1132?page=com.atlassian.jira.plug...
]
Bela Ban commented on JGRP-1132:
--------------------------------
This introduced a bug: the next_to_remove value and a remove() need to be executed
atomically ! This wasn't the case, so
- Thread A removing seqno 10, but *not yet* incrementing next_to_remove
- Thread B adding 10 again (duplicate seqno)
would lead to duplicate messages being delivered !
For now, I'm re-adding locks around next_to_remove updates (and removes, for
example).
Revisit in 2.10 to see if we can achieve this without locks
AckReceiverWindow: make non blocking
------------------------------------
Key: JGRP-1132
URL:
https://jira.jboss.org/jira/browse/JGRP-1132
Project: JGroups
Issue Type: Task
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.9
Remove the lock acquired by AckReceiverWindow on adds and removes. Use a
ConcurrentHashMap to make these operations non-blocking (well, besides the write lock on a
CHM segment).
This should yield better perf
--
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