Costin Manolache wrote:
Well, it the patch is based on unloading the JSP - it won't be easy,
the -1 that Remy expressed initially seems valid ( and all it takes to
make it valid is a second comitter, which I just did ). So according
to the rules it won't work - and even if it would work, it may still
cause unexpected breakage of applications which is bad.
If it externalizes the strings - I don't see what valid veto can be
raised, we did this in the past ( 3.3 - not complete ). It would also
help to have some simple 'ab' tests to show how much is lost in raw
performance - it's allways a tradeoff between memory and disk, and a
lot of applications work just fine without keeping all in memory - but
it's good to know numbers instead of talking about our assumptions.
Let's see:
- it will be slow (I can find really embarrassing Tomcat 3.x JSP
performance graphs, if you want)
- it adds complexity
- it will create additional code generation paths that will not be
tested (as usual)
- I contend that in 2006 it is useless
I feel strongly about this issue because I am concerned with using
tomcat in lower memory environments ( not only my extreme case, but
also on 'regular' computers where tomcat is not the center of the
universe and can't take all the memory ). Remy is obviously concerned
about big server case where performance is a very important issue.
Having a flag can do both cases - except that the code is already
complex, so it's better to be worth it. Of course, if the patch is
also cleaning up jspservlet and makes it easy - that won't be an issue
:-)
The problem is that the issues you care about have caused some trouble
lately, so I don't feel very compelled to follow your opinions on this one.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
