Hey guys,
From Edmunds perspective the ability to keep compiled pages around is
extremely important. When under load we have seen our application
servers freeze when forced to compile pages. To overcome this in our
traditional applications we now pre-compile all JSPs, place the
classes in the EAR classpath (under APP-INF/classes) and remove the
raw JSP files from the EAR. For CQ4 we also precompile JSPs and load
their classes into the repository. While compilation for a single JSP
is quick when one is faced with concurrent requests which cause
compilation one runs into issues with CPU load (which is already high
in a CMS backed application). I think that it is extremely important
to ensure we keep the ability to pre-compile and store JSP class files
in the repository so that we do not have to compile them on the fly
while serving traffic.
-paddy
On Nov 28, 2007, at 12:47 AM, David Nuescheler wrote:
Hi Bertrand,
...i'm strongly against removing the class files from the
repository.
from my experience it is very valuable if you can remove the classes
remotely....
Do you need to be able to remove individual class files from the
repository?
Definitely. Especially for larger projects, some real-life projects
run
with hundreds (if not thousands) of jsps, which used to be a huge
overhead to compile. how much of that is better now using a different
compiler and how much really was a jasper performance issue to begin
with I don't really know.
If you can live with a "delete all compiled JSP classes" function,
we
can probably find another solution, like a utility that can be called
from a script to do that.
Deleting JSPs is a development/debugging concern, having to call a
script (via a URL) to do that is not harder than having to know where
and when to delete stuff in the repository.
I am scared of everything that we don't put into the repository
considering
clustering and backup/restore issues.
I recall that we basically went to hell and back for everything that
we did
not put into the repository, so please be very careful with that.
Now for certain intermediary files that may not be an issue, I just
would
like to be very, very careful.
...I'm all for using a standard version, and forget about
having classes in the repository, at least for now.
i would not care. i reckon the changes are not very complicated and
can easily be reapplied to a new jasper version....
Sure, but it's easy to lose track, and I don't think we have a
comprehensive set of automated tests for Jasper.
Besides, having our own fork of Jasper bloats Sling and might make
people wary of why we have that - all kinds of warnings go off in my
programming brain when I see a project doing this.
I think we are looking for an additional abstraction when it comes
to the place where we store the resulting servlet source, right?
Well, let's see if we can come up with a good patch that is convincing
and non-intrusive to allow our abstraction into Jasper.
regards,
david
.ps: Is it correct that we don't have an issue actually compiling the
classes into the repository (and also classload them from the
repository),
our issue would the transpilation to the servlet java source, right?
(or did Jasper
remove that intermediary step while I was asleep for a bunch of
years ;))
