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