[
https://jira.jboss.org/jira/browse/JGRP-1132?page=com.atlassian.jira.plug...
]
Bela Ban commented on JGRP-1132:
--------------------------------
A possible solution is to use a tombstone, which is a special instance of Message. When a
message is removed, we don't remove it but call replace() on the ConcurrentHashMap,
and replace the value with a tombstone.
We also maintain a counter lowest_tombstone, which keeps track of the lowest tombstone
that can safely be removed, without gaps in the seqno sequence. Method remove() removes
all messages with a tombstone as value (CHM.remove(key, val, expected_val), up to
next_to_remove -1.
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