Re: Effect of MaxThreads
Thanks for this. We tried it and it did fail. I don't understand the reasoning though, I would have thought that the whole point of a queue is to queue requests for which there is no available threads. And I would hope that threads would be returned to the pool when a request ends. It is not really Threads that we want to control, but rather the number of concurrent servlet requests processed. One other odd thing is that when we ran our multi threaded clients from two different client machines at the same time we received failures. It felt like different connectors were being used for different client machines, which does not make sense. They both reference the server with the same URL. We have Apache in front of Tomcat (for dubious but required reasons). Anyway, the bottom line is that I could not get maxThreads/acceptCount to effectively throttle calls to the servlets. (Which was required because the max connections parameter could not be set via JNDI for the Oracle Connection pooler, which was required because the application specifies the password which DBCP could not handle.) Regards, Anthony -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Bill Barker Sent: Tuesday, January 15, 2008 12:09 PM To: users@tomcat.apache.org Subject: Re: Effect of MaxThreads Yes, but the way that the default, non-APR, AJP/1.3 Connector works, connections generally will stay open tying up the corresponding threads. This means that acceptCount doesn't really do very much in this case. Tomcat will end up failing the request if it can't find a free thread for it. The APR and (experimental) NIO AJP/1.3 Connectors don't have this problem, since they don't have any link between the number of threads (which are only for active requests) and number of Socket connections. Caldarale, Charles R [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] EXCH2.na.uis.unisys.com... From: Berglas, Anthony [mailto:[EMAIL PROTECTED] Subject: Effect of MaxThreads Tomcat connectors provide maxThreads parameter to throttle the number of concurrent transactions. But what actually happens when this number is exceeded? It's in the doc: http://tomcat.apache.org/tomcat-6.0-doc/config/http.html acceptCount - The maximum queue length for incoming connection requests when all possible request processing threads are in use. Any requests received when the queue is full will be refused. The default value is 10. We have Apache in front of Tomcat (for dubious reasons). So why not remove the httpd overhead? - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DBCP user/password specified in getConnection
We have an app that uses connection pooling, but tries to specify the username/password in the code. In particular, it does not want the password to be in plain text in an xml file. There is only one username involved, so no issues with heterogeneous connection pools. Pretty basic requirement. Tomcat complains that this is not supported in Basic DBCP. Any pointers most welcome. If not possible with DBCP, what connection poolers do people recommend? C3p0? Thanks, Anthony (We had tried to use Oracle CP, but too hard to set max nr connections parameter which is a property, rather than reflected. Requires a special JNDI factory, or a future version of Tomcat.) -- Dr Anthony Berglas Ph. +61 7 3227 4410 Mob. +61 44 838 8874 [EMAIL PROTECTED]; [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Effect of MaxThreads
Tomcat connectors provide maxThreads parameter to throttle the number of concurrent transactions. But what actually happens when this number is exceeded? Are additional requests queued, or are they simply bounced? We have Apache in front of Tomcat (for dubious reasons). Where is the best place to throttle, Apache or Tomcat? Any ideas welcome. Thanks, Anthony -- Dr Anthony Berglas Ph. +61 7 3227 4410 Mob. +61 44 838 8874 [EMAIL PROTECTED]; [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Datasource Property Parameters (Oracle) JNDI
Hello, I am trying to set up 0racle connection pooling. Some of the parameters are reflected normally, but some are specified via a property lists. How do I set the property list properties using Tomcat/JNDI? I can set up the basic DataSource, but I cannot set the maxLimit parameter on the max number of connections because they are in the setConnectionCacheProperties property map, not reflected. More specifically, here is my conf/Catalina/localhost/KMS.conf (My web app is KMS). # cat /opt/tomcat/conf/Catalina/localhost/KMS.xml ?xml version=1.0 encoding=UTF-8? Context path=/KMS docBase=KMS debug=5 reloadable=true crossContext=true Resource name=jdbc/rkm auth=Container type=oracle.jdbc.pool.OracleDataSource driverClassName=oracle.jdbc.OracleDriver factory=oracle.jdbc.pool.OracleDataSourceFactory connectionCachingEnabled=true connectionCacheName=KmsConPool abandonedConnectionTimeout=200 connectionWaitTimeout=200 maxLimit=20 url=jdbc:oracle:thin:@localhost:1521:rsakmpri user=local password=-THIS-SHOULD-BE-IGNORED- / !-- maxLimit ignored -- /Context The problem is that parameters like connectionCachingEnabled are set reflectively and work but some such as MaxLimit are set in property lists. Specifically doing this in ordinary, easy Java, from the Oracle manual:- OracleDataSource ods = new OracleDataSource(); // set cache properties in map java.util.Properties prop = new java.util.Properties(); prop.setProperty(MinLimit, 2); prop.setProperty(MaxLimit, 10); // set DataSource properties String url = jdbc:oracle:oci8:@; ods.setURL(url); ods.setConnectionCacheProperties (prop); // ods.setUser(hr); ods.setPassword(hr); ods.setConnectionCachingEnabled(true); ods.setConnectionCacheName(ImplicitCache01); ... Connection conn = ods.getConnection(user, pass); But of course this is Enterprise software, so it must be done in XML, not Java. Any ideas as to how to do this most welcome. Anthony PS. I have never seen any reference to the ability to put a file like KMS.xml in the conf area. I certainly seems to work, and is very necessary -- obviously one does not want site config in a war -- but just not documented as far as I can tell. -- Dr Anthony Berglas Ph. +61 7 3227 4410 Mob. +61 44 838 8874 [EMAIL PROTECTED]; [EMAIL PROTECTED] -- Dr Anthony Berglas Ph. +61 7 3227 4410 Mob. +61 44 838 8874 [EMAIL PROTECTED]; [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fix to Tomcat Jasper slow .tag compilation problem.
As described in a previous post, Jasper is *extremely* slow at compiling
.tag files packaged in a .jar. Tens of seconds every time you touch a
new .jsp for the first time. Almost unusable if you use .tags
extensively, as I do.
The following few lines is a hack to fix this. The added code is marked
between // AJB markers. It effectively turns off the timestamp
checking on .jar files.
This does NOT actually introduce a bug. There is an existing bug in
that .jsp files are not automatically recompiled if any .tags in .jars
are changed. So you need to purge work in either case. A proper fix
would be to check dependencies properly, at least to the .jar file
itself. But the current fix is *much* better that the existing
behavior.
COULD SOMEBODY PLEASE ARRANGE FOR THIS CODE TO BE ADDED TO THE CURRENT
SUBVERSION REPOSITORY?
Outstanding is to make the compilation of .tags themselves much faster,
not tens of seconds. To do that one needs to call the Java compiler
once at the end for all the .tags, rather than once for each individual
.tag which is *much* slower.
I must admit that I got rather lost reading the Jasper source, with all
the contexts etc. Some better comments on the classes describing their
relationships to each other would be most helpful.
Thanks,
Anthony
// Tomcat 6.0.10 Src deployed version.
public class JspCompilationContext {...
public void compile() throws JasperException, FileNotFoundException
{
createCompiler();
// begin AJB
// Hack to stop .tag files that are packaged in .jars being
recompiled for every single .jsp that uses them.
// The hack means that .tag files will not be automatically
recompiled if they change -- you need to delete work area.
// But that was actually an existing bug -- .jsps are not
dependent on the .tag .jars so the work area needed deleting anyway.
// (Outstanding is to compile multiple .tags in one pass and so
make the process Much faster.)
boolean outDated;
if (isPackagedTagFile) outDated = ! new
File(getClassFileName()).exists();
else outDated = jspCompiler.isOutDated();
//AjbLog.log(### Compiler.compile + jspUri + pkgTagFile +
isPackagedTagFile + outDated + outDated + + getClassFileName());
if (outDated) {
// if (isPackagedTagFile || jspCompiler.isOutDated()) {
// end AJB
try {
jspCompiler.removeGeneratedFiles();
jspLoader = null;
jspCompiler.compile();
jsw.setReload(true);
jsw.setCompilationException(null);
} catch (JasperException ex) {
// Cache compilation exception
jsw.setCompilationException(ex);
throw ex;
} catch (Exception ex) {
JasperException je = new JasperException(
Localizer.getMessage(jsp.error.unable.compile),
ex);
// Cache compilation exception
jsw.setCompilationException(je);
throw je;
}
}
}
--
Dr Anthony Berglas
Ph. +61 7 3227 4410
Mob. +61 44 838 8874
[EMAIL PROTECTED]; [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Fix to Tomcat Jasper slow .tag compilation problem.
Precompiling would not help.
1. Precompiling JSPs with .tag files is broken in Jasper, if tags call
other tags.
2. If it were fixed I would imagine that it would still recompile each
tag over and over again. A precompile of a few dozen jsps would then
take hours.
The next issue to fix is the very slow one tag at a time Java compiles.
Then the dependencies can be looked at, but the code is fairly complex.
My enthusiasm for addressing these issues is dependent on the community
being able to incorporate my fixes into the core. Otherwise I fork
Tomcat, not a good idea.
My feeling is that my fix below will just be ignored.
Anthony
-Original Message-
From: Peng Tuck Kwok [mailto:[EMAIL PROTECTED]
Sent: Monday, October 29, 2007 8:17 PM
To: Tomcat Users List
Subject: Re: Fix to Tomcat Jasper slow .tag compilation problem.
Would pre-compiling your jsp files help you instead? AFAIK that works
on
the
tags so you probably don't need to touch jspc.
On 10/29/07, Berglas, Anthony [EMAIL PROTECTED] wrote:
As described in a previous post, Jasper is *extremely* slow at
compiling
.tag files packaged in a .jar. Tens of seconds every time you touch
a
new .jsp for the first time. Almost unusable if you use .tags
extensively, as I do.
The following few lines is a hack to fix this. The added code is
marked
between // AJB markers. It effectively turns off the
timestamp
checking on .jar files.
This does NOT actually introduce a bug. There is an existing bug in
that .jsp files are not automatically recompiled if any .tags in
.jars
are changed. So you need to purge work in either case. A proper
fix
would be to check dependencies properly, at least to the .jar file
itself. But the current fix is *much* better that the existing
behavior.
COULD SOMEBODY PLEASE ARRANGE FOR THIS CODE TO BE ADDED TO THE
CURRENT
SUBVERSION REPOSITORY?
Outstanding is to make the compilation of .tags themselves much
faster,
not tens of seconds. To do that one needs to call the Java compiler
once at the end for all the .tags, rather than once for each
individual
.tag which is *much* slower.
I must admit that I got rather lost reading the Jasper source, with
all
the contexts etc. Some better comments on the classes describing
their
relationships to each other would be most helpful.
Thanks,
Anthony
// Tomcat 6.0.10 Src deployed version.
public class JspCompilationContext {...
public void compile() throws JasperException,
FileNotFoundException
{
createCompiler();
// begin AJB
// Hack to stop .tag files that are packaged in .jars being
recompiled for every single .jsp that uses them.
// The hack means that .tag files will not be automatically
recompiled if they change -- you need to delete work area.
// But that was actually an existing bug -- .jsps are not
dependent on the .tag .jars so the work area needed deleting anyway.
// (Outstanding is to compile multiple .tags in one pass and
so
make the process Much faster.)
boolean outDated;
if (isPackagedTagFile) outDated = ! new
File(getClassFileName()).exists();
else outDated = jspCompiler.isOutDated();
//AjbLog.log(### Compiler.compile + jspUri + pkgTagFile
+
isPackagedTagFile + outDated + outDated + +
getClassFileName());
if (outDated) {
// if (isPackagedTagFile || jspCompiler.isOutDated()) {
// end AJB
try {
jspCompiler.removeGeneratedFiles();
jspLoader = null;
jspCompiler.compile();
jsw.setReload(true);
jsw.setCompilationException(null);
} catch (JasperException ex) {
// Cache compilation exception
jsw.setCompilationException(ex);
throw ex;
} catch (Exception ex) {
JasperException je = new JasperException(
Localizer.getMessage(jsp.error.unable.compile),
ex);
// Cache compilation exception
jsw.setCompilationException(je);
throw je;
}
}
}
--
Dr Anthony Berglas
Ph. +61 7 3227 4410
Mob. +61 44 838 8874
[EMAIL PROTECTED]; [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat SSL/HTTPS Performance vs Apache
Has anyone done any performance analysis of Tomcat's SSL performance, especially compared to Apache. It is rumored that Tomcat is unusable without Apache in front for SSL, but I wonder if that is true. Our application will have lots of clients making short connections, so it is the RSA processing time that is critical. Anthony -- Dr Anthony Berglas Ph. +61 7 3227 4410 (Mob. +61 42 783 0248) [EMAIL PROTECTED]; [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jasper Gobbling exceptions
When I call a JSP directly via web.xml exceptions provide a number of root cause stack traces the second or third of which indicates what the exception actually was and, with some deciphering, which .tag file generated it. The trace is shown on both the form and Tomcat standard output, which is handy. However when I call the JSP from a Servlet only the first, useless, JasperException is displayed. On has to go to the Tomcat log to see the real exception. This happens regardless of whether .forward or .include is used. Is it possible to invoke the JSP via the servelet and still get the underlying exception? (Would be handy during development.) Anthony -- Dr Anthony Berglas Ph. +61 7 3227 4410 (Mob. +61 42 783 0248) [EMAIL PROTECTED]; [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jasper compiler crashes
When I try to precompile I get a null pointer exception deep in
.servlet.JasperLoader.loadClass. Happens for almost all of my .jsps.
They work fine with incremental compile.
They do use tags defined with JSTL .tag files. Tags call tags.
tomcat-6.0.10-src
If anyone knows of decent docs on precompiling Jasper please let me
know. (I know about jasper-howto.html).
(And there is an underlying problem that Jasper is *extremely* slow to
compile. I can compile and build all of Tomcat itself from source in
less time than it takes to compile one medium sized JSP (about 30
seconds). It is difficult to imagine how even the sloppiest code could
run that slowly. Something is wrong. 100% CPU.)
Ant:-
taskdef classname=org.apache.jasper.JspC name=jasper2
classpath id=jspc.classpath
fileset dir=${tomcat}/bin
include name=*.jar/
/fileset
fileset dir=${tomcat.lib}
include name=*.jar/
/fileset
/classpath
/taskdef
!-- pathelement location=${java.home}/../lib/tools.jar/ --
target name=jspc description=Try prebuilding JSPs
delete dir=${tomcat}/webapps/plain_eg/WEB-INF/src/
mkdir dir=${tomcat}/webapps/plain_eg/WEB-INF/src/
jasper2
validateXml=false
uriroot=${tomcat}/webapps/plain_eg
webXmlFragment=WEB-INF/generated_web.xml
outputDir=${tomcat}/webapps/plain_eg/WEB-INF/src
failOnError=false
/
!-- showSuccess=true --
Stack trace:-
May 29, 2007 4:20:38 PM org.apache.jasper.JspC processFile
SEVERE: ERROR-the file '\token\autocrudtokentest.jsp' generated the
following general exception:
java.lang.NullPointerException
at sun.misc.URLClassPath$3.run(URLClassPath.java:316)
at java.security.AccessController.doPrivileged(Native Method)
at sun.misc.URLClassPath.getLoader(URLClassPath.java:313)
at sun.misc.URLClassPath.getLoader(URLClassPath.java:290)
at sun.misc.URLClassPath.getResource(URLClassPath.java:160)
at java.net.URLClassLoader$1.run(URLClassLoader.java:192)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at
org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:134)
at
org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:66)
at
org.apache.jasper.JspCompilationContext.load(JspCompilationContext.java:
598)
at
org.apache.jasper.servlet.JspServletWrapper.loadTagFile(JspServletWrappe
r.java:221)
at
org.apache.jasper.compiler.TagFileProcessor.loadTagFile(TagFileProcessor
.java:576)
at
org.apache.jasper.compiler.TagFileProcessor.access$000(TagFileProcessor.
java:50)
at
org.apache.jasper.compiler.TagFileProcessor$TagFileLoaderVisitor.visit(T
agFileProcessor.java:627)
at
org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1507)
at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2336)
at
org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2386)
at org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2392)
at org.apache.jasper.compiler.Node$Root.accept(Node.java:489)
at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2336)
at
org.apache.jasper.compiler.TagFileProcessor.loadTagFiles(TagFileProcesso
r.java:645)
at
org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:190)
at
org.apache.jasper.compiler.Compiler.compile(Compiler.java:306)
at
org.apache.jasper.compiler.Compiler.compile(Compiler.java:286)
at
org.apache.jasper.compiler.Compiler.compile(Compiler.java:273)
at
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.ja
va:566)
at
org.apache.jasper.servlet.JspServletWrapper.loadTagFile(JspServletWrappe
r.java:212)
at
org.apache.jasper.compiler.TagFileProcessor.loadTagFile(TagFileProcessor
.java:576)
at
org.apache.jasper.compiler.TagFileProcessor.access$000(TagFileProcessor.
java:50)
at
org.apache.jasper.compiler.TagFileProcessor$TagFileLoaderVisitor.visit(T
agFileProcessor.java:627)
at
org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1507)
at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2336)
at
org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2386)
at
org.apache.jasper.compiler.TagFileProcessor$TagFileLoaderVisitor.visit(T
agFileProcessor.java:631)
at
org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1507)
at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2336)
at
org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2386)
at org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2392)
at org.apache.jasper.compiler.Node$Root.accept(Node.java:489)
at
RE: Jasper compiler crashes
Thanks for that, but I don't see how it will help. If you look below
it is the jasper2 that is causing me grief, which is essentially the
same as yours.
How long does it take to precompile the JSPs. Is it several JSPs per
second or several seconds per JSP? My JSPs take over 20 seconds to
compile interactively, which would make precompiling all of them
infeasible except for a nightly build.
I'm surprised that your script needs those package rename hacks. Feels
like precompiling into Tomcat's work area should be built in,
bin/precompileJsps.bat|.sh.
Thanks,
Anthony
-Original Message-
From: Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 30, 2007 12:20 AM
To: Tomcat Users List
Subject: Re: Jasper compiler crashes
What I like to do is to compile my JSPs just like Tomcat would do it
runtime, so that I can keep the ability to recompile my JSP files.
http://people.apache.org/~fhanik/precompile.html
http://people.apache.org/~fhanik/tomcat-6-precompile.xml
I just whipped up the v6 script, but I believe it to work properly.
Filip
Berglas, Anthony wrote:
When I try to precompile I get a null pointer exception deep in
.servlet.JasperLoader.loadClass. Happens for almost all of my
.jsps.
They work fine with incremental compile.
They do use tags defined with JSTL .tag files. Tags call tags.
tomcat-6.0.10-src
If anyone knows of decent docs on precompiling Jasper please let me
know. (I know about jasper-howto.html).
(And there is an underlying problem that Jasper is *extremely* slow
to
compile. I can compile and build all of Tomcat itself from source
in
less time than it takes to compile one medium sized JSP (about 30
seconds). It is difficult to imagine how even the sloppiest code
could
run that slowly. Something is wrong. 100% CPU.)
Ant:-
taskdef classname=org.apache.jasper.JspC name=jasper2
classpath id=jspc.classpath
fileset dir=${tomcat}/bin
include name=*.jar/
/fileset
fileset dir=${tomcat.lib}
include name=*.jar/
/fileset
/classpath
/taskdef
!-- pathelement location=${java.home}/../lib/tools.jar/
--
target name=jspc description=Try prebuilding JSPs
delete dir=${tomcat}/webapps/plain_eg/WEB-INF/src/
mkdir dir=${tomcat}/webapps/plain_eg/WEB-INF/src/
jasper2
validateXml=false
uriroot=${tomcat}/webapps/plain_eg
webXmlFragment=WEB-INF/generated_web.xml
outputDir=${tomcat}/webapps/plain_eg/WEB-INF/src
failOnError=false
/
!-- showSuccess=true --
Stack trace:-
May 29, 2007 4:20:38 PM org.apache.jasper.JspC processFile
SEVERE: ERROR-the file '\token\autocrudtokentest.jsp' generated the
following general exception:
java.lang.NullPointerException
at sun.misc.URLClassPath$3.run(URLClassPath.java:316)
at java.security.AccessController.doPrivileged(Native Method)
at sun.misc.URLClassPath.getLoader(URLClassPath.java:313)
at sun.misc.URLClassPath.getLoader(URLClassPath.java:290)
at sun.misc.URLClassPath.getResource(URLClassPath.java:160)
at java.net.URLClassLoader$1.run(URLClassLoader.java:192)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at
org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:134)
at
org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:66)
at
org.apache.jasper.JspCompilationContext.load(JspCompilationContext.java:
598)
at
org.apache.jasper.servlet.JspServletWrapper.loadTagFile(JspServletWrappe
r.java:221)
at
org.apache.jasper.compiler.TagFileProcessor.loadTagFile(TagFileProcessor
.java:576)
at
org.apache.jasper.compiler.TagFileProcessor.access$000(TagFileProcessor.
java:50)
at
org.apache.jasper.compiler.TagFileProcessor$TagFileLoaderVisitor.visit(T
agFileProcessor.java:627)
at
org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1507)
at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2336)
at
org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2386)
at org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2392)
at org.apache.jasper.compiler.Node$Root.accept(Node.java:489)
at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2336)
at
org.apache.jasper.compiler.TagFileProcessor.loadTagFiles(TagFileProcesso
r.java:645)
at
org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:190)
at
org.apache.jasper.compiler.Compiler.compile(Compiler.java:306)
at
org.apache.jasper.compiler.Compiler.compile(Compiler.java:286)
at
org.apache.jasper.compiler.Compiler.compile(Compiler.java:273
RE: Jasper compiler very slow
Thanks for the replies. But I suspect that there is something very odd going on, and possibly preventable. There is just no way that any reasonably written code could take that long to compile JSP. I have checked that it is CPU bound. Maybe there is some O(n^4) algorithm in there, but I cannot imagine what. Anthony -Original Message- From: Rashmi Rubdi [mailto:[EMAIL PROTECTED] Sent: Thursday, April 19, 2007 12:42 PM To: Tomcat Users List Subject: Re: Jasper compiler very slow Anthony, Please ignore my first reply on this thread, I misunderstood your post, the reply I posted is irrelevant. Here's my new reply : On 4/18/07, Berglas, Anthony [EMAIL PROTECTED] wrote: Hello All, The compile time for my .jsp pages is extremely slow -- like 10 seconds on a modern PC to the first time any page is run. Painful during development. I agree that 10 seconds is too long, normally having JSP pages with a lot of plain-text, causes them to be slow, also JSP page load time can be attributed to non-optimized application layer code as well. Here are a few suggestions that have worked for me: 1) If the JSP pages have a lot of plain-text, move the plain text to a persistent store - for example an XML file or database. 2) See if there's any code in the application layer that could be optimized --- JDBC code (normally using Connection Pooling and Prepared Statements, batch updates/inserts). 3) If the result set returned from the persistence layer is too large try paging it into smaller chunks. After carefully making some of the above changes to my JSPs (especially moving out the plain text to a persistent store), my JSP page load within 1 second in the development environment on *first access*. I can compile a vast amount of Java code in 2 seconds. It is difficult to imagine what could be happening within Jasper to be that slow. I thought you meant the Jasper *pre-compiler* , and not the normal run-time compiler. I have been using the .tag facility to define custom tags fairly heavily. The pages are template driven, so that my top level JSPs contain little or no actual HTML. But there is not that much template code -- an XML parser should be able to read the lot in a few tens of milliseconds. I store all plain text in an XML file and I use XSLT to transform the XML structure into an HTML file. Then I call the transformation from a JSP page with JSTL's x:transform tag. This causes the page to load very quickly. Most of the HTML is dynamically generated by the XSLT. Also, I store chunks of plain text with HTML formatting in an XML file and transform it with XSLT to make the page load faster. I suspect that there is something very specific that is causing the very bad performance. Have not started profiling. I'd call this a bug. Is the HTML being generated dynamically? or is there a lot of static HTML and plain text? Also, it would help to optimize the database layer and app layer code. Any ideas most welcome. [Pre-compiling the JSPs would not help -- it would make things worse. At least now I only need to wait for the recompile of the JSPs that I actually want to test in a run. Pre-compiling would require me to wait for all the JSPs to recompile -- many minutes. (One needs to blast the Jasper work area regularly otherwise changes to .tag files do not get reflected in .jsps)] Yeah, I agree - pre-compiling is not meant to be used during application development anyway. Others are of course welcome to make their suggestions :-) -Rashmi - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jasper compiler very slow
Hello All, The compile time for my .jsp pages is extremely slow -- like 10 seconds on a modern PC to the first time any page is run. Painful during development. I can compile a vast amount of Java code in 2 seconds. It is difficult to imagine what could be happening within Jasper to be that slow. I have been using the .tag facility to define custom tags fairly heavily. The pages are template driven, so that my top level JSPs contain little or no actual HTML. But there is not that much template code -- an XML parser should be able to read the lot in a few tens of milliseconds. I suspect that there is something very specific that is causing the very bad performance. Have not started profiling. I'd call this a bug. Any ideas most welcome. [Pre-compiling the JSPs would not help -- it would make things worse. At least now I only need to wait for the recompile of the JSPs that I actually want to test in a run. Pre-compiling would require me to wait for all the JSPs to recompile -- many minutes. (One needs to blast the Jasper work area regularly otherwise changes to .tag files do not get reflected in .jsps)] Anthony [[My general comment would be for web development use Servlets, not JSPs. With a few well thought out templates you don't write much HTML anyway, and using servlets ends the impedance mismatch, as well as much of the pain... But too late for me now.]] -- Dr Anthony Berglas Ph. +61 7 3227 4410 (Mob. +61 42 783 0248) [EMAIL PROTECTED]; [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Basic Auth without web.xml security-constraint not working
Thanks for your replies, I think that the matter is settled. The underlying issue is that when Role R is required for Page P then *TWO* things need to happen depending on whether the user is in role R. These are 1. Allow or block access to page P. 2. Grey out or not grey out the menu item for page P. Right, I understand. The fact is that Tomcat will not perform authorization without also performing authentication. That is the crux of the matter. IMHO it is a bug, whether in the implementation or the spec I don't know or really care. The APIs take a very simplistic view of the world, and it just does not work for me at least. Pity, as not much more is needed. I could indeed scan web.xml given the inadequate API (rolesRequiredForUrl(), rolesForUser() etc.). (Scanning is possible but ugly -- needs duplication of URL pattern processing). But I prefer not to scan web.xml because I have other information about each form, and it would be nice to put the source of truth for the security info in the same place. But thanks for all the help. I have some Tomcat hacks that work for the time being. Later I will look for a fuller framework, either mine or someone else's, that is not J2EE based. If you really want to hack around with authentication and authorization, check out securityfilter (http://securityfilter.sourrceforge.net). The code is portable across servlet containers, and especially across different versions of the same container ;) Looks interesting. (Link is actually http://securityfilter.sourceforge.net, your link was to a spam site.) Anthony - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Basic Auth without web.xml security-constraint not working
Tomcat seems to only check the Authorization: headers if there is some security-constraint explicitly declared in web.xml. However, it appears that the optimization has been incorrectly implemented because it does not then recheck the header if request.isUserInRole(...) etc. are called. So users cannot log into a system that uses request.isUserInRole(...). More specifically, my simple application tests request.isUserInRole(...) and request.getRemoteUser(). If the user lacks permissions the application sends a 401, and the user is prompted for a name/password which is sent back as a Authorization: Basic dGltOlBhc3N3b3JkMQ== So far so good. But Tomcat then ignores the Authorization: header which is correctly sent by the browser. The web.xml has login-config auth-methodBASIC/auth-method realm-nameAgile UI: tim/Password1/realm-name /login-config in it. There is no security-constraint clause in the web.xml because I do not want to declare them there. (They are instead declared internally as part of a menuing system, which calls request.isUserInRole().) A hack to make Tomcat look at the Authorization: header is to add the following to web.xml security-constraint web-resource-collection web-resource-namedbtest/web-resource-name url-pattern/dbtest/*/url-pattern /web-resource-collection auth-constraint role-namedummyrole-name /auth-constraint /security-constraint In which case it works if one accepts the unwanted dummy query. Is it possible to tell Tomcat to always check the Authorization:? Alternatively, is it possible to grant the dummy role to anonymous users? Do anonymous users have any role that could be added to a dummy security-constraint? Is it possible for me to determine which users have which roles in my application so that I can check the header myself? Ie. get at the tomcat-users.xml style info, in a (fairly) web server independent manner? Or going the other way, is it possible for webapp to easily find out what roles are required for a given .jsp to run? (We want to grey out menu items that a user has no access to.) My general feeling is that attempting to use Java Servlet security is just wrong. One should simply do it oneself. Anthony -- Dr Anthony Berglas Ph. +61 7 3227 4410 (Mob. +61 42 783 0248) [EMAIL PROTECTED]; [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
