[jboss-jira] [JBoss JIRA] Commented: (JGRP-1104) NAKACK: revisit critical path
[
https://jira.jboss.org/browse/JGRP-1104?page=com.atlassian.jira.plugin.sy...
]
Bela Ban commented on JGRP-1104:
--------------------------------
OK, so I took a long look and agree with you that these changes are indeed warranted.
I made the following changes:
- undelivered_msgs is gone
- After adding an OOB message, we don't call removeOOBMessages() [1 less lock to
contend for !], and we don't call hasOOBMessages() [also 1 less lock !]
- The timer thread is not used anymore to propagate OOB messages up the stack. This
didn't impact performance, so why use a precious resource such as timer threads...
Preliminary tests show that performance is just a *tad* better than with the existing
code, but the changes made the code more compact. So this is good; as a matter of fact,
any chance that reduces code complexity and doesn't decrease performance is good !
:-)
I need to run some more perf tests (on my cluster @ home, and it the ATL lab) tomorrow to
see if I get the same perf values.
NAKACK: revisit critical path
-----------------------------
Key: JGRP-1104
URL: https://jira.jboss.org/browse/JGRP-1104
Project: JGroups
Issue Type: Task
Affects Versions: 2.8
Reporter: Vladimir Blagojevic
Assignee: Bela Ban
Fix For: 2.11
Attachments: websession_benchmark.jps
Revisit NAKACK#handleMessage and see if we can:
a) lower contention on NRW lock by not attempting to propel up oob messages one-by-one
I have no profiling data so I am speaking without a solid proof to back my claims. I am
envisioning both oob and regular threads contending for a window as they push messages up
the stack. oob threads are always going to attempt to lock per message (line 788). In an
event that we received missing oob message in a series of oob messages we are going to
repeatedly lock window per message traversed. Not good. We don't need this IMHO. I
really like lock efficient removeMany algorithm. Let removeMany propel messages up the
stack as much as possible, even oob messages.
b) why are we propelling oob messages on a timer (line 833)? Is it to lower the workload
of the current thread, or is there a more fundamental reason?
c) undelivered_msgs is complicating things unnecessarily IMHO. Why don't we let oob
threads go into removeMany code and remove as much messages as they can - both oob and
regular and push them up rather than lock NRW per message?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira