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.

> 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?

> That was planned for later, in jasper34 space - but if you send code that
> shows a significant degradation in performance in some reasonable
> situations we can still fix it in 3.3.

I hope that Costin will be able to reproduce what I found.

> Regarding the default - I think it should be enabled, mostly because that
> will require people to make sure their taglibs are working corectly in a
> pooled environment. It should be possible to disable it on a per
> application basis, and we need to make sure we document how to do that.

I agree.

> I don't think the design is bad - just the implementation of the pool, but
> this is the first attempt with the goal of making sure the pooling work,
> optimizations will come later. The current experience with tomcat
> performance evolution from 3.1 to 3.3 shows that recycling objects has a
> huge effect ( if implemented corectly ) - and I see no reason why jasper
> would be different. 

Agree, object reuse can have nice effects. But the hash+sync overhead
must be balanced against the benefits of the actual object reuse.

> I'm looking forward to the VM where the allocation and
> GC will be free ( so far most do synchronize on object allocation ).

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.

/Rickard

-- 
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Email: [EMAIL PROTECTED]

Reply via email to