Re: tag pooling question
That would be nice to have tag pooling in 4.x. It was one of those things that I wanted to do before my day job changed a little. Anyway, a few thoughts: Tag pooling as implemented in 3.x is IMHO a good starting point, but generated code will really benefit if we can handle the more "traditional" optimizing compiler situations like pulling redundant code (i.e. tag setter methods) out of loops, etc. Hopefully, with the recent talk of new jasper (very exciting), we can have a good place to easily integrate such optimizations. If you have specific questions about 3.x tag pooling, just let me know... I might be able to remember some of it. -casey peter lin wrote: > > thanks larry for that information. I will take a look before I jump in. > > Larry Isaacs wrote: > > > > This was done by Casey Lucas. However, be aware that it comes > > with a disadvantage in that because of the extra code, it reduces > > the number of tags you can get on a JSP be for you hit Bug #6088 > > > > <http://nagoya.betaversion.org/bugzilla/show_bug.cgi?id=6088> > > > > I'm doubtful you can get 100-300 tags on a JSP page in any version > > of Jasper. Also, check recent posts on this list for a proposed > > "Jasper2" effort that is underway. See: > > Actually, I managed to make a page with about 140 tags that barely > squeezes under the 64K limit. Under moderate load it runs like a dog. > When I break it up into smaller pages using action include, it runs much > better. > > > > > <http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg24054.html> > > > > Cheers, > > Larry > > > > Peter lin > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: Some clean up of the jakarta-tomcat tree for Tomcat 3.3
I heard that. Get rid of it. -casey Andy Armstrong wrote: > > +1 (cleaning is good -- I love deleting stuff) > > Mike Anderson wrote: > > > > +1 > > > > Mike Anderson > > > > >>> [EMAIL PROTECTED] 06/19/01 03:49PM >>> > > Hi, > > > > Does anyone have any objection to my deleting the following folders > > from the jakarta-tomcat head: > > > > proposals/jasper34 > > proposals/tomcat-4.0 > > proposals/web-connector > > src/jasper34 > > > > They all have projects elsewhere and, as Henri noted earlier, would make > > a noticeable reduction in the size of the source file. > > > > Cheers, > > Larry > > -- > Andy Armstrong, Tagish
Re: Jasper34: static output changes
"Craig R. McClanahan" wrote: > > On Sat, 16 Jun 2001, Casey Lucas wrote: > > > > > [EMAIL PROTECTED] wrote: > > > > > > On Fri, 15 Jun 2001, Casey Lucas wrote: > > > > > > > > > > > Costin, > > > > > > > > sounds good. > > > > > > > > btw, when do you think the generator code in 34 will settle down > > > > a little? > > > > > > Soon :-) > > > > > > There is only one more change in the generator layout - switching to > > > a "visitor" pattern, with the tree representation of the page separated > > > from the actual generator. > > > > > > If you are thinking to tagpool changes - please wait until RuntimeLiaison > > > gets a bit of shape, I would like to provide some hooks for the container > > > to control the pools. Again, the idea is to allow a "toolkit" model, where > > > different components can be plugged in. > > > > ok. just let me know when you think it's appropriate to > > start adding some tag optimizations. > > > > > Separating tree is very important to allow modules to do various > > > optimizations ( like replacing common tags with equivalent in-line java > > > code ) and to do the direct bytecode generation. > > > > regarding "replacing common tags with equivalent in-line java code": what > > exactly did you have in mind? > > > > Jasper already understands what things like do, and it > generates specialized code to implement the required functionality (rather > than treating it like a custom tag). right. i thought he might be refering to custom tags. that's where my concern was. for the standard stuff, i'm sure we can inline / optimize plenty. > > With the advent of the JSP Standard Tag Library (being designed by the > expert group on JSR 52), there will be a much larger number of tags that > are suitable for this type of analysis -- things like conditional and > iteration tags, where you can generate much more efficient native Java > code instead of all the overhead of calling a regular custom tag. > > > -casey > > > > Craig
Re: Jasper34: static output changes
[EMAIL PROTECTED] wrote: > > On Fri, 15 Jun 2001, Casey Lucas wrote: > > > > > Costin, > > > > sounds good. > > > > btw, when do you think the generator code in 34 will settle down > > a little? > > Soon :-) > > There is only one more change in the generator layout - switching to > a "visitor" pattern, with the tree representation of the page separated > from the actual generator. > > If you are thinking to tagpool changes - please wait until RuntimeLiaison > gets a bit of shape, I would like to provide some hooks for the container > to control the pools. Again, the idea is to allow a "toolkit" model, where > different components can be plugged in. ok. just let me know when you think it's appropriate to start adding some tag optimizations. > Separating tree is very important to allow modules to do various > optimizations ( like replacing common tags with equivalent in-line java > code ) and to do the direct bytecode generation. regarding "replacing common tags with equivalent in-line java code": what exactly did you have in mind? -casey
Re: Jasper34: static output changes
Costin,
sounds good.
btw, when do you think the generator code in 34 will settle down
a little?
-casey
[EMAIL PROTECTED] wrote:
>
> Ok, time to discuss the first mini-optimization.
>
> Right now jasper has 2 ways to output data - one is the common
> out.println("String ");
>
> The other ( not very used ) is using an additional file to store the
> strings, and it's enabled by "largefile" option.
>
> The output system is probably the most important part of jasper ( except
> taglibs ) with regard to performance.
>
> My proposal is to drop the first option, which is also failing for chunks
> bigger than 64k ( due to .class file limitations on constant pool
> strings), and use the second ( with some changes ) in all cases.
>
> The main problem is that the java file will be less readable (
> out.println( strings[4] ) instead of the real string ). That can be
> resolved easily by generating a comment with the real string ( most users
> will not read the java file - now that we are close to line number
> mapping it'll happen even less ).
>
> Note that this is nothing new for jasper - the option has been present in
> jasper and is tested.
>
> The main benefits:
>
> - full control over static content allocation. If the strings are part of
> the constant pool, they are loaded with the class and garbage collected
> only if the class itself is gc. By loading them from the file we could
> easily add a LRU cache for the static chunks and reduce the runtime memory
> usage quite significantly.
>
> - ability for containers to control the static content. For a large file
> the connector could send only the file and offsets to apache, instead of
> reading and sending the large chunk.
>
> - it will work with large files without requiring users to set options
> ( that could be resolved by detecting large chunks and turning it on
> automatically )
>
> - a single output model - easier to test and optimize than 2.
>
> Let me know if you see any problem with that - it'll probably happen next
> week, I'm still stuck with the JspServlet.
>
> Costin
>
Re: [VOTE] New Committer: Mike Anderson
+1 -casey
Re: Jasper performance/3.3 tag pooling
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: 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: 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 JasperT
Re: Jasper performance/3.3 tag pooling
Rickard, Thanks for sending the test application. I've been using monthlist.jsp while testing rendered then hand bashed code. After some preliminary bashing :) I think it will be possible to call all setters (except runtime expressions) only once per run of the page. Also, we can create / obtain tag handler instances only once per page run. Anyway... after tweaking the rendered code, I was disappointed that there wasn't much of a change in the performance when I hit the page directly. The "optimized" version was even a bit slower :( So, I hooked it up to a profiler. It said that most of the time was being spent in webwork.util.ValueStack.findValue which is called from some of the setters and some of the do[Start|End]Tag methods. So even though the setters and tag handler "new"s were optimized, there wasn't much change in page evaluation time. (A strange note: under the profiler, the optimized version ran in about 75% of the time it took the un-optimized version. Not sure why the big difference, but I have seen variations like that before when code is run under a profiler.) So, Is there any way you could send me a new webwork.jar (no need for the whole .war) that has tag implementations optimized for tag instance and setter call reuse?. If you can move some/many of the calls to ValueStack.findValue out of the doStart/doEnd methods, that should help. Yes, I know this doesn't solve the problem of why weblogic was faster for you, but any tag related optimizations we can make should help other tag users (me and my day job included). If you send a new jar, I'll test it out and let you know. -casey Rickard Öberg wrote: > > [EMAIL PROTECTED] wrote: > > > Jasper performance is a high priority thing for us (nr 1. on our "system > > > performance fixing" list actually), so if possible, absolutely. I can't > > > say I've delved that far into Jasper yet though. It was a bit hard to > > > read. > > > > I'm working on a refactoring of jasper, and "easy to read" is a big > > priority. It's moving a bit slower than I expected - now I'm back on > > planning stage after hearing so much bad things about using XSLT :-) But I > > think there are ways to make ( almost ) everyone happy. > > > > I hope in few weeks ( after JavaOne ) we'll have something that works for > > both 1.1 and 1.2 ( the first part of refactoring ), and we can start the > > fun part - optimizing it. > > Sounds like a good plan :-) I'd be happy to help out with commenting on > the code. Code contribution is tricky right now (lots of other > OpenSource projects to manage :-). > > > The main problem is to avoid one synchronized call for each tag ( > > "new" _is_also_ a synchronized call on most VMs - it synchronizes > > the heap !!! ). > > Whoa.. I didn't know that.. that's an important factor to consider then. > > > Tomcat3.3 has one synchronized call to get the worker > > thread from the pool - and that doesn't seem to show up in any > > performance tests. > > As long as the synchs are few, and the block itself is short, you should > be ok. > > > We could keep a pool of pools ( probably for each context ). The local > > pools can be unsynchronized - so we'll have only one sync per page. Each > > context will have a set of pools ( with the size == the largest number of > > concurent requests for that context ). And we can of course be agressive > > in shrinking the pools that were not used recently. > > That could work. > > > We can try to do some of this in 3.3 space - or in a branch of 3.3 ( > > jasper34 is going to take a while, and I have a feeling you need results > > fast ). > > The big date for me is 2002-01-01. Before that I need some kind of > "assurance" that it'll improve greatly 'till that time, or we need to > look at alternatives (*shiver*). > > So sooner than later, sure, but preferably righter than sooner. Get this > stuff right, and I think you'll get lots of new supporters and keep old > ones ;-) > > > Regarding your application - I think we know the problem. There are few > > things you can do to reduce the memory use, and you could cache and > > recycle intermediary objects in each tag instance - you could benefit a > > lot from the reuse of the tags. > > I will start looking at optimizations on my side of things to, for sure. > My code isn't extremely optimized, I know that, but OTOH I've tested the > same code with WebLogic 5.0 (just to test) and it was wy faster, so > there's definitely room on the JSP side to improve things. > > > The memory savings of the thread pooling are not helping your application > > yet ( since they are very small compared with the rest ), yet you pay the > > synchronization price ( a lot - since you make heavy use of tags ). With > > few changes in your app and few changes in the tag pool we could reverse > > the situation - but if you disable the pool there's little chance you > > could increase the performance above the current level. > > Yup, that seems reasonable. > >
Re: Jasper performance/3.3 tag pooling
I think the changes will be too big to add before the 3.3 freeze. I like your alternative and will start bashing the jsp->java files to get something optimal before changing the jasper34 generator code. I'll let you know when I have something that looks interesting so that it can be discussed before taking the time to modify the generator code. -casey [EMAIL PROTECTED] wrote: > > Casey, > > We hope to freeze 3.3 for a release in the next weeks. If you feel the > changes are reasonably small and will not create problems - you can still > do it. > > What about: > > 1. We copy the code from 3.3 as it is in jasper34 area ( except that we > rename the package ). > > 2. We make sure it builds and runs in 3.3 - with a minimal set of changes: > - copy jasper34.jar in lib/container > - edit server.xml and replace with > > 3. You can start making the optimizations, and I can start doing the > refactoring, making sure we keep everything functional. > > 4. In time we can merge the changes from 4.0, add the new interfaces > proposed by Mel, add a new generator and so on - while making sure the > tests are passing and jasper is stable. > > This is unlikely to be finished before 3.3 is released, but we can make > sure we keep passing all the test suites and we can release milestones of > jasper34 for who needs the performance enhancements. > > When the code is ready we can make a 3.3.1 release and replace the old > jasper ( and same for when ajp14 is ready ). > > What I tried in proposals/jasper34 is just wrong and against the basic > ideas of "evolution" - and I realize that. > > Just give me 2 days, I need to finish with xalan ( we just had the 2.1.0 > release and I need to finish my work on it ) > > Costin > > On Wed, 23 May 2001, Casey Lucas wrote: > > > > > Costin & Craig, > > > > I agree with both of you. The optimizations that Craig mentioned are > > exactly the ones that I was hoping to add. Yes, the least fun part > > will probably be adding to the existing generator code. But, until a > > new generating architecture is in place, I think it would be good to > > go ahead and try to add the code to the existing jasper. > > > > When the next gen jasper gets a lot of momentum, we can add the > > tag related optimizations to it. > > > > -casey > > > > [EMAIL PROTECTED] wrote: > > > > > > On Wed, 23 May 2001, Craig R. McClanahan wrote: > > > > > > > I know Costin loves evolutionary change :-), and it's certainly a valid > > > > approach to Jasper. > > > > > > > > But there is also another approach we should consider - a green-field > > > > recoding of at least some of the major components (conforming to an > > > > agreed-upon overall architecture, of course). > > > > > > > NOTE: For most of the rest of the overall problem (the PageContext > > > > implementation, how Jasper fits in with the servlet container, and so > > > > on) evolution is probably a very reasonable strategy. On the compiler, > > > > though, I'm not so sure. > > > > > > If we are talking about the compiler ( or code generator ): I partially > > > agree, the current architecture will get a lot of pressure from more > > > complex optimizations or tricks. > > > > > > But before we can even start to change the generator we need to do the > > > initial refactoring and get the other components in order ( runtime, etc). > > > We can also get some optimizations in, and use that to learn what's needed > > > from a new generator architecture. > > > > > > I just don't think the new generator can happen in a 3.4 space - my goal > > > is just to enable an effort to rewrite it, and gather as much information > > > as possible about it's requirements. > > > > > > In any case - whatever happens in the current generator with regard to > > > generated code will still be usefull for any new generator architecture. > > > And if certain optimizations can't be done - that's even better, because > > > it would help us understand what's needed. > > > > > > I had big hopes for an XSLT based generator, and I still think it may be a > > > good way to implement the code generator - and I hope to hear other > > > ideas. > > > > > > Costin > >
Re: Jasper performance/3.3 tag pooling
Costin & Craig, I agree with both of you. The optimizations that Craig mentioned are exactly the ones that I was hoping to add. Yes, the least fun part will probably be adding to the existing generator code. But, until a new generating architecture is in place, I think it would be good to go ahead and try to add the code to the existing jasper. When the next gen jasper gets a lot of momentum, we can add the tag related optimizations to it. -casey [EMAIL PROTECTED] wrote: > > On Wed, 23 May 2001, Craig R. McClanahan wrote: > > > I know Costin loves evolutionary change :-), and it's certainly a valid > > approach to Jasper. > > > > But there is also another approach we should consider - a green-field > > recoding of at least some of the major components (conforming to an > > agreed-upon overall architecture, of course). > > > NOTE: For most of the rest of the overall problem (the PageContext > > implementation, how Jasper fits in with the servlet container, and so > > on) evolution is probably a very reasonable strategy. On the compiler, > > though, I'm not so sure. > > If we are talking about the compiler ( or code generator ): I partially > agree, the current architecture will get a lot of pressure from more > complex optimizations or tricks. > > But before we can even start to change the generator we need to do the > initial refactoring and get the other components in order ( runtime, etc). > We can also get some optimizations in, and use that to learn what's needed > from a new generator architecture. > > I just don't think the new generator can happen in a 3.4 space - my goal > is just to enable an effort to rewrite it, and gather as much information > as possible about it's requirements. > > In any case - whatever happens in the current generator with regard to > generated code will still be usefull for any new generator architecture. > And if certain optimizations can't be done - that's even better, because > it would help us understand what's needed. > > I had big hopes for an XSLT based generator, and I still think it may be a > good way to implement the code generator - and I hope to hear other > ideas. > > Costin
Re: Jasper performance/3.3 tag pooling
Glenn Nielsen wrote: [snip] > > I just had an idea (dangerous things) regarding tag pooling optimizations. > > When Jasper translates a page it should be able to generate information > about which tag handler classes it needs, and for each tag handler, the > profile of the attribute/value pairs. At runtime Jasper could make one call > to a tag pooling synchronized method to get all available instances of the tag >handlers > it needs. Any tag handlers/attribute profiles it couldn't obtain, it would have > to create. Then it would manage its own local tag pool during the execution > of the request. On termination of the request, after the page has been committed > to the remote client, it would make one call to a tag pooling synchronized > method to recycle/add the tag handlers it used. So there would only be 2 > synchronized methods per page for implementing tag pooling regardless of > how many tags are used. And you have the benifits of minimizing JVM memory > usage by sharing a global JVM tag pool. > that sparked something.. If we just bite the bullet and modify Jasper to correctly determine tag handler usage within a page (i.e. not get a new (from pool or "new") tag each time) then we can probably get the best of both worlds -- local reuse of tag handler variables (I don't like to call that a pool) plus application wide tag pooling. If application wide tag pooling is too expensive, then we can chunk it. Regardless, the per page reuse should be a big gain. Next step might be to determine if, in certain situations, we can not re-call tag setters. The spec says that attributes set should be "persistent". Rickard's test case would really benefit from setter optimization because most time was spent in body of setter methods. Any comments? btw, If i start tinkering, should I work with jasper34 or the 3.3 stuff? -casey > Regards, > > Glenn > > -- > Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| > MOREnet System Programming | * if iz ina coment. | > Missouri Research and Education Network | */ | > --
Re: Jasper performance/3.3 tag pooling
Rickard, Can you please send in some complete examples? Also, did you run the tests with and without tag pooling enabled on the same version of tomcat? (By adding removing TagPoolManagerInterceptor.) My experience has been that if the jsp uses many tags, then pooling is a big performance gain. See comments below. Rickard Öberg wrote: > > Hi! > > Ok, so now I've tested the Jasper performance with the 3.3 tag pooling > fix. The test was performed with a medium complexity page using lots of > iterative custom tags in a hierarchical fashion (i.e. tags within tags). > > Results: > The page ran slower, and above all the response time varied greatly > (between 250ms and 460ms, whereas without tag pooling we got between > 230ms and 340ms). > > Looking at the generated code, I'm not particularly surprised: it uses > (it seems) a real shared tag pool, so using tags will execute code that > needs > to be synchronized. Yes, everytime you obtain a tag, there is a synch that occurs for the pool that exists for each uniquely named tag and specific set of attributes. There is actually a set of named pools per application context. > > This is a bad design. Basically, any gains you get from reusing tags are > lost due to the overhead and general performance decrease you get by > using hashtables+"synchronized". > Hash lookup is done once per jsp page - when the jsp page is first run. After that, it's basically a synchronized push / pop pair on all subsequent runs of the page. In the future we can even get rid of the synch by using thread local storage... one step at a time though. :) > I've looked at pages generated by other more efficient JSP compilers > (e.g. Resin), and they generally use another approach: > Only reuse a tag within a particular page, and don't use a synchronized > pool to do it. Just pass the instance around within the generated code. > What is important is not primarily the global optimization gained by > using pools, but the local optimization gained by not creating tags for > each iteration in a iterative custom tag. > Yes reusing a tag handler within a single page will be more efficient (for that particular page) but I would guess that once we change to pool per thread there's no way newing the tags at each use will be faster (at least for a busy site with lots of tags.) > This is wy more efficient, and also avoids the suboptimization of > trying to reuse objects using Java code, something which is more > efficiently > handled by modern JVMs' memory management (i.e. creating objects using > "new" is > pretty snappy compared with Java-coded pools). > I disagree. I've found that object reuse can be a good performance optimization. > So, please remove the tag pooling, and do it right. If you don't believe > me, do some benchmarking or something. > I have done benchmarking and pooling enabled always wins. :) Maybe you can send some examples so that we can try and track down the problems. Thanks for taking a look at tag pooling. I look forward to refining the implementation. -casey
Re: bad watchdog test?
Craig, As you requested... I've attached diffs for the java file and for the jsp. Let me know if you have any questions / comments. -casey "Craig R. McClanahan" wrote: > > On Thu, 17 May 2001, Casey Lucas wrote: > > > > > I finally had some time last night to see why all of the watchdog tests > > wouldn't run correctly if tag pooling was turned on. > > > > Based on my understanding of the spec I think that that some of the code > > included in watchdog may be incorrect. The spec says that a tag handler > > can be used multiple times and that release() should be called before the > > tag handler gets garbage collected. But > > src\server\jsp-tests\WEB-INF\classes\jsp\tags\examples\TestTag.java relies > > on release() being called after every use of the tag. > > > > It wouldn't surprise me if Watchdog made some incorrect assumptions > here. Tag lifecycle seems to confuse lots of people, and because Tomcat > didn't implement pooling there wasn't an easy way to catch errors. > > If you've got diffs to fix the assumptions, I can evaluate them and check > them in. If it's more complicated than that, I'll forward the relevant > info to the folks that wrote the Watchdog tests for comment and action. > > > The code shouldn't be hard to fix for all situations except the test of > > the release method itself. If pooling is in use, then release will > > only be called when the web context is unloaded or an exception is thrown > > during tag usage. We could modify the "release test" to throw an exception > > during tag usage and hence cause release to be called, but I'm not sure > > we should because the spec doesn't say anything about reuse of a tag handler > > when an exception is thrown. For example, I guess a container would be compliant > > if reused a tag (and hence didn't call release) even in the case of exceptions. > > > > > > So, my questions are: > > > > 1. Is the watchdog test I've described bad and need fixing? > > > > 2. If so, any comments on what to do with the "release test"? > > > > > > > > -casey > > > > Craig TestTag.java.diff positiveRelease.jsp.diff
bad watchdog test?
I finally had some time last night to see why all of the watchdog tests wouldn't run correctly if tag pooling was turned on. Based on my understanding of the spec I think that that some of the code included in watchdog may be incorrect. The spec says that a tag handler can be used multiple times and that release() should be called before the tag handler gets garbage collected. But src\server\jsp-tests\WEB-INF\classes\jsp\tags\examples\TestTag.java relies on release() being called after every use of the tag. The code shouldn't be hard to fix for all situations except the test of the release method itself. If pooling is in use, then release will only be called when the web context is unloaded or an exception is thrown during tag usage. We could modify the "release test" to throw an exception during tag usage and hence cause release to be called, but I'm not sure we should because the spec doesn't say anything about reuse of a tag handler when an exception is thrown. For example, I guess a container would be compliant if reused a tag (and hence didn't call release) even in the case of exceptions. So, my questions are: 1. Is the watchdog test I've described bad and need fixing? 2. If so, any comments on what to do with the "release test"? -casey
Re: Jasper performance
Rickard, As Glenn mentioned, Jasper is in the process of getting a rework. But in the mean time and since you mentioned taglibs, you may want to look at the tag pooling module that was added to tc 3.3. If your jsps use a lot of tags, you should see a big performance gain. Let me know if you have questions about tag pooling. I was hoping to add tag pooling to tc 4, but have been very busy. So unless I gain some spare time, you'll probably need to wait until the new Jasper is available (at least for tag pooling). -casey Rickard Öberg wrote: > > Hi! > > We are using Tomcat/JBoss and are pleased with the actual functionality. > What is killing us right now is the performance of the code generated by > Jasper, especially when using taglibs in complex ways. The generated > code is way too unoptimized. > > So, if this has not been asked before (in which case a RTFA is ok, > although I've looked already), my question is: > When will Jasper be rewritten? > Are there any such projects underway now? > Have there been any discussions about this yet? > Am I the only one seeing this problem, or are more people concernced > about it? > > Thanks, > Rickard > > -- > Rickard Öberg > Software Development Specialist > xlurc - Xpedio Linköping Ubiquitous Research Center > Author of "Mastering RMI" > Email: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat/proposals/build2/ant tomcat.jsp
Hey costin,
Sure thing. We recently moved and have been very busy but I'm starting to
have a little more time (knock on wood). I should be able to help out with
at least the pooling stuff, so just let me know if you have specific ideas
or need help.
-casey
[EMAIL PROTECTED] wrote:
>
> Hi Casey,
>
> Sorry, I have too many things for now - the web based build is going to
> wait a bit. If you could check in the changes, great.( I hope you got the
> commit access )
>
> BTW, I have few ideas for the pooling in jasper34 ( I would like to make
> the pool pluggable, and managed by the container ). Getting the code
> generator to work is first, but I hope in few weeks to finally merge the 2
> runtimes and make the changes, and I hope you can review ( or help
> :-) some of it.
>
> Costin
>
> On Sun, 29 Apr 2001, Casey Lucas wrote:
>
> >
> > Costin,
> >
> > Web based build will be a nice addition -- cool.
> >
> > Small comment though. Keep in mind that I don't have a complete understanding
> > of all associated code, but at first glance, it appears that AntTag won't work
> > correctly if tag pooling is being used. I think the fix is simple though. Just
> > reset the list of targets and args at tag start time:
> >
> >
> > > 1.1 jakarta-tomcat/proposals/build2/WEB-INF/src/AntTag.java
> > >
> > > Index: AntTag.java
> > > ===
> > > package tadm;
> > > import java.util.*;
> > > import java.io.*;
> > > import java.net.URL;
> > > import javax.servlet.http.*;
> > > import javax.servlet.*;
> > >
> > > import javax.servlet.jsp.*;
> > > import javax.servlet.jsp.tagext.*;
> > >
> > > import org.apache.tools.ant.*;
> > >
> > > /**
> > >* This tag will run ant tasks
> > >*
> > >*/
> > > public class AntTag extends TagSupport {
> > >
> > > public AntTag() {}
> > >
> > > public int doStartTag() throws JspException {
> >
> > add:
> >
> > args.clear()
> > targets.clear() // or removeAllElements() etc.
> >
> >
> > > try {
> > > pageContext.setAttribute("antProperties",
> > > args);
> > > } catch (Exception ex ) {
> > > ex.printStackTrace();
> > > }
> > > return EVAL_BODY_INCLUDE;
> > > }
> > >
> > > public int doEndTag() throws JspException {
> > > runTest();
> > > return EVAL_PAGE;
> > > }
> > >
> > > // child tag support
> > > Properties args=new Properties();
> > > Vector targets=new Vector();
> > >
> > > public void setProperty( String name, String value ) {
> > > System.out.println("Adding property " + name + "=" + value );
> > > args.put(name, value );
> > > }
> > >
> > > public String getProperty( String name ) {
> > > System.out.println("Getting property " + name );
> > > return args.getProperty(name );
> > > }
> > >
> > > public void addTarget( String n ) {
> > > System.out.println("Adding target " + n );
> > > targets.addElement( n );
> > > }
> > >
> > > // Properties
> > >
> > > /** Set the name of the test.xml, relative to the base dir.
> > >* For example, /WEB-INF/test-tomcat.xml
> > >*/
> > > public void setTestFile( String s ) {
> > > args.put("ant.file", s);
> > > }
> > >
> > > /** Set the target - a subset of tests to be run
> > >*/
> > > public void setTarget( String s ) {
> > > addTarget(s);
> > > }
> > >
> > > public void setDebug( String s ) {
> > > args.put( "debug", s);
> > > }
> > >
> > > // Implementation methods
> > >
> > > private void runTest() throws JspException {
> > > PrintWriter out=null;
> > > try {
> > &g
Re: cvs commit: jakarta-tomcat/proposals/build2/ant tomcat.jsp
duh... too fast to type, too slow to think! how about move the clears to
the end of doEndTag instead of doStartTag. :)
-casey
Casey Lucas wrote:
>
> Costin,
>
> Web based build will be a nice addition -- cool.
>
> Small comment though. Keep in mind that I don't have a complete understanding
> of all associated code, but at first glance, it appears that AntTag won't work
> correctly if tag pooling is being used. I think the fix is simple though. Just
> reset the list of targets and args at tag start time:
>
> > 1.1 jakarta-tomcat/proposals/build2/WEB-INF/src/AntTag.java
> >
> > Index: AntTag.java
> > ===
> > package tadm;
> > import java.util.*;
> > import java.io.*;
> > import java.net.URL;
> > import javax.servlet.http.*;
> > import javax.servlet.*;
> >
> > import javax.servlet.jsp.*;
> > import javax.servlet.jsp.tagext.*;
> >
> > import org.apache.tools.ant.*;
> >
> > /**
> >* This tag will run ant tasks
> >*
> >*/
> > public class AntTag extends TagSupport {
> >
> > public AntTag() {}
> >
> > public int doStartTag() throws JspException {
>
> add:
>
> args.clear()
> targets.clear() // or removeAllElements() etc.
>
> > try {
> > pageContext.setAttribute("antProperties",
> > args);
> > } catch (Exception ex ) {
> > ex.printStackTrace();
> > }
> > return EVAL_BODY_INCLUDE;
> > }
> >
> > public int doEndTag() throws JspException {
> > runTest();
> > return EVAL_PAGE;
> > }
> >
> > // child tag support
> > Properties args=new Properties();
> > Vector targets=new Vector();
> >
> > public void setProperty( String name, String value ) {
> > System.out.println("Adding property " + name + "=" + value );
> > args.put(name, value );
> > }
> >
> > public String getProperty( String name ) {
> > System.out.println("Getting property " + name );
> > return args.getProperty(name );
> > }
> >
> > public void addTarget( String n ) {
> > System.out.println("Adding target " + n );
> > targets.addElement( n );
> > }
> >
> > // Properties
> >
> > /** Set the name of the test.xml, relative to the base dir.
> >* For example, /WEB-INF/test-tomcat.xml
> >*/
> > public void setTestFile( String s ) {
> > args.put("ant.file", s);
> > }
> >
> > /** Set the target - a subset of tests to be run
> >*/
> > public void setTarget( String s ) {
> > addTarget(s);
> > }
> >
> > public void setDebug( String s ) {
> > args.put( "debug", s);
> > }
> >
> > // Implementation methods
> >
> > private void runTest() throws JspException {
> > PrintWriter out=null;
> > try {
> > out=pageContext.getResponse().getWriter();
> > pageContext.getOut().flush();
> > out.flush(); // we need a writer for ant
> >
> > Project project=new Project();
> >
> > AntServletLogger log=new AntServletLogger();
> > log.setWriter( out );
> > project.addBuildListener( log );
> >
> > project.init();
> >
> > Enumeration argsE=args.propertyNames();
> > while( argsE.hasMoreElements() ) {
> > String k=(String)argsE.nextElement();
> > String v=args.getProperty( k );
> > if( k!=null && v!= null )
> > project.setUserProperty( k, v );
> > }
> >
> > String antFileN=args.getProperty("ant.file");
> > if( antFileN==null )
> > throw new JspException( "ant.file not specified");
> > File antF=new File(antFileN);
> > ProjectHelper.configureProject( project,
> >antF
Re: cvs commit: jakarta-tomcat/proposals/build2/ant tomcat.jsp
Costin,
Web based build will be a nice addition -- cool.
Small comment though. Keep in mind that I don't have a complete understanding
of all associated code, but at first glance, it appears that AntTag won't work
correctly if tag pooling is being used. I think the fix is simple though. Just
reset the list of targets and args at tag start time:
> 1.1 jakarta-tomcat/proposals/build2/WEB-INF/src/AntTag.java
>
> Index: AntTag.java
> ===
> package tadm;
> import java.util.*;
> import java.io.*;
> import java.net.URL;
> import javax.servlet.http.*;
> import javax.servlet.*;
>
> import javax.servlet.jsp.*;
> import javax.servlet.jsp.tagext.*;
>
> import org.apache.tools.ant.*;
>
> /**
>* This tag will run ant tasks
>*
>*/
> public class AntTag extends TagSupport {
>
> public AntTag() {}
>
> public int doStartTag() throws JspException {
add:
args.clear()
targets.clear() // or removeAllElements() etc.
> try {
> pageContext.setAttribute("antProperties",
> args);
> } catch (Exception ex ) {
> ex.printStackTrace();
> }
> return EVAL_BODY_INCLUDE;
> }
>
> public int doEndTag() throws JspException {
> runTest();
> return EVAL_PAGE;
> }
>
> // child tag support
> Properties args=new Properties();
> Vector targets=new Vector();
>
> public void setProperty( String name, String value ) {
> System.out.println("Adding property " + name + "=" + value );
> args.put(name, value );
> }
>
> public String getProperty( String name ) {
> System.out.println("Getting property " + name );
> return args.getProperty(name );
> }
>
> public void addTarget( String n ) {
> System.out.println("Adding target " + n );
> targets.addElement( n );
> }
>
> // Properties
>
> /** Set the name of the test.xml, relative to the base dir.
>* For example, /WEB-INF/test-tomcat.xml
>*/
> public void setTestFile( String s ) {
> args.put("ant.file", s);
> }
>
> /** Set the target - a subset of tests to be run
>*/
> public void setTarget( String s ) {
> addTarget(s);
> }
>
> public void setDebug( String s ) {
> args.put( "debug", s);
> }
>
> // Implementation methods
>
> private void runTest() throws JspException {
> PrintWriter out=null;
> try {
> out=pageContext.getResponse().getWriter();
> pageContext.getOut().flush();
> out.flush(); // we need a writer for ant
>
> Project project=new Project();
>
> AntServletLogger log=new AntServletLogger();
> log.setWriter( out );
> project.addBuildListener( log );
>
> project.init();
>
> Enumeration argsE=args.propertyNames();
> while( argsE.hasMoreElements() ) {
> String k=(String)argsE.nextElement();
> String v=args.getProperty( k );
> if( k!=null && v!= null )
> project.setUserProperty( k, v );
> }
>
> String antFileN=args.getProperty("ant.file");
> if( antFileN==null )
> throw new JspException( "ant.file not specified");
> File antF=new File(antFileN);
> ProjectHelper.configureProject( project,
>antF );
>
> // pre-execution properties
> Hashtable antProperties=project.getProperties();
> argsE=antProperties.keys();
> while( argsE.hasMoreElements() ) {
> String k=(String)argsE.nextElement();
> String v=(String)antProperties.get( k );
> if( k!=null && v!= null )
> args.put( k, v ); // includes "revision"
> }
>
> if( targets.size()==0 ) {
> //targets.addElement("client");
> }
>
> project.executeTargets( targets );
>
> // post-execution properties
> antProperties=project.getProperties();
>
> argsE=antProperties.keys();
> while( argsE.hasMoreElements() ) {
> String k=(String)argsE.nextElement();
> String v=(String)antProperties.get( k );
> if( k!=null && v!= null )
> args.put( k, v );
> }
>
> } catch( BuildException ex ) {
> if( out==null ) out=new PrintWriter(System.out);
> ex.printStackTrace(out);
> Throwable ex1=ex.getExcept
Re: Tag pooling impl.
Hey Costin, [EMAIL PROTECTED] wrote: > > Hi Casey, > > There is a small problem when building with jikes. The > TagPoolInterceptor depends on jasper runtime, which depend on the servlet > api - I think it should be moved into the facade ( for now ). We do need a > serious refactoring of jasper - and that would clarify a lot of > things. There is no problem with javac, since it doesn't use > "strict" rules. > Sorry about that. I normally don't use jikes, but I should have at least tested with it. What platforms to most people test with before commiting code? I mean besides watchdog and such. i.e. jdk version, jdk vendor, os, etc.? Just curious. > I'll do the move if you don't mind. I like the idea of having a general > and facade-independent pool mechanism, but we can do that later. I definately don't mind. True a more general pooling mechanism would probably be better. Baby steps for me... just getting my feet wet. :) Thanks for your help. -Casey
Re: cvs commit: jakarta-tomcat/src/share/org/apache/jasper/runtime BodyContentImpl.java PageContextImpl.java
I noticed that for PageContextImpl you made a comment about removing
the log dependency. Was this just because it was used on a case that
"shouldn't happen" or is there another reason why jasper components
shouldn't rely on tomcat logging code?
Just wondering / checking, because some jasper stuff I'm working on
uses the same log classes.
-Casey
[EMAIL PROTECTED] wrote:
>
> costin 01/03/22 18:21:21
>
> Modified:src/share/org/apache/jasper/runtime BodyContentImpl.java
> PageContextImpl.java
> Log:
> Double the size of the buffer, as before ( sorry again for undoing your
> change ).
>
> Removed the logger dependency ( that was used only to report a case that
> shouldn't happen )
>
> Revision ChangesPath
> 1.10 +6 -4
>jakarta-tomcat/src/share/org/apache/jasper/runtime/BodyContentImpl.java
>
> Index: BodyContentImpl.java
> ===
> RCS file:
>/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/runtime/BodyContentImpl.java,v
> retrieving revision 1.9
> retrieving revision 1.10
> diff -u -r1.9 -r1.10
> --- BodyContentImpl.java 2001/03/21 19:50:51 1.9
> +++ BodyContentImpl.java 2001/03/23 02:21:20 1.10
> @@ -103,6 +103,9 @@
>}
>}
>
> +/** Make space for len chars. If len is small, allocate
> + a reserve space too.
> + */
>private void reAllocBuff (int len) {
>//Need to re-allocate the buffer since it is to be
> //unbounded according to the updated spec..
> @@ -112,12 +115,11 @@
> //XXX Should it be multiple of DEFAULT_BUFFER_SIZE??
>
> if (len <= Constants.DEFAULT_BUFFER_SIZE) {
> - tmp = new char [bufferSize + Constants.DEFAULT_BUFFER_SIZE];
> - // bufferSize = bufferSize * 2;
> - bufferSize += Constants.DEFAULT_BUFFER_SIZE;
> + bufferSize = bufferSize * 2;
> + tmp = new char [bufferSize];
> } else {
> - tmp = new char [bufferSize + len];
> bufferSize += len;
> + tmp = new char [bufferSize];
> }
> System.arraycopy(cb, 0, tmp, 0, cb.length);
> cb = tmp;
>
>
>
> 1.20 +7 -8
>jakarta-tomcat/src/share/org/apache/jasper/runtime/PageContextImpl.java
>
> Index: PageContextImpl.java
> ===
> RCS file:
>/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/runtime/PageContextImpl.java,v
> retrieving revision 1.19
> retrieving revision 1.20
> diff -u -r1.19 -r1.20
> --- PageContextImpl.java 2001/03/02 04:51:42 1.19
> +++ PageContextImpl.java 2001/03/23 02:21:20 1.20
> @@ -94,8 +94,6 @@
> */
>public class PageContextImpl extends PageContext {
>
> -Log loghelper = Log.getLog("JASPER_LOG", "JspFactoryImpl");
> -
>PageContextImpl(JspFactory factory) {
>this.factory = factory;
>}
> @@ -462,12 +460,13 @@
>protected JspWriter _createOut(int bufferSize, boolean autoFlush)
>throws IOException, IllegalArgumentException
>{
> - try {
> - return new JspWriterImpl(response, bufferSize, autoFlush);
> - } catch( Throwable t ) {
> - loghelper.log("creating out", t);
> - return null;
> - }
> + // This may fail for security expcetions, if the sandbox is broken !!
> + // try {
> + return new JspWriterImpl(response, bufferSize, autoFlush);
> + // } catch( Throwable t ) {
> + // loghelper.log("creating out", t);
> + // return null;
> + // }
>}
>
>/*
>
>
>
Re: jasper tag handler cleanup during exceptions
Mel,
Thanks for the informative response. I can sense
your frustration. I'm right there with you.
I already have the "catch the Throwable and wrap it
if we have to" style rendering working and it seems
to be ok. Unless you (or someone else) is in
disagreement, I can check it in. This model
(I think) should map easier into the Jasper 4 rendering
while still allowing the tag pools to maintain
consistency. If necessary, we can refactor code
into PageContextImpl later.
Again, thanks for your comments.
-Casey
Mel Martinez wrote:
>
> Casey,
>
> This is tuff. I am very leery of wrapping up
> Throwables because that changes how they 'look' to
> methods further up the stack chain. However, given
> what is coming down the pipe with JSP 1.2, I think it
> MIGHT be reasonable to simply anticipate the change
> and overload the PageContextImpl.handlePageException()
> method to match the future interface.
>
> try {
> // body of translated JSP here ...
> } catch (Throwable t) {
> //do tag pool cleanup here ...
> out.clear();
> (PageContextImpl)
>pageContext).handlePageException(t);
> } finally {
> out.close();
> factory.releasePageContext(pageContext);
> }
>
> Then org.apache.jasper.runtime.PageContextImpl gains
> something like:
>
> public void handlePageException(Throwable t)
> throws ServletException, IOException{
> if(t instanceof Exception){
> handlePageException((Exception)t);
> }else if(t instanceof Error){
> throw (Error)t;
> }else{
> throw new ServletException(t);
> }
> }
>
> Functionally, this does not do anything different from
> what you proposed, but it puts things in the right
> framework for being handled correctly later, if we
> need to change it. For example, should we just bite
> the bullet and forward all throwables to an error page
> (if any)?
>
> On the other hand, this, imho, points to a flaw in the
> spec in that jsp's should not be catching Throwables
> or even Exceptions that it does not recognize and know
> exactly how to deal with. By passing them off to a
> JSP api (the handlePageException) it is not giving the
> Servlet container a chance to deal with the Throwable
> since, at least in the case of Jasper, the Jsp
> implementation doesn't really have anyway of passing
> the Throwable along unaltered. For example, if some
> container method invoked by a servlet (such as a
> request or response method) needed to communicate some
> situation up to the container with a Throwable
> subclass, it would not make it there through the
> _jspService method's try..catch barrier. By at least
> throwing it wrapped in a ServletException, we give the
> container a chance at it, but now the container has to
> be smart enough to know to look inside the
> ServletException on the chance it will recognize the
> throwable contents. And if the Throwable has been
> shuttled along to an ErrorPage, by the jsp servlet,
> then the container would never see it.
>
> It would be different if the specification provided
> that the servlet container provide a callback method
> that handlePageException was required to use to give
> the ServletEngine a chance to handle the Throwable -
> but in that case, why not just let _jspService throw
> Throwable?
>
> I mean really, it's kind of silly that the spec is
> asking the jsp servlet to intercept and redirect or
> wrap up what might be a catastrophic Error condition
> underwhich the JVM shouldn't even be running any
> longer! :-)
>
> Sigh... I'm sorry. Exceptions, Errors and Throwables
> get me a little 'bent'. The inheritance model is
> crapola. The idea that Throwable and Exception are
> 'checked' but that RuntimeException (descending from
> Exception) and Error (descending from Throwable) are
> 'unchecked' drives me nuts. They should have made
> 'checked' or 'unchecked' a marker interface (like
> Serializable) and a lot of headaches could have been
> avoided.
>
> Given all that, you probably would do just fine to
> ignore Throwable for now and simply do your cleanup on
> caught Exceptions and Errors and leave the Throwable
> problem for the future. That should be fine 99% of
> the time.
>
> try{
> try{
> //body goes here
> }catch(Exception e){
> //do tag cleanup
> throw e;
> }catch(Error err){
> //do tag cleanup
> throw err;
> }
> }catch(Exception e){
> //blah...blah...
>
> :-)
>
> Mel
>
> --- Casey Lucas <[EMAIL PROTECTED]> wrote:
> >
> > Mel,
> >
> > Thanks for the comments. See below.
> >
> >
Re: jasper tag handler cleanup during exceptions
Mel,
Thanks for the comments. See below.
Mel Martinez wrote:
>
> --- Casey Lucas <[EMAIL PROTECTED]> wrote:
> >
> > As I started to add some code to remove pooled tag
> > handlers from
> > the tag pool if an exception is thrown during tag
> > usage, I came
> > across an issue...
> >
> > To clean up tag handlers in the case of exceptions,
> > I need to
> > know when any exception is thrown. So I figured the
> > best way
> > to do this is to catch it. :) Yet in Tomcat 3, I can
> > only safely catch
> > (and rethrow) java.lang.Exception, java.lang.Error,
> > and
> > java.lang.RuntimeException. If I simply added a
> > catch for
> > java.lang.Throwable (like I wanted to), I can't
> > correctly propagate
> > the exception under Tomcat 3.
> >
>
> Casey,
>
> How about if you simply nest your try{
> }catch(Throwable t){} inside the 'main' try..catch
> block, do your cleanup and then throw it outwards to
> be handled normally, like so:
>
> public void _jspService(HttpServletRequest request,
> HttpServletResponse response)
> throws IOException, ServletException {
> // init jsp page stuff goes here
> try {
> try{
>
True. This is what I was hoping to do.
> // body of JSP here ...
>
> }catch(Throwable t){
>//do tag pool cleanup here
>throw t;
Can't do this because _jspService doesn't include Throwable
in it's throws clause... unless you make the additional modification
below.
> }
> } catch (Exception e) {
> out.clear();
> pageContext.handlePageException(e);
> } finally {
> out.close();
> factory.releasePageContext(pageContext);
> }
> }
Instead I was wondering if something like this is ok
(taken from my modified rendering) ? :
} catch (Exception ex) {
if (out != null && out.getBufferSize() != 0)
out.clearBuffer();
if (pageContext != null) pageContext.handlePageException(ex);
} catch (Throwable throwable) {
throw new org.apache.jasper.JasperException(throwable);
}
} finally {
if (out instanceof org.apache.jasper.runtime.JspWriterImpl) {
((org.apache.jasper.runtime.JspWriterImpl)out).flushBuffer();
}
if (_jspxFactory != null) _jspxFactory.releasePageContext(pageContext);
}
Will this mess up any error/exception propogation that you know of?
>
> Would that accomplish what you are trying to do? You
> should be able to do this by modifying
> JspParseEventListener's generateHeader() and
> generateFooter() methods.
>
> mel
>
> > I can ignore other Throwables (besides the three
> > types mentioned)
> > but that means that tag handlers will not get
> > removed from the pool
> > if a different type of exception is thrown. -- I
> > don't really like it.
> >
> > Alternatively, would it be ok to also catch
> > Throwable at the bottom
> > of the rendered code (below the java.lang.Exception
> > catch) then just
> > wrap it in a JasperException (or maybe just
> > ServletException)? If so,
> > I can do everything with just Throwables -- same
> > model for Tomcat 3
> > and 4. Would wrapping Throwables with
> > JasperExceptions mess up any
> > error propagation from the JSP?
> >
> > Thanks Jasper gurus.
> >
> > -Casey
>
> __
> Do You Yahoo!?
> Get email at your own domain with Yahoo! Mail.
> http://personal.mail.yahoo.com/
jasper tag handler cleanup during exceptions
As I started to add some code to remove pooled tag handlers from the tag pool if an exception is thrown during tag usage, I came across an issue... In Tomcat 3, at the end of a JSP page, Jasper renders code to catch java.lang.Exception. In Tomcat 4, Jasper renders code to catch Throwable. This is because of the spec diffs when it comes to PageContext.handlePageException. To clean up tag handlers in the case of exceptions, I need to know when any exception is thrown. So I figured the best way to do this is to catch it. :) Yet in Tomcat 3, I can only safely catch (and rethrow) java.lang.Exception, java.lang.Error, and java.lang.RuntimeException. If I simply added a catch for java.lang.Throwable (like I wanted to), I can't correctly propagate the exception under Tomcat 3. I can ignore other Throwables (besides the three types mentioned) but that means that tag handlers will not get removed from the pool if a different type of exception is thrown. -- I don't really like it. Alternatively, would it be ok to also catch Throwable at the bottom of the rendered code (below the java.lang.Exception catch) then just wrap it in a JasperException (or maybe just ServletException)? If so, I can do everything with just Throwables -- same model for Tomcat 3 and 4. Would wrapping Throwables with JasperExceptions mess up any error propagation from the JSP? Thanks Jasper gurus. -Casey
Re: Bugzilla issues
Hola. I'm sure I wont have enough time to take over Jasper for 3, but I may find some time to help out. I'll try to take a look after I wrap up some other stuff. -Casey "Ignacio J. Ortega" wrote: > > Hola a todos: > > There are so many Tomcat 3/Jasper bugs and the component itself assigned > to Justyna Horward, it seems Justyna will not do much to help us with > 3.X, if nobody complaints, if nobody complaints i will make somebody > responsible of that component...( myself as a last resort to contact > reporters at least ) > > Who wants to volunteer to own the Jasper component on Tomcat 3? > > Casey, Mel or Marc perhaps? > > Another issue on bugzilla, It's time for creating the 3.3 version on > bugzilla? I think people does not know where to put the bugs relate dto > 3.3, and it's starting to use unknown for 3.3 .., with 2 milestones out > in the wild, we can think on add 3.3 version to Bugzilla, if nobody > complaints i will do that tomorrow. > > Any comments will be highly appreciatted... > > Saludos , > Ignacio J. Ortega
Re: http 1.0 timeout patch
I'm -1 on the 15 sec. You never know what type of network a client may be traversing. -Casey GOMEZ Henri wrote: > > Hi, > > I notice you corrected the patch which is a good thing > but settings timeout to 5mn (300s) is a little too high > for an http 1.0 connection. The timeout could be as low as 15s. > The timeout is activated if you have more that 15s between 2 > read() and since connector read stream byte by byte. > > 300s is valid for http 1.1 connection with keep-alive. > I'll commit the patch for 3.3 but with a 15 seconds timeout ;-) > > Si la fortune vient en dormant, ça n'empêche pas les emmerdements de venir > au réveil. > -- Pierre Dac > > >-Original Message- > >From: Glenn Nielsen [mailto:[EMAIL PROTECTED]] > >Sent: Wednesday, March 21, 2001 4:14 PM > >To: [EMAIL PROTECTED] > >Subject: Re: mod_webapp status? > > > > > >"Pier P. Fumagalli" wrote: > >> > >> jean-frederic clere <[EMAIL PROTECTED]> wrote: > >> > >> > "Eric L. Anderson" wrote: > >> >> > >> >> What is the current status of mod_webapp? I have tried > >building the connector > >> >> from cvs but the build fails with webapplib. The errors > >seem to indicate > >> >> there > >> >> are some missing source files. > >> >> > >> >> wa.c:69: `wa_connections' undeclared (first use in this function) > >> >> wa.c:69: (Each undeclared identifier is reported only once > >> >> wa.c:69: for each function it appears in.) > >> >> wa.c:72: `cb' undeclared (first use in this function) > >> >> wa.c:73: `wa_callbacks' undeclared (first use in this function) > >> >> > >> >> I can not find any trace of an actual definition of > >"wa_connections" in any > >> >> of the source files. > >> > > >> > ? It is in "webapplib/wa_connection.c" > >> > > >> >> > >> >> -- > >> >> Eric L. Anderson > >> >> [EMAIL PROTECTED] > >> > > >> > I have also problems with mod_webapp. > >> > > >> > Pier has changed a lot of things, you will have to little. > >> > >> I'm rewriting it using APR... As we speak... > >> > >> Pier (under the snow in Dublin) > >> > > > >APR is for Apache 2.0, correct? What about Apache 1.3? > > > >What _is_ the status of mod_webapp/WARP, this is a critical componenet > >for Tocmat 4. Tomcat 4 is useless to me without an Apache connector. > > > >Regards, > > > >Glenn > > > >-- > >Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| > >MOREnet System Programming | * if iz ina coment. | > >Missouri Research and Education Network | */ | > >-- > >
Re: cvs commit: jakarta-tomcat/src/share/org/apache/jasper/runtime BodyContentImpl.java
Casey Lucas wrote:
>
> Just curious... why did you take out the buffer size double? Is that too
> much memory to sacrifice? Someone ? recently sent this in as a performance
> improvement patch.
Of course the line
tmp = new char [bufferSize + Constants.DEFAULT_BUFFER_SIZE];
also needs to be tweeked, if you add the 2X buffer.
>
> You know I love anything that makes tags faster. :)
>
> -Casey
>
> [EMAIL PROTECTED] wrote:
> >
> > costin 01/03/21 11:51:06
> >
> > Modified:src/share/org/apache/jasper/runtime BodyContentImpl.java
> > Log:
> > Lucky fix - it shows up for some JSPs generating a lot of content.
> > Nacho - nice tuneup ( remove double copy ), you forgot one line :-)
> >
> > Revision ChangesPath
> > 1.9 +4 -1
>jakarta-tomcat/src/share/org/apache/jasper/runtime/BodyContentImpl.java
> >
> > Index: BodyContentImpl.java
> > ===
> > RCS file:
>/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/runtime/BodyContentImpl.java,v
> > retrieving revision 1.8
> > retrieving revision 1.9
> > diff -u -r1.8 -r1.9
> > --- BodyContentImpl.java 2001/03/10 01:20:23 1.8
> > +++ BodyContentImpl.java 2001/03/21 19:50:51 1.9
> > @@ -113,7 +113,8 @@
> >
> > if (len <= Constants.DEFAULT_BUFFER_SIZE) {
> > tmp = new char [bufferSize + Constants.DEFAULT_BUFFER_SIZE];
> > - bufferSize = bufferSize * 2;
> > + // bufferSize = bufferSize * 2;
> > + bufferSize += Constants.DEFAULT_BUFFER_SIZE;
> > } else {
> > tmp = new char [bufferSize + len];
> > bufferSize += len;
> > @@ -179,6 +180,8 @@
> > if (len >= bufferSize - nextChar)
> > reAllocBuff(len);
> >
> > + //System.out.println("XXX " + off + " " + (off+len) + " " +
> > + // nextChar + " " + bufferSize + " "+ cb.length);
> >s.getChars(off, off + len, cb, nextChar);
> > nextChar += len;
> >}
> >
> >
> >
Re: cvs commit: jakarta-tomcat/src/share/org/apache/jasper/runtime BodyContentImpl.java
Just curious... why did you take out the buffer size double? Is that too
much memory to sacrifice? Someone ? recently sent this in as a performance
improvement patch.
You know I love anything that makes tags faster. :)
-Casey
[EMAIL PROTECTED] wrote:
>
> costin 01/03/21 11:51:06
>
> Modified:src/share/org/apache/jasper/runtime BodyContentImpl.java
> Log:
> Lucky fix - it shows up for some JSPs generating a lot of content.
> Nacho - nice tuneup ( remove double copy ), you forgot one line :-)
>
> Revision ChangesPath
> 1.9 +4 -1
>jakarta-tomcat/src/share/org/apache/jasper/runtime/BodyContentImpl.java
>
> Index: BodyContentImpl.java
> ===
> RCS file:
>/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/runtime/BodyContentImpl.java,v
> retrieving revision 1.8
> retrieving revision 1.9
> diff -u -r1.8 -r1.9
> --- BodyContentImpl.java 2001/03/10 01:20:23 1.8
> +++ BodyContentImpl.java 2001/03/21 19:50:51 1.9
> @@ -113,7 +113,8 @@
>
> if (len <= Constants.DEFAULT_BUFFER_SIZE) {
> tmp = new char [bufferSize + Constants.DEFAULT_BUFFER_SIZE];
> - bufferSize = bufferSize * 2;
> + // bufferSize = bufferSize * 2;
> + bufferSize += Constants.DEFAULT_BUFFER_SIZE;
> } else {
> tmp = new char [bufferSize + len];
> bufferSize += len;
> @@ -179,6 +180,8 @@
> if (len >= bufferSize - nextChar)
> reAllocBuff(len);
>
> + //System.out.println("XXX " + off + " " + (off+len) + " " +
> + // nextChar + " " + bufferSize + " "+ cb.length);
>s.getChars(off, off + len, cb, nextChar);
> nextChar += len;
>}
>
>
>
Re: first cut at tag pooling implementation
Janco,
True. This has been fixed already.
Thanks for the look. I put that in there to make sure someone
was actually looking at the code. (hehe. just kidding)
-casey
Janco Tanis wrote:
>
> I've a doubt with the code in TagHandlerPoolImpl.getHandler():
>
> // When the stack is empty, create a new tag and return it
> if (myHandlers.empty()) {
> returnValue = (Tag) myHandlerClass.newInstance();
> // Pushing it on the stack will cause the next getHandler to return the same tag
>using pop
> // So I guess we need to remove the push over here...
> myHandlers.push(returnValue);
> } else {
> returnValue = (Tag) myHandlers.pop();
> }
>
> --
> janco
>
> Casey Lucas wrote:
>
> > The attached files and diffs are based on 3.3 (hopefully latest code).
> > They add tag pooling for tomcat. I hope that some of you will have
> > time to take a look and provide feedback. I mainly tested with our
> > application that uses a lot of tags.
> >
> > To disable pooling, don't include the TagPoolManagerInterceptor
> > interceptor. Jasper will still generate pooling code, but pooling
> > won't be used at runtime.
> >
> > Summary of changes:
> >
> > 1. changed jasper to add tag pool support
> >
> > files changed:
> > org.apache.jasper.compiler.
> > JspParseEventListener.java
> > TagBeginGenerator.java
> > TagEndGenerator.java
> >
> > files added:
> > org.apache.jasper.compiler.
> > TagPoolManagerGenerator.java
> > TagPoolGenerator.java
> >
> > 2. added tag pooling classes / interfaces
> > files added:
> > org.apache.jasper.runtime.
> > TagHandlerPool.java
> > TagHandlerPoolImpl.java
> > TagPoolManager.java
> > TagPoolManagerImpl.java
> >
> > -Casey
> >
>
> --
> Janco Tanis
>
>
> COAS, Your partner in computer aided services
>
>Nijverheidsweg 34Tel: +31 (0) 187 49 3222
>Postbus 44 Fax: +31 (0) 187 49 2912
>3250 AA Stellendam Email: [EMAIL PROTECTED]
Re: [PATCH] Fun with tag pools
Thanks for the comments. See my additional comments within. "Craig R. McClanahan" wrote: > > Casey, I haven't looked at the details but the concept looks really > great! I'm looking forward to a corresponding implementation for 4.0. > > A couple of interspersed comments below: > > On Sun, 18 Mar 2001, Casey Lucas wrote: > snip > > > > Questions: > > - > > 1. Each web application wide TagPoolManager is stored in application scope > > as an attribute. Of course this means that an application could change it. > > Is this acceptable? > > > > We're doing that kind of thing in 4.0 today with the classpath and class > loader being passed from Catalina. The good news: it works. The bad > news: it exposes information to change that should not really be > changeable. > > The other alternative would be some sort of global static variable that > Jasper knows about -- at least in 4.0 each webapp's Jasper is loaded by a > separate class loader, so statics would be unique. > Yea, I threw around that idea, but had some trouble (confusion) with class loaders in 3.3. The interceptor would set the static, but it wasn't visible to the jsp. Once I got the application scope attribute working I stayed with that. I prefer the JspFactory.get(set)DefaultFactory() style and will probably revisit it. > > 2. Tag handlers are ALWAYS returned to the tag pool. Even in the case of > > exceptions, tag handlers will be reused. Should tags be removed from the > > pool if an exception is thrown during the normal set of tag calls (doStartTag, > > doInitBody, etc.) ? > > > > I believe we should plan on reuse, even if exceptions are thrown by this > tag itself. > > For example, in Struts I have tags that check for valid combinations of > attributes being set in the doStartTag() method (you need either "x" or > "y"; if you use "a" you must also use "b"; that sort of thing) and throw > an exception if the condition is violated. There's nothing wrong with the > tag instance itself - it was just used wrong in the page. > > > > > Caveats: > > --- > > 1. Tag reuse has some important implications for the tag developer. > > In general, the handler must be repeatedly usable without calls > > to Tag.release. For example, handlers should be sure to reset > > certain variables to a well known state in doEndTag. Only those > > variables that change during the processing of the tag need to be > > reset. Those set via attribute setters (and not changed) are ok. > > > > Even if you are running under JSP 1.1 (i.e. Tomcat 3.x), tag developers > will find it useful to review the JSP 1.2 Proposed Final Draft spec. It > includes lifecycle diagrams on a tag that identify precisely when the > container will call which methods. > > > Note that some of the tags in the watchdog tests do not support > > reuse. So don't enable pooling for watchdog tests. > > > > Better would be to fix the tests so they work correctly. At least on the > Watchdog 4.0 tests, I can probably acquire some resources to help us get > these right. > > > 2. Because handlers are always returned to the pool, exceptions > > may cause handlers to miss doEndTag and therefore possibly miss > > cleanup / state reset. The new TryCatchFinally interface fixes > > this problem, but it's not available in jsp 1.1. > > > > How about a policy where you don't recycle any tag instances *after* the > one that threw the exception? Would that cover all the possible cases? > I was thinking of something like: If an exception is thrown (from any code, not necessarily the tag) during the scope of a tag handler's use (between doStartTag and doEndTag), then that tag should be removed from the pool because its state can not be guaranteed. Of course this is only a Tomcat 3.x issue because JSP 1.2 introduces the TryCatchFinally interface. If a tag must perform state maintenance at the end of its use, then it will just use the doFinally method. By using doFinally, the container does not have to make any assumptions about a tag handlers possible reuse -- the tag must ensure its ability to be reused. -Casey
[PATCH] Fun with tag pools
ets up tag pooling if it is enabled, it will
* add a TagPoolManagerImpl to the application context. JSPs will
* then find it and use tag pooling. To disable tag pooling, just
* dont include this interceptor.
*
* @author Casey Lucas <[EMAIL PROTECTED]>
* @see TagPoolManager
*/
public class TagPoolManagerInterceptor extends BaseInterceptor {
/**
* This hook is called when an application context is initialized.
* Here, we add a TagPoolManagerImpl to the application context.
*
* @param ctx
* @exception TomcatException
*/
public synchronized void contextInit(Context ctx) throws TomcatException {
if (debug>0) {
log("Adding TagPoolManagerImpl: " + ctx);
}
TagPoolManager manager = (TagPoolManager)
ctx.getAttribute(TagPoolManager.CONTEXT_ATTRIBUTE_NAME);
if (manager != null) {
if (debug>0) {
log("TagPoolManagerImpl already exists for: " + ctx);
}
} else {
manager = new TagPoolManagerImpl();
ctx.setAttribute(TagPoolManager.CONTEXT_ATTRIBUTE_NAME, manager);
}
}
/**
* This hook is called when an application context is shutdown. Here,
* the TagPoolManagerImpl is removed from the application context.
*
* @param ctx
* @exception TomcatException
*/
public synchronized void contextShutdown(Context ctx) throws TomcatException {
if (debug>0) {
log("Removing TagPoolManagerImpl: " + ctx);
}
TagPoolManager manager = (TagPoolManager)
ctx.getAttribute(TagPoolManager.CONTEXT_ATTRIBUTE_NAME);
if (manager != null) {
ctx.removeAttribute(TagPoolManager.CONTEXT_ATTRIBUTE_NAME);
manager.shutdown();
} else {
if (debug>0) {
log("TagPoolManagerImpl not found for: " + ctx);
}
}
}
}
/*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* "This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/)."
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
*Foundation" must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called "Apache"
*nor may "Apache" appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* <http://www.apache.org/>.
*
*/
package org.apache.jasper.compiler;
import org.apache.jasper.runtime.TagPoolManager;
/**
* This class generates code during the initilization phase that
* declares and attempts to obtain a TagPoolManager.
*
* @author Casey Lucas <[EMAIL PROTECTED]>
* @see TagPoolManager
*/
public class TagPoolManagerGenerator extends GeneratorBase
implements InitMe
RE: first cut at tag pooling implementation
> > Great! > > > > You will do before/after performance comparisons? > > In the process... Ok, here are some basic numbers. For simple performance testing I wrote a jsp that uses an outer tag (BodyTag iteration style) and an inner tag. I placed timings around the outer tag. Based on 3.3 (nightly from a couple of days ago) and running 1 iterations, over 10 runs each from one browser... tag processing took avg of: pre tag pooling: 7362 milliseconds tag pooling patches (pooling enabled): 1586 milli tag pooling patches (pooling disabled): 6494 milli Yes, I know most pages don't have 1 tags and my tests are far from rigorous, but I just wanted to get a rough estimation. I found it interesting that the patched (but pooling disabled) runs were faster than the originals. The only thing that I can think of that might be different is that the old code had some references to a static variable that I removed. I'm not sure if that could/ would make a difference. Maybe there was something else going on. > > > > > Have you tested your changes with Watchdog? > > > Well I tried to run the patches with watchdog and became worried when some of the tests failed. But the ones that failed appeared to be the same ones that failed with the originals. Are the nightly builds supposed to pass watchdog tests? Hopefully the 3.3m2 stuff will work cleanly with watchdog and I can test against that. -Casey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: first cut at tag pooling implementation
> Great! > > You will do before/after performance comparisons? In the process... > > Have you tested your changes with Watchdog? > No, not yet. I'm still new to tomcat development but I'll get familiar with watchdog. > Which version of the Tomcat source are you working with? 3.3 with jdk 1.3 but hopefully it will port easily to others. I was hoping for comments before verifying other builds. BTW, I love your sig. I'm a terrible speller too. -casey > > Regards, > > Glenn > > Casey Lucas wrote: > > > > The attached files and diffs are based on 3.3 (hopefully latest code). > > They add tag pooling for tomcat. I hope that some of you will have > > time to take a look and provide feedback. I mainly tested with our > > application that uses a lot of tags. > > > > To disable pooling, don't include the TagPoolManagerInterceptor > > interceptor. Jasper will still generate pooling code, but pooling > > won't be used at runtime. > > > > Summary of changes: > > > > 1. changed jasper to add tag pool support > > > > files changed: > > org.apache.jasper.compiler. > > JspParseEventListener.java > > TagBeginGenerator.java > > TagEndGenerator.java > > > > files added: > > org.apache.jasper.compiler. > > TagPoolManagerGenerator.java > > TagPoolGenerator.java > > > > 2. added tag pooling classes / interfaces > > files added: > > org.apache.jasper.runtime. > > TagHandlerPool.java > > TagHandlerPoolImpl.java > > TagPoolManager.java > > TagPoolManagerImpl.java > > > > 3. added interceptor to enable tagging > > files added: > > org.apache.tomcat.modules.tagpool. > > TagPoolManagerInterceptor.java > > > > 4. changed modules.xml and server.xml > > added this text to end of modules.xml: > > > > javaClass="org.apache.tomcat.modules.tagpool.TagPoolManagerInterceptor"> > > > > Not yet > > > > > > added this text to end of server.xml: > > > > > > I'll post performance numbers as soon as I have something > > put togehter. Please let me know if anyone has comments. > > > > -Casey > > > > > > Name: JspParseEventListener.java.diff > >JspParseEventListener.java.diff Type: unspecified type >(application/octet-stream) > > Encoding: quoted-printable > > Download Status: Not downloaded with message > > > > Name: TagBeginGenerator.java.diff > >TagBeginGenerator.java.diff Type: unspecified type >(application/octet-stream) > > Encoding: quoted-printable > > Download Status: Not downloaded with message > > > >Name: TagEndGenerator.java.diff > >TagEndGenerator.java.diff Type: unspecified type >(application/octet-stream) > >Encoding: quoted-printable > > Download Status: Not downloaded with message > > > > Name: TagHandlerPool.java > >TagHandlerPool.java Type: JavaScript Program >(application/x-javascript) > > Encoding: quoted-printable > > Download Status: Not downloaded with message > > > > Name: TagHandlerPoolImpl.java > >TagHandlerPoolImpl.java Type: JavaScript Program >(application/x-javascript) > > Encoding: quoted-printable > > Download Status: Not downloaded with message > > > >Name: TagPoolGenerator.java > >TagPoolGenerator.java Type: JavaScript Program >(application/x-javascript) > >Encoding: quoted-printable > > Download Status: Not downloaded with message > > > > Name: TagPoolManager.java > >TagPoolManager.java Type: JavaScript Program >(application/x-javascript) > > Encoding: quoted-printable > > Download Status: Not downloaded with message > &g
first cut at tag pooling implementation
The attached files and diffs are based on 3.3 (hopefully latest code). They add tag pooling for tomcat. I hope that some of you will have time to take a look and provide feedback. I mainly tested with our application that uses a lot of tags. To disable pooling, don't include the TagPoolManagerInterceptor interceptor. Jasper will still generate pooling code, but pooling won't be used at runtime. Summary of changes: 1. changed jasper to add tag pool support files changed: org.apache.jasper.compiler. JspParseEventListener.java TagBeginGenerator.java TagEndGenerator.java files added: org.apache.jasper.compiler. TagPoolManagerGenerator.java TagPoolGenerator.java 2. added tag pooling classes / interfaces files added: org.apache.jasper.runtime. TagHandlerPool.java TagHandlerPoolImpl.java TagPoolManager.java TagPoolManagerImpl.java 3. added interceptor to enable tagging files added: org.apache.tomcat.modules.tagpool. TagPoolManagerInterceptor.java 4. changed modules.xml and server.xml added this text to end of modules.xml: Not yet added this text to end of server.xml: I'll post performance numbers as soon as I have something put togehter. Please let me know if anyone has comments. -Casey JspParseEventListener.java.diff TagBeginGenerator.java.diff TagEndGenerator.java.diff TagHandlerPool.java TagHandlerPoolImpl.java TagPoolGenerator.java TagPoolManager.java TagPoolManagerGenerator.java TagPoolManagerImpl.java TagPoolManagerInterceptor.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: where to plug-in startup/shutdown knowledge for internal tomcat components
I pulled src for 3.3 m2 (with jasper.runtime in common dir) and it all started working cool! Additionally, I have a much better understanding of tomcat's use of ClassLoaders. Thanks for the help. -Casey > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Sunday, March 11, 2001 3:27 AM > To: [EMAIL PROTECTED] > Subject: RE: where to plug-in startup/shutdown knowledge for internal > tomcat components > > > Hi Casey, > > I agree, resolving class loader problems is not easy. But it does have a > bit of logic :-) > > The solution you found ( put everything in common/ ) is ok - that's how > tomcat worked in 3.2 and before, and still works. > > Resolving the problem with a separate class loader for container is a bit > more difficult - the main benefit is that the container implementation ( > modules and libs that are used - including jaxp ) are separated from the > web application. > > > attempt 1: > > > > For each contextInit, TagPoolManagerInterceptor called > > TagPoolManager.setDefaultManager with a newly created TagPoolManagerImpl, > > yet when the jsp called TagPoolManager.getDefaultManager, the static > > reference set in setDefaultManager came back null. > > Try to do a println( TagPoolManager.getClassLoader().toString() ) every > time you use it. You'll see what happens ( 2 different class loaders ). > > You can also try to print the parent loader. > > > > Giving up on that, I tried 2: > > > > Use no statics, just call Context.setAttribute in the interceptor. In > > the jsp use Context.getAttribute. The object that comes back is > > the exact same TagPoolManagerImpl that was put there by the interceptor > > but if I try to cast it to a TagPoolManager (or TagPoolManagerImpl for > > that matter), I get a ClassCastException. > > Same problem - different class loaders -> different classes :-) > > > I was originally trying to follow the model of JspFactory. I modeled my > > interceptor after the JspInterceptor, but no luck for me. I noticed that > > sevlet.jar was both in TC_HOME/lib and TC_HOME/lib/common. Maybe that's > > That was fixed recently, servlet.jar should be only in common. > > > > why JspFactory works. I jared up the TagPool* classes and stuck them into > > TC_HOME/lib/common and everything worked. Even though it worked, it didn't > > seem right putting jasper.runtime.Tag* classes into the common directory. > > Any help / suggestions would be greatly appreciated. > > jasper.runtime is now in common ( we did a number of fixes since M1 ). > Everything that should be visible to webapps ( and jasper runtime is one > example - since jsps are using the classes from runtime ) should be in > common ( i.e. visible in both apps and container ). > > Jasper itself ( the compiler ) is in a separate loader. > > Think of the container as another application, that happens to provide > some services to other apps. > > The common dir is what all applications are seeing ( including the > container ). Each app has it's own local jars, providing the local > functionality. The container provides jsp compilation, configuration, > and other services that are used by tomcat. > > Costin > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: where to plug-in startup/shutdown knowledge for internal tomcat components
Ok, I'm going crazy. I had everything setup like you recommended (at least I thought I did), but I'm still running into problems. scenarios: TagPoolManagerInterceptor is in package org.apache.tomcat.modules.tagpool TagPoolManager (Impl, etc) are in org.apache.jasper.runtime attempt 1: For each contextInit, TagPoolManagerInterceptor called TagPoolManager.setDefaultManager with a newly created TagPoolManagerImpl, yet when the jsp called TagPoolManager.getDefaultManager, the static reference set in setDefaultManager came back null. Giving up on that, I tried 2: Use no statics, just call Context.setAttribute in the interceptor. In the jsp use Context.getAttribute. The object that comes back is the exact same TagPoolManagerImpl that was put there by the interceptor but if I try to cast it to a TagPoolManager (or TagPoolManagerImpl for that matter), I get a ClassCastException. I was originally trying to follow the model of JspFactory. I modeled my interceptor after the JspInterceptor, but no luck for me. I noticed that sevlet.jar was both in TC_HOME/lib and TC_HOME/lib/common. Maybe that's why JspFactory works. I jared up the TagPool* classes and stuck them into TC_HOME/lib/common and everything worked. Even though it worked, it didn't seem right putting jasper.runtime.Tag* classes into the common directory. Any help / suggestions would be greatly appreciated. -Casey > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Saturday, March 10, 2001 1:13 AM > To: [EMAIL PROTECTED] > Subject: RE: where to plug-in startup/shutdown knowledge for internal > tomcat components > > > Hi Casey, > > Welcome to the wonderful world of ClassLoading. > > The default configuration for 3.3 is to use a separate class loader for > container ( i.e. tomcat.core, jasper, jaxp ) and web applications. > > This resolves a number of problems - like having a different parser in the > web application. > > It also resolves the problem of overriding and fine-control over what is > seen in the web app, and does enhance the security ( most classes that are > visible in container are "trusted" ). > > But what I love about this is that it forces us to make a clear > distinction between what is runtime and what is internal to the container. > > To answer to your problem: I assume TagPoolManager will be available at > runtime to jsps. So it should be included in the common runtime, shared by > both webapps and container. > > TagPoolInterceptor is a container extension, so it'll be part of the > container loader. You shouldn't use static fields in general, but if you > do keep in mind that "static" refers to the ClassLoader+Class combination > ( you have one instance of the static field for each class loader ). > > BTW, this operating mode ( with multiple loaders ) is the most flexible > for tomcat. The old mechanism still works ( with the old limitations ), > but requires some code to enable it ( it's mostly for embeded tomcat ). > > > Costin > > > On Sat, 10 Mar 2001, Casey Lucas wrote: > > > > Now, I'm testing the pooling stuff out. I've got a > > TagPoolManagerInterceptor that listens to contextInit, etc. But my > > problem is that the static TagPoolManager reference that I initialize > > in contextInit always ends up null when the jsp runs. I put a print statement > > in the static initializer of TagPoolManager and I can see that it is > > being called once when tomcat starts up (and the various contexts are > > loaded) and a second time when the jsp is run. I assume that there's > > some class loader stuff going on that I don't understand. > > > > I looked at JspFactory because I'm using the same set/getDefault idiom. > > It some how keeps its static reference that is initilized in contextInit. > > My code seems to be just like JspFactory, yet my static gets reinitialized > > to null. > > > > Any suggestions? > > > > -Casey > > > > > -Original Message- > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > > Sent: Friday, March 09, 2001 2:29 PM > > > To: [EMAIL PROTECTED] > > > Subject: RE: where to plug-in startup/shutdown knowledge for internal > > > tomcat components > > > > > > > > > On Fri, 9 Mar 2001, Casey Lucas wrote: > > > > > > > So, given all that, I need to control lifetime of TagHandlerPoolManager's > > > > default instance. By controlling it, I can have one TagHandlerPoolManager > > > > instance per web application and when the web application gets unloaded, > > > >
RE: where to plug-in startup/shutdown knowledge for internal tomcat components
Costin. Thanks for the help and sorry for all the questions. I wasn't familiar with tomcat hooks and didn't understand the JspInterceptor. But that was then... Now, I'm testing the pooling stuff out. I've got a TagPoolManagerInterceptor that listens to contextInit, etc. But my problem is that the static TagPoolManager reference that I initialize in contextInit always ends up null when the jsp runs. I put a print statement in the static initializer of TagPoolManager and I can see that it is being called once when tomcat starts up (and the various contexts are loaded) and a second time when the jsp is run. I assume that there's some class loader stuff going on that I don't understand. I looked at JspFactory because I'm using the same set/getDefault idiom. It some how keeps its static reference that is initilized in contextInit. My code seems to be just like JspFactory, yet my static gets reinitialized to null. Any suggestions? -Casey > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Friday, March 09, 2001 2:29 PM > To: [EMAIL PROTECTED] > Subject: RE: where to plug-in startup/shutdown knowledge for internal > tomcat components > > > On Fri, 9 Mar 2001, Casey Lucas wrote: > > > So, given all that, I need to control lifetime of TagHandlerPoolManager's > > default instance. By controlling it, I can have one TagHandlerPoolManager > > instance per web application and when the web application gets unloaded, > > all the Tag.release methods can be called. Aren't the JspServlet and > > JspInterceptor mechanisms specific to an individual jsp file? If so, > > I don't think that's what I need because pooling will be for the entire > > web application not a specific JSP. > > > I was hoping that when the web application (not individual jsp) is > > loaded, unloaded, reloaded I could do the TagHandlerPoolManager initialization > > and cleanup tasks. Maybe I'm making things too complicated. Should > > managing the lifetime of a per-web-application object like > > TagHandlerPoolManager be simpler? > > And you have 2 solutions: > 1. Use tomcat hooks. You can let a tomcat module manager the > TagHandlerPool and you'll get all the notifications you need. > Just implement and TagPoolManagerInterceptor module, implement > the hooks you need ( addContext, contextInit, reload, etc). > > 2. Use some "hacks" in the generated init()/destroy(). > For example, in init() you can use a context attribute ( TagPoolManager ), > if not set you'll create it and init, if it's set you just use it. > > > Am I off base, with my general strategy? > > No, it is ok. > > > Also, regarding 3.x and 4.x, I'd like to keep it usable / adaptable > > to all. We're currently using 3, but will eventually migrate to 4. > > 4.x also have a mechanism to notify you about events - either a 2.3 filter > or use the internal Listener interfaces, and most decent servlet > containers will provide such a mechanism. > > As long as you keep a simple interface to your tag pool, it should be easy > to write the container-specific adapter that will plug it in. > > > Costin > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: where to plug-in startup/shutdown knowledge for internal tomcat components
ainer's internal APIs. > > In any case, remember that Jasper-generated servlets can be used via JspC > - i.e. pre-compiled into servlets, without any jsp-specific code ( > JspInterceptor acts like a runtime JspC ). So putting your code into > JspServlet will be a bad choice. > > One way is to use tomcat3.3 hooks ( contextInit, reload, > requestMap, pre/postRequest, etc ), and eventually take advantage of the > per/request ( and thread ) and per context storage ( in 3.3, each Thread > has it's own set of Request/Response - so request notes are equivalent > with per thread data ). > > The other way is to do tricks in the generated servlet. For example > on init() you can check a context attribute, and if not set you can do the > context initialization and set the attribute. As long as you use > "global" objects, reloading shouldn't affect you. You can use jasper > runtime object to put the common code, so the generated code will remain > small. > > Both solutions have advantages - and it's even possible to do a > mix. > > My recomandation - just use a SimplePool, implement the "real" code ( tag > pooling ), without worry about how the pool will look like or will be > hooked. After this works, we'll find a solution ( or 2 ) for this issue. > > > Costin > > > On Fri, 9 Mar 2001, Casey Lucas wrote: > > > > > I'm doing some prototyping for tag pooling in tomcat (based on > > the 3.3 tree.) I'd like to implement tag handler pooling > > per web application. Can someone point me to where I can > > hook into in order to setup the internal pool stuff when > > each web application starts, stop, reloads, etc.? > > > > I need to do things like setup the pooling strategy > > when each web application starts and release all the tag > > handlers when the application shuts down. > > > > Sorry if this is a dumb question, but hopefully someone > > can save me a lot of time. > > > > thanks. > > > > -Casey > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, email: [EMAIL PROTECTED] > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
where to plug-in startup/shutdown knowledge for internal tomcat components
I'm doing some prototyping for tag pooling in tomcat (based on the 3.3 tree.) I'd like to implement tag handler pooling per web application. Can someone point me to where I can hook into in order to setup the internal pool stuff when each web application starts, stop, reloads, etc.? I need to do things like setup the pooling strategy when each web application starts and release all the tag handlers when the application shuts down. Sorry if this is a dumb question, but hopefully someone can save me a lot of time. thanks. -Casey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: tag handler pooling ideas
Thanks for the comments. > > Just a quick note - my experience so far with server-side performance is > that it doesn't matter how many objects you create, as long as you do it > only once ( and not for each request ). > Right. I was planning on using a web-application-wide collection of pools. > I don't think doing any reuse inside a page ( i.e. same tag instance > beeing reused during a request ) is worth the effort at this stage - > you'll get most of the benefit and improvements by just using a pool and > reusing the tags from request to request - if possible. > Later you can do more advanced things. > True. I didn't plan on tackling that one yet. So, each time a new handler is needed in a page, it will be retrieved from its pool. > Another note - it would be nice if the pool interface is not very > hardcoded in the implementation. Do you mean using interfaces, etc? If so, I agree. > Most of the time there is a sync() that > is hard to avoid in pools, and you get a good improvement by using > thread data ( in a form or another ). This is a bit hard because the > same page may be accessed in multiple threads - so you'll have to keep tag > instances duplicated per thread - but there are solutions to control it > without affecting the response time, and most of the times few pages get > most of the hits - so it's not like all the tags from all the pages will > be cached at all times. > Well I can do a pool per thread, but my assumption is that there could possibly be a lot of tag handlers sitting around. Should this be a concern? Also, I don't know the exact thread pooling model that Tomcat uses, but if it creates and destroys worker thread, that will hurt the pool-per-thread model. By doing a web application wide collection of pools, there will be a synchronized pop (or similar) per handler retrieval and a synchronized push (or similar) per handler return to the pool. The synchronization will occur for handlers that are in the same pool across pages. Do you think this might be a problem? I was thinking of a simple approach to the size of the pools: make sure that a handler is always available. This means that the size of each pool will grow to the max number of concurrent handlers used. This case is not any worse than the current case (newing one each time). -casey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: tag handler pooling ideas
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Hans > Bergsten > Sent: Wednesday, March 07, 2001 9:06 PM > To: [EMAIL PROTECTED] > Subject: Re: tag handler pooling ideas > > > Casey Lucas wrote: > > > > I am planning on implementing tag handler pooling and would like > > to throw out a few ideas for feedback: > > > > assumptions: > > - Tag handlers can only be reused if the same set of attributes > > are used for the tag. > > > > - Tag.relese is called only once -- at some point before the > > handler is garbage collected. > > I believe you must add one more restriction on reuse: you can only > reuse tag handlers that are on the same nesting level. For instance, > this case requires two tag handler instances even though they have > the same set of attributes: > > > > > True. This was an obvious one -- I just didn't mention it. > > basic idea: > > My general idea was to have a collection of named pools. Jasper > > could then render code to use the named pool to obtain handler > > instances instead of newing them each time. > > > > more info: > > Each tag handler pool would have a name that would include > > the tag's short name and the set of attributes that were used > > on the tag. > > If by "short name", you mean something that identifies both the > tag library and the tag, I'm with you. The prefix is not enough. > The prefix is assigned per page, and you can actually use different > prefixes for the same library in different pages, so you need > another unique name for the tag library as such. The same problem > exists with the taglib uri attribute value. Maybe you can use the > context-relative path to the TLD; no matter how the TLD is identified > by the taglib directive's uri attribute, it must always be resolved > to a path to the TLD, and that must be unique within one app. > Right. I wasn't planning on using the prefix. The taglib needs to be included, but I hadn't given the exact manner much thought. The TLD path sounds like a good idea. > > This would give us the correct reuse level. So > > for the following tags there would be two named pools (after > > taking into account attributes): > > > > > > > > > > > > To eliminate the need to lookup the pool by name each time a > > tag was needed, pool references could be rendered and initialized > > (looked up) when the jsp is initialized. Inside the main jsp > > method (_jspService), the pool references would be used directly. > > I'm not sure I follow. > Because there will be a collection (HashMap) of pools (Stacks), I don't want to lookup the correct pool for a handler every time a handler needs to be used. The overhead of string hash + lookup can be eliminated by declaring pool instance variables in the rendered jsp. Upon jsp initialization, the pools could be looked up. Subsequently the pool references could be used to get handlers when needed. What it boils down to is a Stack pop (synchronized for this one pool) instead of a HashMap lookup (synchronized across all tag pools) followed by the pop. Hopefully that made sense. -casey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
tag handler pooling ideas
I am planning on implementing tag handler pooling and would like to throw out a few ideas for feedback: assumptions: - Tag handlers can only be reused if the same set of attributes are used for the tag. - Tag.relese is called only once -- at some point before the handler is garbage collected. basic idea: My general idea was to have a collection of named pools. Jasper could then render code to use the named pool to obtain handler instances instead of newing them each time. more info: Each tag handler pool would have a name that would include the tag's short name and the set of attributes that were used on the tag. This would give us the correct reuse level. So for the following tags there would be two named pools (after taking into account attributes): To eliminate the need to lookup the pool by name each time a tag was needed, pool references could be rendered and initialized (looked up) when the jsp is initialized. Inside the main jsp method (_jspService), the pool references would be used directly. When the pools are removed (shutdown, reload, etc.) Tag.release will be called for each of the handlers. I assume that pools need to be per web application, but haven't given it a lot of thought. Any comments / suggestions? -Casey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Tag Handler Pooling Clarification
Sorry for the long message, but I'm a bit unclear on some Tag related spec details. I need to make sure I have a clear understanding before I start thinking about tag handler reuse implementation. My original understanding of Tag.release was that it was always called after a tag handler was used -- after doEndTag. After calling release, the JSP container could then put the tag handler back into a pool for reuse. So, I was under the impression that a tag handler could be treated simply as a pooled resource. Based on my understanding, all of our code simply set tag handler attributes to their default values in the release method. By doing this we set the tag handler to a "default" or "initialized" state. Subsequently, setPageContext, various setters, etc. could be called and the whole tag use process would proceed again. But, after a more careful reading of the tag sections of the JSP 1.2 spec, it appears that tag reuse can only occur when tags have the same set of attributes that are initialized in the JSP. Specifically, in section 10.1.1 under the "Lifecycle" section, bullet [3] states: Note that since there are no guarantees on the state of the properties, a tag handler that had some optional properties set can only be reused if those properties are set to a new (known) value. This means that tag handlers can only be reused within the same "Att-Set" (set of attributes that have been set). This part of the spec could be interpreted to mean that tag handlers should only be reused if they have the same set of attributes. For example, given the following JSP fragment, two different tag1 handlers would have to be used (instead of reusing the handler): I hope that I'm misunderstanding something. I'd much prefer that the JSP container can rely on the handler's release method to reset the handler to a known state and simply start the tag process over again (setPageContext, setters, etc.) Such an assumption would greatly simplify a pooling strategy. Can anyone provide clarification? -Casey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: re-use of tag objects via Tag.release method
Ok, I'll bite. Where's the best place to start looking? Code that does the rendering? Wasn't there at one point talk of making the renderer more "pluggable"? -Casey -Original Message- From: Pierre Delisle [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 01, 2001 3:22 PM To: [EMAIL PROTECTED] Subject: Re: re-use of tag objects via Tag.release method Casey Lucas wrote: > > Looking at the rendered jsp -> java files in the work directory > (and noticing the calls to Tag.release), I realized that Jasper > is not reusing tags that it creates. So, my question is: > > Has there been any conversations about implementing tag > reuse in Jasper? To my knowledge, there has been no conversation on the topic. But, it'd be great to start one :-). Besides the obvious performance gains, having agressive tag reuse in tomcat would also be great for taglibs testing purposes. Properly handling 'release()' in a tag can be tricky and bugs will only show up when a tag is run in a container that supports 'tag reuse'. -- Pierre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - This email server is running an evaluation copy of the MailShield anti- spam software. Please contact your email administrator if you have any questions about this message. MailShield product info: www.mailshield.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
re-use of tag objects via Tag.release method
Looking at the rendered jsp -> java files in the work directory (and noticing the calls to Tag.release), I realized that Jasper is not reusing tags that it creates. So, my question is: Has there been any conversations about implementing tag reuse in Jasper? -Casey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[PATCH] custom tag performance problem
It's great to see that the 3.2.2 beta is out but it was sad to see that there's still a performance problem in certain situations with custom tags. I submitted the patch a few weeks back but I'm sure you all are very busy. So, given the recent threads about performance, I'll plea my case again... The problem should be apparent in at least two situations: 1. if you are using custom tags that derive from BodyTagSupport and have larger than 8K body. 2. if you are using a lot of nested tags (e.g. inside iteration type tags.) Basically the problem is that BodyContentImpl allocates a new buffer in situations where it doesn't need to. This causes a lot of 8K or larger buffers to be used -- ouch. After applying the patch, my test runs went from spending an average of 17% time in BodyContentImpl.reAllocBuff and BodyContentImpl.clear to spending an average of 5.6% time in BodyContentImpl.reAllocBuff (clear had almost 0% time.) I've attached the patch for BodyContentImpl.java. BodyContentImpl.diff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
optimization of BodyContentImpl
Last week I sent a message about some optimizations that might be added to tomcat, but didn't see any response. Can someone tell me what the normal procedure for suggesting code changes is? patch format? work with a developer that is a commiter? I'm not trying to nag, I just want to make sure I sent the suggestion to the right place and in the right way -- I'm new to the tomcat open source development procedures. thanks. -Casey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
BodyContentImpl optimization
Hopefully this is the right place for the following information. If not, I'm sorry. I don't really do active development on tomcat (cvs updates, etc) but while profiling our application, I noticed a couple of minor improvements that could be made to BodyContentImpl.java. Specifically, in 'reAllocBuff', a buffer allocation and arraycopy can be removed. In 'clear', a buffer allocation can be removed. We use a lot of tags and some of them have large bodies (causing calls to reAllocBuff), so both reAllocBuff and clear showed up as "hot spots". The diff is below: 110,111c110 < char[] tmp = new char [bufferSize] < System.arraycopy(cb, 0, tmp, 0, cb.length) --- > char[] tmp = null 116c115 < cb = new char [bufferSize + Constants.DEFAULT_BUFFER_SIZE] --- > tmp = new char [bufferSize + Constants.DEFAULT_BUFFER_SIZE] 119c118 < cb = new char [bufferSize + len] --- > tmp = new char [bufferSize + len] 122c121,122 < System.arraycopy(tmp, 0, cb, 0, tmp.length) --- > System.arraycopy(cb, 0, tmp, 0, cb.length) >cb = tmp 502,503d501 < cb = new char [Constants.DEFAULT_BUFFER_SIZE] < bufferSize = Constants.DEFAULT_BUFFER_SIZE I hope someone can make use of this. -Casey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
