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