[ https://jira.jboss.org/jira/browse/JGRP-1132?page=com.atlassian.jira.plug... ] Bela Ban updated JGRP-1132: --------------------------- Fix Version/s: 2.10 (was: 2.9) -- 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

[ 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. -- 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

[ https://jira.jboss.org/jira/browse/JGRP-1132?page=com.atlassian.jira.plug... ] Bela Ban commented on JGRP-1132: -------------------------------- maybe add2() can also remove OOB messages as it already holds the lock. There would be less contention between add2() and removeOOBMessages() -- 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

[ https://jira.jboss.org/jira/browse/JGRP-1132?page=com.atlassian.jira.plug... ] Bela Ban updated JGRP-1132: --------------------------- Attachment: AckReceiverWindow.java -- 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

[ https://jira.jboss.org/jira/browse/JGRP-1132?page=com.atlassian.jira.plug... ] Bela Ban commented on JGRP-1132: -------------------------------- Chosen solution: - The lookup ConcurrentHashMap has Segments and maps seqnos to segments - A segment has an AtomicReferenceArray<Message>, and maps a seqno to an index - A Message at a given index can be null, non-null or a TOMBSTONE - Segment.add() and Segment.remove() are atomic and set an element from null --> valid message (add()), or valid message --> TOMBSTONE (remove()) - The initial lookup in the CHM still uses per-bucket locks, but most of the time these are gets: new segments are infrequently created (depends on the segment size) and old segments are infrequently removed, too - To even eliminate the lookup CHM, there are 2 pointers: one to the current segment to add a new message and one to the current segment from which to remove a message. This bypasses a CHM lookup in almost all cases and makes the ARW almost completely look-free ! -- 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