[jboss-jira] [JBoss JIRA] Commented: (JGRP-1043) UNICAST: high contention

[ https://jira.jboss.org/jira/browse/JGRP-1043?page=com.atlassian.jira.plug... ] Bela Ban commented on JGRP-1043: -------------------------------- Re: Further to the issue of contention for AckReceiverWindow.msgs The reason for ack'ing OOB messages directly, instead of later with the regular message processing, is that if the OOB thread returns, there won't be an ACK for that message. As a matter of fact, if we have a lot of OOB messages, and no regular message for a while, there would be a large number of unacked OOB messages. Re: use of processing to determine whether to call win.removeOOBMessage() The 'processing' AtomicBoolean needs to be changed while holding the AckReceiverWindow.msgs lock, or else we can end up with messages left in the AckReceiverWindow, as follows (AckReceiverWindow.remove(AtomicBooloean): /** * We need to have the lock on 'msgs' while we're setting processing to false (if no message is available), because * this prevents some other thread from adding a message. Use case: * <ol> * <li>Thread 1 calls msgs.remove() --> returns null * <li>Thread 2 calls add() * <li>Thread 2 checks the CAS and returns because Thread1 hasn't yet released it * <li>Thread 1 releases the CAS * </ol> * The result here is that Thread 2 didn't go into the remove() processing and returned, and Thread 1 didn't see * the new message and therefore returned as well. Result: we have an unprocessed message in 'msgs' ! * @param processing * @return */ Let's discuss this tomorrow -- 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