AW: Tag Pooling ( was: Re: DO NOT REPLY [Bug 16001] - Tag.rel ease() not invoked

[Torsten Fohrer <To...@dcsi.de>]

on option, can it be minimize the synchronized calls, as a example.

1. Removing synchronized methods in TagPool
2. Adding a synchronize block on top of the jspService method, that get all
needed tag instances
3. normal using the instances
4. Adding a synchronize block in finally block to put back the tag instances

this can simply extended to support tagpool per unique tag/attribute
combination in the same context.


Torsten Fohrer

> -----Ursprüngliche Nachricht-----
> Von: Costin Manolache [mailto:cmanolache@yahoo.com]
> Gesendet: Dienstag, 21. Januar 2003 01:08
> An: tomcat-dev@jakarta.apache.org
> Betreff: Tag Pooling ( was: Re: DO NOT REPLY [Bug 16001] - 
> Tag.release()
> not invoked
> 
> 
> Taking Glenn's post out of thread:
> 
> 
> Glenn Nielsen wrote:
> 
> > Per JSP Page (current)
> > ----------------------
> > 
> > The current tag pool manages one or more pools of tags on a per JSP
> > page basis. With a synchronized method call for each get/reuse pair
> > for a TagHandler used in the page. That page could have as 
> many current
> > requests as Processor threads.  The TagHandlerPool's for 
> the JSP page
> > could grow to the point where they have as many TagHandler elements
> > as needed to handle the maximum number of concurrent 
> requests (Threads).
> 
> If we're going to keep the current around - we should at 
> least increase
> the limit. 
> 
> 
> 
> > Per JSP Page Thread Local
> > -------------------------
> > 
> > Switching this to ThreadLocal would remove all need for synchronized
> > access for the TagHandlerPool get/reuse but significantly 
> increase the
> > memory usage. You end up with a TagHandlerPool for each 
> thread, for each
> > JSP page.
> > 
> > Both of these could require enoubh memory to hold the 
> number of TagHandler
> > classes = Number of Threads * Number of JSP pages * Number of unique
> > TagHandlers needed per JSP
> 
> A mechanism to clean up unused pools could help reduce this ( 
> similar with 
> ThreadPool ). ( maybe combined with some JMX to give insight 
> into how many 
> pools and tags are in used - quite usefull ).
> 
> This is the classical "memory versus time" - a choice that 
> users should make
> for themself, depending on the application they run. A 
> production site with 
> a lot of memory and very high traffic on few pages may choose 
> the speed.
> 
> 
> > There are two other options based on managing a global tag 
> pool rather
> > than
> > a per JSP page tag pool.  If you have many JSP pages with 
> custom tags
> > there
> > will be common tags/attributes used across all of them.  
> Why not be able
> > to reuse these TagHandler's across all the JSP pages 
> instead of on a per
> > JSP page basis. This could significantly reduce the number 
> of instances of
> > TagHandler's
> > which have to be pooled, and the memory the consume.  
> Consider the JSTL
> > c:if tag and how many times it could get used across 20 
> different JSP
> > pages.
> 
> If this is still thread local - I'm +0 ( i.e. I won't 
> implement it, but
> I think it's a great idea ).
> 
> That would make it ( threads * maxTag ), where maxTag is the 
> maximum number
> of one tag in any page. 
> 
> It shouldn't be hard - you'll need to pass the context and keep the
> ThreadLocal in the context.
> 
> Of course - keep in mind that you need one pool for each 
> tag+attribute_set
> ( another wise requirement..)
> 
> 
> > Global
> > ------
> > 
> > TagHandlerPool's which are global and pool all unique 
> TagHandler classes
> > for all JSP pages. In this case you would require one 
> synchronized call at
> > the start of the JSP page to populate its local pool with reusable
> > TagHandler's from the global pool. Then on JSP page exit return the
> > TagHandler's from its local pool to the global. Requires 
> two synchronized
> > method calls per JSP page execution, but mimimizes the 
> memory footprint of
> > pooled tags.
> 
> If by global you mean cross-context - I don't think it would work ( 
> versioning, security, etc ).
> 
> 
> > 
> > Global Thread Local
> > -------------------
> > 
> > TagHandlerPool's which are global within a thread and pool 
> all unique
> > TagHandler classes for all JSP pages which execute within 
> the thread. No
> > synchronized methods
> > would be required for this design.  This would have a smaller memory
> > footprint than the Per JSP Page (current) and Per Jsp Page 
> Thread Local
> > tag pools, but use more memory than the Global tag pool.
> 
> Again - if by global you mean per context, +1. Per server is 
> too dangerous
> ( a thread can hold on the reference for a tag and access it 
> when it is 
> in used in a different context ).
> 
> 
> > Of the four designs above I think the Global Thread Local 
> design may be
> > the best. It removes the need for synchronized get/reuse 
> and has a smaller
> > memory footprint than the Per JSP Page tag pool design.
> 
> +1 for Context Thread Local ( eventually combined with some expiration
> strategy ).
> 
> 
> Costin
> 
> 
> --
> To unsubscribe, e-mail:   
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>