On 3/7/06, Remy Maucherat <[EMAIL PROTECTED]> wrote: > 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)
"slow" usually requires a context - i.e. server type, memory, CPU, expected load. And beeing 'fastest' is not allways the most important thing for everyone - fastest jsp won't help if it OOM or if other components get less memory. Footprint is as important as well. > - it adds complexity > - it will create additional code generation paths that will not be > tested (as usual) Almost every feature will add some complexity, and will be tested by the subset of people who need it ( example: the apr library :-) > - I contend that in 2006 it is useless It is useless for people who run huge servers and can fit everything in memory. It is not useless for people who have lots of JSPs or run on shared memory. > > > 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. We all cause some troubles from time to time, and tend to value our own opinions a bit high. Luckily - this is not about following my opinion or my troubles - it's about a tomcat feature. The fact that it's useless for yourself, or that 3.3 was slow, or that adding any code increases complexity and testing are not IMO valid reasons to veto. Costin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
