On 3/7/06, Renato <[EMAIL PROTECTED]> wrote: > 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 ;)).
hmm... sorry, I host java webapps for customers, and this is my last problem. I mean a typical webapp contains approx. 100 classes and 50 jsps? Most of the classes are always in use and therefore in memory as well as the jsps. I don't really see the problem here. I mean before I run out of memory for JSPs, I will run out of memory for classes.... Leon > > --- 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
