Hey Mel,
I'll use this as a chance to explain some thoughts
I've recently had on tag pooling. Maybe you and
others have comments.
Mel Martinez wrote:
>
> Hi folks!
>
> I'm still overwhelmed with other priorities (new job,
> house-hunting, moving, etc.) to be able to help again,
> but I managed over the last day or so to get caught up
> with the list (for the most part - skipped some major
> threads along the way).
>
Hope things are working out well. I know where you're
coming from. We just moved and are now in the process
of putting in a yard.
> On tag-pooling: I am +1 on implementing a tag-cache
> on a per-page basis and tag-pooling on an application
> basis. If/when we move to the interfaces and toolkit
> metaphor I proposed for Jasper34, then page-based
> caching can best be done by enabling access to a
> tag-cache via the page-life-cycle handler, the
> JspPageHandler interface.
>
I agree. I spent some time last week looking at possible
optimizations. The general ideas were:
- pool tag handler objects per application. This could
still be turned on/off at runtime via module and is
already available.
- cache (re-use) handlers per page - i.e. only get the handler
from the pool once (when it is needed). If application
wide pooling is disabled then we'll just "new" a handler.
To be clear: there won't be any data structures (stacks, etc.)
for caching -- it will just be done via the rendering.
- call most setters only once -- when the tag handler
is first obtained. Attributes that are runtime expressions
will need to be called every time.
- in some situations we can pull out the tag handler
initialization code from inside "do" loops. Currently,
if a Tag is inside of a BodyTag, the initialization for
the inner tag is done inside of the
do-while(BodyTag.doEndBody() == EVAL_BODY_TAG). The
inner tag initializations only need to be done once
before the start of the do-while. Pulling the inner
initializations/checks out of the do loop would be a nice
thing, but it won't be as important once the tags
and setter calls are re-used for the whole page.
- maybe get rid of some redundant do-while(false)
constructs and various other minor clean ups.
So, to summarize: Each tag handler will be obtained once
per page (either from pool or via "new"). Setters
will be called once per handler per page. Both obtaining
the handler and calling the setters will be done on
an as needed basis. Yes, that will mean a synch call
to get each handler when it's first used if application
wide pooling is enabled.
So far, I was thinking that there would still be one tag
handler object per custom tag in the jsp page. For example,
given:
<x:iterate count="100">
<x:someTag/>
</x:iterate>
<x:someTag/>
there would still be 3 tag handler instances obtained.
The spec says the "someTag" handler could be reused because
tag scope allows it. But then we have the question of when
to reuse handlers if scope allows it. For example, if the
above was changed to:
<x:iterate count="100">
<x:someTag attrib="abc"/>
</x:iterate>
<x:someTag attrib="xyz"/>
We could reuse the handler instance but would have to call
the setters for "attrib" each time. What's more expensive, setter
call or just using a different handler? Of course this
depends on tag usage and what the setters are doing.
So, for now, I was planning on not implementing tag handler
reuse across multiple uses of a custom tag in the same jsp.
This can, of course, be improved in the future.
> I am very much -1 on basing any sort of caching or
> pooling relative to the request thread using
> thread-local variables because it assumes the Thread
> will be pooled and reused - this may not be true in
> all containers and Jasper should be
> container-independent.
>
I agree. After the above stuff gets done, I hope
that we won't have to do any thread local variable
stuff. I originally thought such optimizations would
be nice, but am now hoping that they won't be needed.
I'd like to make sure that all this stuff will (eventually)
work with tomcat 4 and future tomcats as well.
> Basically, one should think in terms of what temporal
> and access scope different objects have: request,
> page, application, etc. The JspPageHandler persists
> between requests for a page and should be used to
> represent access to objects and services concerned
> with the life-cycle of a page beyond one request, such
> as modification checking, name mangling,
> recompilation/loading as needed and clearly,
> tag-object caching. Thus, it seems logical that tags
> could be retrieved via either directly from methods
> on the page handler or from a tag cache manager object
> retrieved from the page handler.
>
> Casey, do you see any problems following such a
> general design philosophy? You are the lord gawd of
> the tag-pooling code, so I will defer to your
> judgement.
>
I agree with the general design philosophy. But don't
defer to much :) (The more I learn about Tomcat the more
I realize how much I don't know.) I haven't looked though
all the new Jasper stuff yet, but the idea sounds good.
> The source for the JasperToolkit and associated
> interfaces is still currently under
> jakarta-tomcat/src/jasper34/ and needs to be moved
> (along with the contents of
> jakarta-tomcat/proposals/jasper34) to
> jakarta-tomcat-jasper. Unfortunately, I am not going
> to be able to do this for at least a couple of weeks
> or more (my jakarta dev environment is 300 miles
> away!). I am chomping at the bit to resume coding on
> this, but alas, life has it's priorities. I'm going
> to delay asking Brian for new passwords until I can
> move my network up here with me so I won't have access
> to the repositories until then.
>
Costin is away for a while too. Hopefully though we
can soon get things ironed out so that we can move forward
with jakarta-tomcat-jasper.
-casey
> I will try to at least stay caught up with the
> developments via this list.
>
> Cheers,
>
> Dr. Mel Martinez
> Extreme Blue/Cambridge
> IBM
>
> __________________________________________________
> Do You Yahoo!?
> Get personalized email addresses from Yahoo! Mail - only $35
> a year! http://personal.mail.yahoo.com/
