[ https://jira.jboss.org/jira/browse/JGRP-1085?page=com.atlassian.jira.plug... ] Bela Ban commented on JGRP-1085: -------------------------------- Simply replcaing ReadWriteLocks with ReentrantLocks didn't yield better performance with perf.Test. However, one of the things we need to look at is whether we can move addition / removal to/from Retransmitter out of the lock-scopes, e.g. in add() / remove(). A correct impl of removeMany() could also yield perf improvements -- 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-1085?page=com.atlassian.jira.plug... ] Bela Ban commented on JGRP-1085: -------------------------------- For example, in NakReceiverWindow.add(), we can de-scope it like this: void add(seqno, msg) { lock: if(seqno == current): action=PUT if(seqno < current): return if(seqno > current): action=PUT_AND_XMIT else action=PUT_IF_ABSENT end-lock: switch(action): case PUT: xmit_table.put(seqno, msg) case PUT_AND_XMIT: xmit_table.put(seqn,msg) / retransmitter.put(seqno) case PUT_IF_ABSENT: if xmit_table.putIfAbsent(seqn, msg) --> retransmitter.remove(seqno) } The work inside the lock scope is only to determine what to do with the message, the real (and costly) work is done *outside* the scope, so we can have more concurrent add() invocations. Same for NakReceiverWindow.removeMany(): - Determine in the lock scope how many messages we can remove (add them to a list and add the seqnos of messages to be discarded from the xmit_table to a different list. - After the lock-scope: remove all seqnos from xmit_table (if any) and return list TODO: write a test which only uses NakReceiverWindow and measures how long it takes to insert 1 million messages. With the changes above, this should be faster ! -- 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-1085?page=com.atlassian.jira.plug... ] Bela Ban commented on JGRP-1085: -------------------------------- Further optimization in NAKACK: - When sending a message in down(), we always grab the NakReceiverWindow for local_addr - A ref to the window can be cached, so we can eliminate the Map.get(local_addr) altogether -- 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-1085?page=com.atlassian.jira.plug... ] Bela Ban resolved JGRP-1085. ---------------------------- Resolution: Done removeMany() was done in https://jira.jboss.org/jira/browse/JGRP-1091 -- 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