Costin Manolache wrote:
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
Let me rename this:
Context 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 ).
No, Global means global within a single webapp but pools tags for all
JSP pages within a context. There are too many problems trying to pool
cross-context due to each context having its own WebappClassLoader.
Global Thread Local
Let me rename this:
Context 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 ).
Yes, Global means global within a single webapp but pools tags for all
JSP pages within the context. There are too many problems trying to pool
cross-context due to each context having its own WebappClassLoader.
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 ).
Was that a +1 to the renamed Context Global Thread Local?
Glenn
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
