tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Costin Manolache" <cos...@gmail.com>
Subject Re: What's about unloading policy of jsp-servlets ?
Date Wed, 17 May 2006 16:29:30 GMT
A different side of this - JspServlet and the code we are using to compile
and load
servlets is quite complex ( and ugly in some places ). There are a lot of
weird cases where tomcat needs
 to do special things for jsps, and jsps may behave differently than a
servlet. All this
is IMO a bad thing, and I think Remy's concerns are in part due to this.

He is also right in that JSPs are _not_ templates, they are supposed to work
just like
servlets.

Few questions:
- do you compile the 10.000 jsps at runtime, or part of the build and then
at runtime
they behave like regular servlets ( but still want to unload what is not in
use ) ?

- could you use a different JspServlet in your application - that would add
unloading,
but without adding this to the real JspServlet ( maybe just add few hooks )
? If so, then
I think getting the hooks in could be done, and you could keep the extra
features in a
separate module ( maybe in sandbox or sf.net or some modules directory, not
part
of the core distro initially ).

- or maybe this could be done at a lower level - i.e. for all servlets ?
Maybe add few hooks to
allow servlets to be unloaded ( via JMX for example ), and have a separate
monitoring module that
picks servlets to unload based on any criteria.

In general - I think getting few extra hooks to enable this would be doable,
even more if it
would allow simplifying the current code. Then for the actual module - it
may be added later,
after it proves to be generally useful or maybe remain a separate component
for special needs.


Costin


On 5/17/06, Oliver Dewdney <oliver.dewdney@lbicon.co.uk> wrote:
>
> The issue of too many jsp files loaded is an issue for us as well. We have
> a
> CMS system that generates jsp files as its output and while it is not the
> best model for publishing content, it is certainly easy! We have > 10,000
> jsp files generated through templates putting a mixture of static and
> dynamic content on the pages. The solution is not to buy more memory as we
> are on a 32-bit machine and have given all available user mode memory to
> the
> jvm.
>
> I do not think that it is a isolated case, but a very significant problem,
> and a significant number of application servers have the ability to set
> the
> number of cached templates/what have yous - even IIS3!
>
> I am working on a patch which addresses some of the issues raised in the
> thread, such as turn-on-able and not altering the code path too much in it
> off state. I think that also the issue of unloading is not valid, as it
> already happens when a dependant file changes and the jsp is recompiled.
> Of
> course if the jsp had a one time only initialization requirement then the
> developer could specify not to enable the LRU cache of jsp servlet engine.
>
> I think that the externalizing of static string data is a diversion on the
> problem, but I would go for a single buffer and use JspWriter.write( cbuf,
> offset, length ) to sent the right portion.
>
> So, what are the requirement to getting a patch accepted in tomcat 5.5?
>
> Oli Dewdney
> Senior Developer
> LB Icon
>
> This e-mail is only intended for the person(s) to whom it is addressed and
> may contain confidential information. LB Icon does not accept
> responsibility
> for any loss or damage caused by this email or any attachments. Unless
> clearly stated to the contrary, any opinions or comments are personal to
> the
> writer and are not made on behalf of LB Icon. If you have received this
> e-mail in error, please notify us immediately at info@lbicon.co.uk and
> then
> delete this message from your system. Please do not copy it or use it for
> any purposes, or disclose its contents to any other person. Thank you for
> your co-operation.
>
> LB Icon is the business name of Aspect Internet Holdings Limited, Aspect
> Technologies Limited, LB Icon Limited and Escador Limited.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message