Why do you create jsps from the database instead of filling a small set of jsps with the content from the database?
Leon On 3/7/06, S. Dierkes <[EMAIL PROTECTED]> wrote: > If you're still searching for a real world application: we have an > application where JSP's are generated dynamically from database (no > on-the-fly because to time consuming, so they are created offline), > currently there had been ~1500 JSP's (~100MB) created (plus the application > itself). The application creates JSP and PDF of real-world forms (fill in as > html, print out as pdf) for different customers (mainly banks), so the > jsp-base is constantly increasing. > Ok, memory is not really an issue in production, since we can increase it on > demand, but a configurable memory behaviour could be a nice feature and > might save memory for other server purposes. Don't get me wrong, I think the > best solution for production is still more RAM, but at least for testing it > would be nice to have less needs for RAM. > > -----Ursprüngliche Nachricht----- > Von: Leon Rosenberg [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 7. März 2006 16:20 > An: Tomcat Developers List > Betreff: Re: What's about unloading policy of jsp-servlets ? > > > 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] > > > > > --------------------------------------------------------------------- > 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]
