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:[EMAIL PROTECTED]] > Gesendet: Dienstag, 21. Januar 2003 01:08 > An: [EMAIL PROTECTED] > 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>