|but there actually is NO sleep in the code, causing the thread
|to go into a tight loop, producing tons of LOCKING-WAITING
|messages and consuming up to 90% of processor time. I don't know
|why the wait was left out, maybe it was a planned feature and
|forgotten about? There was a patch suggested some month (!)
well, credit to Simone for good and bad.
good is that we have a better cache, bad is that he fucked up that mutex
with a "busy wait on ONE thread" bug.
no biggy.
|ago to reduce the amount of messages to one start message and
|one end message; this patch wasn't picked up by any developer,
|I think, because it would tigthen the loop even more (as it is,
|I believe the massive message amount leaves 10% CPU because of
|waiting for IO).
that is bad again fixable...
actually I will try to jump to the end of the stack of messages you sent see
if it is fixed... it is a tricky one as the passivation can be a b**ch to
fix...
the first version of the cache did behave correctly and that is what we
tested JBOSS with on the high end solaris machine... when I came back from
London I did read this code and saw the bug, notified Simone, he said he was
aware of it, just no time to work on it ... will work on it...
|So the correct solution for this issue would be a wait there
|and the accompanying notify/notifyAll at the place, where the
|lock is released. With that correction the LOCKING-WAITING
relax...
|message would only appear once before the wait, making the
|suggested patch unneccessary, and not eat up CPU anymore.
|I believe that this would drastically change your response
|times even when accessing the beans inside a transaction.
|
|As I havn't digged deep enough into JBoss code (and have no
|write access to CVS) I only can hope, that one of the gurus
|sees this, picks it up and fixes it.
Georg... you seem to have a good understanding... relax...
marc
|
|hope this helps
|Georg
| ___ ___
|| + | |__ Georg Rehfeld Woltmanstr. 12 20097 Hamburg
||_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10
|
|PS: Please report your stress test results on this list, I think
| both, performance for accessing the beans inside and outside
|a transaction, are very interesting.
|
|PS2: Besides, that cited code mentiones a possible deadlock in
| another comment, but there seems to be no deadlock resolving
|code. I think, this too should be addressed soon, in a real app
|with heavy load it's really likely, that deadlock can happen.
|If your test clients i.e. access the same beans in random order
|in ONE transaction (via session bean facade for instance) you
|easily should be able to run into a deadlock.
|
|
|
|_______________________________________________
|Jboss-development mailing list
|[EMAIL PROTECTED]
|http://lists.sourceforge.net/lists/listinfo/jboss-development
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
