please, correct my if i be wrong.
On Saturday 18 January 2003 22:56, you wrote: > I agree that the currnet Jasper tag pooling could be improved. > > > 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). > how it be to reduce the synchronize methods to a big synchronize block at beginning and end of the page, storing all tag instances in another object, like local map, pageContext and so? ....by the way..is the pageContext.setAttribute(...,SCOPE_PAGE ) synchronize, and if yes, why? > 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. > each tomcat connect has it own thread pool, right so if i have http with 100, and https with 100, i have a lot of thread locale objects. Does you mean a pool per jsp/tag or tag/thread? > 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 > > > 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. > > 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. > see first comment to reduce synchroniz. is a good idea, identify the taglibs with a attributes/attribute values/name combination...right? > 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. ok, see comment above. > > > 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. > > Regards, > > Glenn > > Costin Manolache wrote: > > Bill Barker wrote: > >>If tag-pooling works for you, I'm happy for you. The current > >>implementation > >>doesn't work for me big time. However, I'm very interested in Costin's > >>claim that it can be done thread-local. > > > > One quick question ( looking at generated code ) - why is the TP limited > > to 5 instances ? If you expect 20+ concurent requests ( where the TP > > would actually matter ) - you'll have the overhead of TP sync, and almost > > no benefit. Can you try again with a larger capacity ? > > > > Regarding the "claim" that it can be done thread-local: I attached a > > first draft, I'll enhance it later ( it could use ThreadWithAttributes - > > to save one extra hashtable lookup ). Let me know if it helps. > > > > > > Costin > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> For additional commands, > e-mail: <mailto:[EMAIL PROTECTED]> Regards, Torsten -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
