a webhosting company that has a shared JVM instance of tomcat for its websites and runs unmanaged code bumps into this kind of problem all the time ;)).
--- Leon Rosenberg <[EMAIL PROTECTED]> wrote: > Yaroslav, > > you've made great work with the patch, but honestly, > which real-world > application uses hunderds of megabytes of jsps? > > that just doesn't make sense... > > regards > Leon > > P.S. don't want to be offending, but i just can't > find a single use-case... > > On 3/7/06, Yaroslav Sokolov <[EMAIL PROTECTED]> > wrote: > > Ok, I can make the next conclusions: > > > > 1. Tomcat eats resources on first opening of any > jsp page and never returns > > them back - servlets just are never unloaded. > > 2. As it happens in all the versions of Tomcat, > there are many jsps, not > > meeting requirements > > of the specification (no destroy() method when > there is some useful data in > > fields) but well working under Tomcat. > > 3. We do not want to change this situation ( -> I > shall not even try to send > > any better patch here :-\ (but I will ;-) ) ) > > > > One more conclusion - if all the jsp content of > our web site does not fit in > > memory, we > > should buy more memory. Else we must not use jsp > technology in all the > > pages. We should choose > > something other than jsp, for example velocity, > SSI,... > > > > P.S. by the way, when web application is unloaded > such bad jsps lose data > > anyway. > > > > On 06/03/06, Costin Manolache <[EMAIL PROTECTED]> > wrote: > > > > > > Starting is different from stopping. > > > > > > Yes, the spec allows unloading - but in reality > most JSPs and servlets > > > can't deal well with that. And the argument that > it is optional > > > doesn't work - in many cases the person who > writes the servlet/jsp is > > > not the same as the person who is running the > production server or > > > does the configuration tunning. > > > > > > There are subtle bugs that may show up when this > feature would be > > > enabled - people doing the config might be > tempted to reduce memory > > > use, and this would result in extremely hard to > reproduce and debug > > > problems. > > > > > > By 'spec compliance' I mean more 'compatibility > with the existing spec > > > _and_ the current usage of the spec'. The later > is IMO more important > > > in many cases than the letter or any > interpretation of the spec. > > > > > > Costin > > > > > > On 3/6/06, Yaroslav Sokolov > <[EMAIL PROTECTED]> wrote: > > > > On 04/03/06, Remy Maucherat <[EMAIL PROTECTED]> > wrote: > > > > > > > > > > Costin Manolache wrote: > > > > > > But it's a separate issue - I agree that > unloading unused jsps is > > > the > > > > > > most important. > > > > > > > > > > The recommended production usage (= optimal) > of JSPs is when they are > > > > > precommpiled, which means that the Jasper > servlet is not used, and the > > > > > JSPs are plain servlets. Their lifecycle is > then identical to the > > > > > lifecycle of servlets. > > > > > > > > > > > > I do not see any reason, why different > servlets could not have different > > > > life cycles. > > > > Even more, the last sentence is in contrary to > current implementation - > > > > some servlets can be loaded not on demand, but > on starting of a web > > > > application. > > > > So, their life cycle has already been _not_ > identical to the life cycle > > > of > > > > other servlets. > > > > > > > > > > > > I understand the Jasper servlet is junk, and > is a testing ground for bad > > > > > ideas, though (ex: the background > compilation thread, and now this). > > > > > > > > > > Rémy > > > > > > > > > > > > > -- > > > > Regards, > > > > Yaroslav Sokolov. > > > > > > > > > > > > > > > > > -- > > Regards, > > Yaroslav Sokolov. > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
