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]
