On Tue, 22 May 2001, Rickard Öberg wrote:
> Hi!
>
> [EMAIL PROTECTED] wrote:
> > Could you send a small page ( and the taglibs ) and the test conditions ?
>
> I have sent taglib+page and test conditions to Costin.
Thanks, I'll try to add it to the tests dir.
>
> > We know the pool is synchronized and that may create problems under heavy
> > load, and we know how to fix this ( by using a per/thread pool without
> > synchronization ).
>
> That is one solution, but what do you do with the pool after page
> request?
I'm not sure I understand. Each thread has a number of associated objects
that are recycled and reused - a Request object will "stick" with a
thread.
Same can be done for the tag pools - except that this may use a lot of
memory ( but less than allocating/freeing ). It is possible to use a
middle ground, or tune this - but for maximum performance you can have a
local pool in each Request.
> I hope that Costin will be able to reproduce what I found.
I hope not :-)
Again - thanks for doing the tests and checking the code, and hope to see
more contributions and maybe few patches :-)
> I had a quick chat with the JRockit guys (the server JVM dudes) last J1,
> and they went "Waaah!" when I told them that JBoss pools EJB instances.
> The JVM would do a much better job with it in their opinion. If that's
> true or not I don't know, but I have seen other statements like that
> from other people.
IMHO the right answer is "depends". And it depends on the actual use case,
on how many objects are created and where the synchronization occurs. For
tomcat, where we expect hundred of concurent requests and each would
create almost a hundred object ( that was the case in 3.0 ) - I doubt any
VM could make a difference.
Costin
