marc,
You should try this on some other OSes. I believe that the sun vm on linux
uses a one-to-one mode (one java thread to one native thread). This model
has problems with thread contension becase all thread contension is resolved
in the kernel which has to pass through the native layer. Other OSes have
different models and different performance behivor. The point I'm
attempting to make is you may be optimizing for one jvm implementation for
one version of the os. (As a side note RedHat is rumored to have a bad
version of the thread libs)
I think the important question is "Why do we have a passivation cache?" Why
did we add it and is the circumstances that led us to add it still valid. I
often find optimiztions in my client's code for situations that simply are
not a problem any more. Optimizations make code more difficult to read and
therefore maintian. (By the way, we could make a arument along the lines of
scaleability vs. performance of a single instance)
I am all for making the code as simple a possible,
-dain
----- Original Message -----
From: "marc fleury" <[EMAIL PROTECTED]>
To: "Jboss-Development@Lists. Sourceforge. Net"
<[EMAIL PROTECTED]>
Sent: Monday, June 25, 2001 11:17 AM
Subject: [JBoss-dev] High load...
> I am about to commit an MBean / EJB pair whose only purpose in life is to
> stress the cache locking logic.
>
> Because it is an MBean it never goes through the RMI layers and so we are
> seeing RAW performance of the logic that does the thread mutex semaphore
and
> all taht... that was the part I had to optimize when I went to SUN... now
> with the new logic 50 threads all pinging on 1 object.
>
> on my new athlon it crawls to an halt at 50 clients in parallel (they wait
> 100ms before pinging again) and there is almost no invocation going
> through...
>
> :(
>
> anybody ELSE seen this? I am almost leaning towards TOTALLY removing the
> passivating caches and associated mutex logic as is
>
> Ok I will say the word... this is shite ...
>
> or is it just me?
>
> marcf
>
> _________________
> Marc Fleury, Ph.D
> [EMAIL PROTECTED]
> _________________
>
>
>
> _______________________________________________
> 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
