marc fleury wrote:
> 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...
This is a good test because it shows worst case, but can it be called a
realistic test? I'm only bringing this up because, well, if I saw
somebody with an application designed such that every user had to share
a single synchronized object, I'd say "well, yah, that'll perform fer
shite!"
>
> :(
>
> anybody ELSE seen this? I am almost leaning towards TOTALLY removing the
> passivating caches and associated mutex logic as is
It does look like the behavior people have been complaining about. I'd
not be in favor of permanently removing the passivating caches, however
- making them non-default, sure, rewrite them absolutely, but they
really have to be available for truly large installations. Truly large
installations (running over N terabyte databases) will still need memory
management. No that's not a typical installation, but don't you want to
be able to support it?
>
> 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
