Re: Asking Again: 5.5.12 Broke my 5.5.9 Config
On 9/30/05, Bob Bronson [EMAIL PROTECTED] wrote: Hi all, I asked this question a couple days ago but received no helpful responses. I thought I'd try one more time. If anyone has had experience with this, please let me know. Thanks... I've just tried to upgrade from TC v5.5.9 to v5.5.12 and it seems my (very simple) configuration is now broken. The following configuration works beautifully under 5.5.9 -- no exceptions, no warnings, just utter perfection. Here's a description of my configuration (BTW, CATALINA_HOME and JAvA_HOME are fine, I'm sure they're not causing the problem). I have CATALINA_BASE set like this: C:\Projects\Configs\ Within this Configs directory I have two sub-directories: conf and Engine_01 like this: C:\Projects\Configs\ | +-conf\ | | | +-server.xml | +-web.xml | +-Engine01\ | | | +-localhost\ | | | | | +-ROOT.xml Within the conf directory I have my server.xml and the default web.xml files. Here is the server.xml contents: Server port=10035 shutdown=SHUTDOWN debug=0 Service name=Catalina Connector port=80 / Engine name=ENGINE_01 defaultHost=localhost Host name=localhost appBase=..\Sites\Test 1/ /Engine /Service /Server Notice I have named the engine, Engine_01. As you can see, in the Engine_01 directory I have a subdirectory, localhost, which contains a context fragment file named, ROOT.xml. Here is the contents of ROOT.xml: Context path= docBase=/ In my server.xml you'll notice I have my appBase property set to ..\Sites\Test 1. Here is the Sites directory structure: C:\Projects\Sites\ | +-Test 1\ | +-index.html +-WEB-INF\ | +-web.xml +-classes\ +-root\ It's all quite simple, I think. When I run under v5.5.9, this configuration works perfectly, as I said. Using the EXACT SAME configuration, running under v5.5.12, I see this WARNING and EXCEPTION when I start TC: WARNING: A docBase C:\Projects\Sites\Test 1\. inside the host appBase has been specified, and will be ignored Sep 26, 2005 8:37:22 PM org.apache.catalina.core.StandardContext resourcesStart SEVERE: Error starting static Resources java.lang.IllegalArgumentException: Document base C:\Projects\Configs\..\Sites\Test 1\ROOT does not exist or is not a readable directory at org.apache.naming.resources.FileDirContext.setDocBase(FileDirContext.java:140) at org.apache.catalina.core.StandardContext.resourcesStart(StandardContext.java:3777) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3948) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524) at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:603) at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:535) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:470) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1118) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:310) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1020) at org.apache.catalina.core.StandardHost.start(StandardHost.java:718) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1012) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442) at org.apache.catalina.core.StandardService.start(StandardService.java:450) at org.apache.catalina.core.StandardServer.start(StandardServer.java:680) at org.apache.catalina.startup.Catalina.start(Catalina.java:536) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:275) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413) Sep 26, 2005 8:37:22 PM org.apache.catalina.core.StandardContext start SEVERE: Error in resourceStart() Sep 26, 2005 8:37:22 PM org.apache.catalina.core.StandardContext start SEVERE: Error getConfigured Sep 26, 2005 8:37:22 PM org.apache.catalina.core.StandardContext start SEVERE: Context [] startup failed due to previous errors Sep 26, 2005 8:37:22 PM org.apache.catalina.core.StandardContext stop INFO:
Re: Asking Again: 5.5.12 Broke my 5.5.9 Config
On 9/30/05, Trond Hersløv [EMAIL PROTECTED] wrote: Hi I'm also running TC 5.5.9 and planning on installing 5.5.12. Twice I have read through the complete Changelog, from 5.5.10 to 5.5.12. I find nothing saying this attribute is now ignored. (Remy has appended his comments at the bottom of this email). Is there other things that may have an impact at my current applications - how do I know? Q: Have I just overlooked it twice or am I looking for this kind of information at the wrong place? The path attribute was already ignored in 5.5.9. docBase is now also ignored if inside the Host's appBase. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat/JVM hangs in session.getAttribute / HashMap.get()
On 9/7/05, GB Developer [EMAIL PROTECTED] wrote: coming late to the party with: http://blogs.opensymphony.com/plightbo/archives/000175.html I had read your blog when you originally posted it, and thought it was the most interesting blog I had read in months. IMO, given the average size of the array in a typical hashmap (very small), they should have added a robstness check (typically, e != e.next). -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Automatic deploy of updated war deletes the context file
On 8/26/05, Paul Austin [EMAIL PROTECTED] wrote: The test case I am using is running on Tomcat 5.5.9. 1. The web application is deployed as a the app.war file, with no context.xml file to the wars/host directory 2. The Host configuration is as follows. Host debug=99 name=host unpackWARs=false deployXML=false Logger className=org.apache.catalina.logger.FileLogger prefix=host timestamp=false / /Host 3. In conf/Catalina/host/app.xml ?xml version='1.0' encoding='utf-8'? Context debug=9 docBase=wars/host/app.war path=/app reloadable=true workDir=work/Catalina/host/app ResourceLink global=jdbc/appDs name=jdbc/appDs type=javax.sql.DataSource/ /Context When I copy app.war into wars/host to repeploy using the automatic deployer I check the conf/Catalina/host/ and http://host/manager/list and the app.xml and the /app context are deleted. Yes, this is normal. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Client Deployer 5.5.11 NullPointerException
On 8/25/05, Allistair Crossley [EMAIL PROTECTED] wrote: Hi, I've decided to try out the Deployer tool for the first time to see if it makes like a little easier for deployments to our test servers. I've used the 5.5.11 Alpha Deployer as I noted some threads indicating a problem with 5.5.9's version. I've come across the following when running it pretty much out of box. I setup a deployer.properties file. Am I missing some kind of classpath or could this be caused by a file in my web application? No Java compiler available. With the deployer package, you're supposed to be using Ant+javac (given that Ant wants JAVA_HOME and likes a JDK). If not, add the JDT JAR that is in common/lib. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Client Deployer 5.5.11 NullPointerException
On 8/25/05, Allistair Crossley [EMAIL PROTECTED] wrote: Hi, No I don't think that's it, both ant and javac work on my command line. I do use Ant for build, I'm just trying deployer for the first time. JAVA_HOME, ANT_HOME are also both defined. Ant is also the latest version 1.6.5 Great. Then go look in the code and try to explain the exception by something other than No Java compiler available. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Client Deployer 5.5.11 NullPointerException
On 8/25/05, Allistair Crossley [EMAIL PROTECTED] wrote: Hi, I'd really love to I assure you, but I really don't a) have years and years of architecting Tomcat development to trace through how Jasper2 works and b) the time whilst I am sat here working for a corporation trying to get Tomcat working for the business For what it's worth (which is nothing I realise) I do realise that jspCompiler.init(this, jsw) is throwing the exception because the jspCompiler returned from the compiler = (Compiler) Class.forName(className).newInstance(); is null due to what must be a CNFE (looks like logging is needed there). I also see that this was why you asked me to copy the JDT compiler jar from common/lib into the deployer/lib. However, I did just that, and this still does not solve the resolution of the compiler class. Can I clarify that wnated me to copy common/lib/jasper-compiler-jdt.jar into deployer/lib? Of course. No compiler is found, so you should add one. Finally, is it documented anywhere that deployer won't work out of the box? If not, I'd be happy to make a comment on the Deployer doc page. The deployer does work out of the box, assuming you have a well configured Ant which is able to use a Java compiler. So you did something funny :) -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Client Deployer 5.5.11 NullPointerException
On 8/25/05, Allistair Crossley [EMAIL PROTECTED] wrote: Hi, Hm :( Are you able to clarify what you mean by a well configured Ant which is able to use a Java compiler. Perhaps this is where the problem lies? My Ant setup is such that I have ANT_HOME and JAVA_HOME env vars set. I have ANT_HOME/bin and JAVA_HOME/bin on the PATH. The ant and javac commands work on the command line. I can run the Tomcat build script and many other build scripts with ant to build software (including Tomcat). This for me looks like at least a configured Ant. Am I missing some link that you know of? In terms of installing the deployer, I literally did the following: 1. Downloaded 5.5.11-alpha Deployer 2. Unzipped to c:\jakarta-tomcat-5.5.11-deployer 3. Created deployer.properties, setting the 4 or 5 properties required for the web application 4. Moved to c:\jakarta-tomcat-5.5.11-deployer 5. Executed ant compile 6. File copy works etc... but then I get the exception with the jasper2 task. Then I got your suggestion 7. Copy jdt compiler jar frmo common/lib to c:\jakarta-tomcat-5.5.11-deployer\lib 8. Executed ant compile Same error occurs however. I don't _think_ I have done anything funny but you never know ;) To start with something, I use a known-to-be-working Ant 1.6.2 release. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Client Deployer 5.5.11 NullPointerException
On 8/25/05, Remy Maucherat [EMAIL PROTECTED] wrote: To start with something, I use a known-to-be-working Ant 1.6.2 release. I just installed and tested with 1.6.5, and it works too. I just added some debug logging too for the classloading exceptions. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Client Deployer 5.5.11 NullPointerException
On 8/25/05, Markus Schönhaber [EMAIL PROTECTED] wrote: Am Donnerstag, 25. August 2005 17:57 schrieb Allistair Crossley: Thanks, that's good to know, it must be something to do with my environment. Are you saying then that you did not have to copy any JDT jars into your deployer? No, I didn't have to copy any jars since ant uses sun's javac from tools.jar in JAVA_HOME by default. If it doesn't for you, then there's something wrong. Yes, if you set JAVA_HOME correctly, then Ant should find javac, and you don't need to add the other compiler. How have you setup Ant? In any specific manner? I extracted the zip, set ANT_HOME accordingly and added %ANT_HOME%\bin to PATH. I'm on Windows too. Maybe the space in the path for JAVA_HOME is causing problems (mine is c:\java\jdk1.5.0), but overall the Ant script is hack free, and there's no .bat to introduce bad behavior (except the Ant one, but hopefully it is properly done). -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Apache Tomcat v5.5.11-alpha Released
The Apache Tomcat team is proud to announce the immediate availability of Apache Tomcat 5.5.11-alpha, which includes bugfixes over Apache Tomcat 5.5.10-alpha. The Release notes are available at http://jakarta.apache.org/tomcat/tomcat-5.5-doc/RELEASE-NOTES Please refer to the change log for the list of changes: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/changelog.html Downloads: Binaries: http://jakarta.apache.org/site/binindex.cgi#tomcat-5.5 Sources: http://jakarta.apache.org/site/sourceindex.cgi#tomcat-5.5 The Apache Tomcat Team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: logging tomcat 5.5
On 8/23/05, Alain Gaeremynck [EMAIL PROTECTED] wrote: I read the doc and found out that in tomcat 5.5 we are suppose to use log 4 j to handle getServletContext.log. However i rather liked the old ways Is it stil supported? if i put this in my context Logger className=org.apache.catalina.logger.FileLogger prefix=servlet. suffix=.log timestamp=true / will it still work? No, it's not supported anymore. You can look at your logging options here: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/logging.html -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Deploying ROOT.war indicates missing application web.xml
On 8/22/05, Allistair Crossley [EMAIL PROTECTED] wrote:
Hi Everyone,
Just been deploying ROOT.war into webapps and it's failing to explode. The
logs indicate;
INFO: Deploying web application archive ROOT.war
22-Aug-2005 09:46:44 org.apache.catalina.startup.ContextConfig
applicationWebConfig
INFO: Missing application web.xml, using defaults only
^^^
Yet, if I rename ROOT.war to ROOT.zip and open it in WinZip, the web.xml has
been correctly packed by the Ant WAR task. Indeed if I unzip the WAR into
webapps manually, the web application works fine and is packaged correctly.
I use an Ant WAR task
war
destFile=${dist.dir}/${app.name}.war
webxml=${webroot.dir}/WEB-INF/web.xml
duplicate=preserve
classes dir=${classes.dir} /
lib dir=${webroot.dir}/WEB-INF/lib /
webinf dir=${webroot.dir}/WEB-INF /
metainf dir=${webroot.dir}/META-INF /
fileset dir=${webroot.dir}
include name=includes/** /
include name=resources/** /
include name=views/** /
/fileset
/war
Any ideas why Tomcat is exhibiting this behaviour?
I just tried it by zipping and removing the ROOT folder, replacing it
with ROOT.war. It gets expanded and deployed correctly.
--
x
Rémy Maucherat
Developer Consultant
JBoss Group (Europe) SàRL
x
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Deploying ROOT.war indicates missing application web.xml
On 8/22/05, Allistair Crossley [EMAIL PROTECTED] wrote: Hi, Just to reconfirm, and also to take into account what you did in your test 0. Check server.xml for unpackWARs=true autoDeploy=true 1. I use Ant's war task to correctly war the web application package. I used 7zip. 2. I clear Tomcat's webapps folder and restart for good measure. I only deleted the ROOT folder. 3. I copy the war into webapps 4. Tomcat reports INFO: Deploying web application archive ROOT.war 22-Aug-2005 11:14:02 org.apache.catalina.startup.ContextConfig applicationWebConfig INFO: Missing application web.xml, using defaults only StandardEngine[Catalina].StandardHost[localhost].StandardContext[] 5. I rename ROOT.war to ROOT.zip and open in WinZip to check file structure, in particular web.xml and to ensure that ROOT is not part of packaged paths. 6. I unzip ROOT.zip to webapps\ROOT 7. I make a request to the web application which succeeds including filters defined in the web.xml 8. Stop Tomcat 9. With WinZip, rezip the tested working ROOT folder contents 10. Delete webapps\ROOT 11. Rename ROOT.zip to ROOT.war 12. Cut ROOT.war onto Desktop. 13. Start Tomcat 14. Cut ROOT.war into webapps 15. Get same error. INFO: Deploying web application archive ROOT.war 22-Aug-2005 11:14:02 org.apache.catalina.startup.ContextConfig applicationWebConfig INFO: Missing application web.xml, using defaults only StandardEngine[Catalina].StandardHost[localhost].StandardContext[] Could the fact that my ROOT.war is 18MB have anything to do with Tomcat's ability to examine for the web.xml??? (wild guess) I know you like funny theories, but how about trying with the default ROOT webapp then ? -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JspC compile exception in tomcat-deployer 5.5.10
On 8/16/05, Bernhard Slominski [EMAIL PROTECTED] wrote: Hi Richard, the problem is that your classpath for the jasper path is not correct. So this Null Pointer exception actually means that some class was not found. Note that you need all the tomcat libraries in your jaser classpath, as well as your libs as well. I post you my script, which is working Ok (on Tomcat 5.5.7). Yes, the problem is indeed that the task definition had been mistakingly removed in this build from the catalina.tasks properties file. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat 5.5, jdk1.5 on user mode debian stable hangs after a few days
On 8/2/05, MDK [EMAIL PROTECTED] wrote: no, the odd thing is, it wasnt even being used (and its a very simple application, of course, thats a relative term) i installed the app, tested it once and logged out. I came back to it a few days later and the whole thing is hanging. If you can recommed any tools i can use to detect what is happening that would be much appreciated the app itself uses spring, openamf (an open source flash remoting connector) with some jdbc (mysql) so i guess that any one of these (and my code) could be the culprit. I'll look into each of these individually and see if they could be causing the problem. When something like Tomcat is hung, the first thing you should do is get a thread dump, which may give very useful information. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.10: APR-SSL generates wrong 302 response
On 7/25/05, Markus Schönhaber [EMAIL PROTECTED] wrote:
Hello!
I've configured Tomcat 5.5.10 to use APR. The HTTP-Connector listens on port
80, the HTTPS-Connector listens on port 443. A request for
https://www/tomcat-docs
generates the following response:
GET /tomcat-docs HTTP/1.1
Host: www
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.8b4) Gecko/20050721
Firefox/1.0+
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
HTTP/1.x 302 Moved Temporarily
Server: Apache-Coyote/1.1
Location: https://www:80/tomcat-docs/
Transfer-Encoding: chunked
Date: Mon, 25 Jul 2005 11:57:39 GMT
Obviously this doesn't work since since the redirection response tells the
browser to connect to the HTTP port using HTTPS.
This problem does *not* occur if:
- The request is for https://www/tomcat-docs/ (no surprise since no redirect
response is generated in this case).
- The HTTPS-Connector is configured to listen on port 8443 (or propably any
other non-standard HTTPS-port - but I haven't tried).
- APR isn't used at all.
There's indeed a cut paste error (the default ports for HTTP and
HTTPS are inverted), so you need to add an extra '!':
Index: Http11AprProcessor.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11AprProcessor.java,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- Http11AprProcessor.java 13 Jul 2005 13:03:51 - 1.25
+++ Http11AprProcessor.java 25 Jul 2005 15:32:48 - 1.26
@@ -1422,8 +1422,8 @@
}
if (colonPos 0) {
-if (ssl) {
-// 80 - Default HTTTP port
+if (!ssl) {
+// 80 - Default HTTP port
request.setServerPort(80);
} else {
// 443 - Default HTTPS port
Using proxyPort=443 should be a decent workaround.
--
x
Rémy Maucherat
Developer Consultant
JBoss Group (Europe) SàRL
x
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Servlet Concurrency Issues
On 6/8/05, Peter Crowther [EMAIL PROTECTED] wrote: Note that SingleThreadModel isn't supported in more recent versions of Tomcat. This may or may not worry you depending on whether you want to move to a more recent version :-). I've posted already about that: if you don't know about something, please don't make guesses with the tone of someone who knows his stuff, since you'll just end up confusing people. Your statement is completely wrong, STM is fully supported in Tomcat 5.5, with instance pooling for good performance. It's usually much faster than having lots of sync in your servlet, that is. I actually like the feature, personally. The only reason it got removed is because it gave users the impression that no additional syncing was ever needed (which is not the case, as session modification may still be unsafe). -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Servlet Concurrency Issues
On 6/8/05, Peter Crowther [EMAIL PROTECTED] wrote: From: Remy Maucherat [mailto:[EMAIL PROTECTED] Your statement is completely wrong, STM is fully supported in Tomcat 5.5, with instance pooling for good performance. Sorry, Remy - I should have checked rather than relying on memory. No problem. STM is deprecated in the specification, but support is mandatory (of course, if the container doesn't do pooling, performance will be really bad). I hope it doesn't get removed, since it is sometimes useful (maybe it could be reinstated with a different name). -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: genStrAsCharArray not available in JspC and performance increase?
On 5/29/05, Kevin Burton [EMAIL PROTECTED] wrote: So on: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/jasper-howto.html#Production%20Configuration It recommends to use genStrAsCharArray when in production. This can be set in web.xml but not when using JspC from the command line. trimSpaces is there... but not genStrAsCharArray. Its in the source but it just doesn't have a command line option. 1... does it make sense for me to just recompile my 5.5.4 production server with this enabled? Whats the performance gain? 2. Can we make this an option in JspC moving forward? I don't see why it can't be a command line switch. I verified that this is still the case in 5.5.9 btw. The command line version of jspc has been kind of deprecated for a while now; we recommend using Ant. Otherwise, adding code to set the flag is relatively simple. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat optimization... saving internal strings with character encoding at compile time.
On 5/29/05, Kevin Burton [EMAIL PROTECTED] wrote: Another area that I'm noticing that Tomcat is spending a LOT of time in is with character encoding. Its not a ton of time but its really showing up as one of the top 20 areas of our webapp. Internally its either storing text as a java.lang.String or with genStrAsCharArray ... a char array Most people are probably using a fixed character encoding. For example we use UTF8. I doubt they're changing charset on the fly. Its a waste of CPU to continually encode these strings. This isn't just theoretical as I'm seeing our webapp do this internally via JProfiler. Why not have strings fixed to a character coding at runtime? While this would yield inflexibility it would increase performance. This could be a new feature called genStrAsEncodedByteArray... which would just store the string as a byte[] and output it directly. The only thing that would need to be encoded in this setup would be dynamic strings from EL. It would also save more memory for English text since strings no longer are stored in 32bit but just UTF8 encoded 8 bit values. It would slow down compile time though because Jasper would now need to call toByteArray() on all your strings. Thoughts? This is obvious. This is not an implementable optimization idea, as you cannot use both a writer and an out stream in a servlet. If this was doable, then obviously constant strings would be cached as byte arrays. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The amazingly slow performance of JSP (profiler results)
On 5/28/05, Kevin Burton [EMAIL PROTECTED] wrote:
I've been tuning our application trying to get the maximum performance
out if the system as possible.
I've been throwing the system at jprofiler and allowing it to tell me
where to optimized.
In short Tomcat is slower than our DB, filesystem,. network and all
other systems by about 4x.
I've been able to shave some page load time off by some but not enough.
The problem I'm starting to see is that we just have a large number of
c:set and c:if constructs (and so forth) within loops. These loops then
get executed 5 times and next thing you know it you have 50k taglib calls.
The problem comes when you look at the source:
Let's say you start with:
c:set var=foo value=bar/
This nice little elegant piece of code gets expanded to:
private boolean _jspx_meth_c_set_0(PageContext _jspx_page_context)
throws Throwable {
PageContext pageContext = _jspx_page_context;
JspWriter out = _jspx_page_context.getOut();
// c:set
org.apache.taglibs.standard.tag.rt.core.SetTag _jspx_th_c_set_0 =
(org.apache.taglibs.standard.tag.rt.core.SetTag)
_jspx_tagPool_c_set_var_value_nobody.get(org.apache.taglibs.standard.tag.rt.core.SetTag.class);
_jspx_th_c_set_0.setPageContext(_jspx_page_context);
_jspx_th_c_set_0.setParent(null);
_jspx_th_c_set_0.setVar(foo);
_jspx_th_c_set_0.setValue(new String(bar));
int _jspx_eval_c_set_0 = _jspx_th_c_set_0.doStartTag();
if (_jspx_th_c_set_0.doEndTag() ==
javax.servlet.jsp.tagext.Tag.SKIP_PAGE)
return true;
_jspx_tagPool_c_set_var_value_nobody.reuse(_jspx_th_c_set_0);
return false;
}
Which explains why JSP alone is so amazingly slow!
I did a comparison of the page performance here and it was 15x slower than
just using Java. So the same set operation in Java was 15x faster.
... so in short ... does anyone have any way to speed this up?
The other thing I noticed is that EL is evaluated at runtime (which has to be
parsed) and sometimes uses reflections. Can anyone shed any more light on
this and hopefully provide some performance optimization suggestions?
You already posted on this subject. Can you provide any hard data that
a tag invocation is actually slow this time ? Guesses don't really do
it, and profilers are often not very accurate. I'm asking because
while the code is indeed quite verbose, it does not make it slow (all
operations in the code that is cut pasted are very cheap). The JIT
is supposed to take care of this kind of code very well.
For production configuration for Jasper, see:
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/jasper-howto.html#Production%20Configuration
We have a facility in Jasper called tag plugins, which allows
replacing a tag invocation (which cannot be any simpler and still
comply to the specification) by equivalent Java code (so your c:if is
traslated to a regular Java if). Support for JSTL is very
incomplete, but you can use that to optimize the few tags that you
think need it. Kin-Man asserted that overall the performance
improvement was small - 10% at most. See package
org.apache.jasper.tagplugins.jstl (which has already an impl for if
which could help you out). Feel free to sumit more JSTL tag plugins if
you find it works well.
EL will have to remain interpreted at runtime, but has a cache. I have
not evaluated this performance area yet, however. Other xSP
technologies interpret a lot of things at runtime, and most don't even
rely on compilation (which will likely tend to make them a little
slower, I assume), and the overhead is usually not in the xSP engine,
so I don't see why it would be a major issue here (as long as the impl
is not too stupid, of course).
--
x
Rémy Maucherat
Developer Consultant
JBoss Group (Europe) SàRL
x
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: The amazingly slow performance of JSP (profiler results)
On 5/28/05, Peter Lin [EMAIL PROTECTED] wrote: as you see already, using JSTL means a single line of code gets converted to several lines of JSTL api calls. once you look at how many classes are involved in executing JSTL, it's pretty clear it's using much more memory and causing more GC. The performance you see is the result of JSTL using more memory. It will obviously use more CPU and make more API calls. However, it does not allocate any objects, but instead will reuse per page objects (which is very fast). So overall, it sounds weird to me that the bottleneck would be on tag invocation. In the end, it's hard to beat a Java if with a generic high level construct ;) I don't understand how anyone could be surprised by that. Back in 2002, I wrote several pages using JSP + java and JSP + JSTL to measure the actual cost of from a performance perspective. The performance difference isn't noticeable if a page has less than 50 tags. With 200+ tags, the performance difference does range from 2-5x slower for JSTL. It's worse when you use XML with JSTL. It's also one of the reasons I like to use JSTL + XML to benchmark. It really gives the VM a workout. have you tried running JRockit 5? I did some tests recently and JRockit's memory management might give you a 2x improvement in performance. That's assuming you can use jdk5 Right, the code for invoking tags seems to be a good candidate to be optimized by a competent JIT. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reload on Tomcat 5.5
On 5/22/05, Robert Parsons [EMAIL PROTECTED] wrote: Hi, Thanks for the quick reply. I have the latest stable version i think (5.5.9). I have tried this on older version too in the past and just given up and gone back to 5.0. I just decided this time to see if it was a bug or me missing somthing. Basically i'm just trying to get classes to reload. Say i make a change in what a particular servlet prints out to the browser, i want to see that change. Nothing complex. At the moment i've just gone back to 5.0 and all is working ok. From time to time i'll download 5.5 and see if it works :p If you're not actually looking for help, and were just trying to confuse people with your incorrect statements about an imaginary problem, then please do not bother posting. BTW, reloading works well, please do not claim otherwise without posting factual data. Doug's post is also wrong, as there are no such thing as cache/workfiles which would cause updating issues (the only relevant thing you could be referring to is the locking issues when redeploying on Windows). -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reload on Tomcat 5.5
On 5/22/05, Robert Parsons [EMAIL PROTECTED] wrote: I don't imagine stuff, and I am not currently running tomcat under windows. I have used various versions of tomcat 5.0 and 5.5 on many different Operating systems (such as redhat, fedora core, ubuntu linux and windows xp) and many versions of java (quite a few different 1.4 and 1.5's). I have not claimed there is a problem with tomcat, i am asking for help as I do not know if I am doing somthing wrong. Yes, you are doing something wrong, as this works. All i can say is that after following tutorials and using very standard Ant scripts (or the the tomcat manager application) I can easily 'reload' servlet applications on Tomcat 5.0.x. On every installation of Tomcat 5.5.x i have found that 'reloading' applications (in the same way I have done with 5.0) does nothing. Changes to classes are not reflected in the output of the application. To get anything to update I have to undeploy and install it again. There is nothing much more I can tell you. I could give you source code or my ant script, but source code is fairly irellevant and the ant script i am using is straight out of the tomcat getting started tutorial. The only configuration changes I have made to tomcat was adding a user in the users.xml! More nonsensical statements. To start with, class reloading is not enabled by default *and* reloading does work fine. As I said, if you think otherwise, please post factual data (test cases, whatever) proving otherwise. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reload on Tomcat 5.5
On 5/22/05, Robert Parsons [EMAIL PROTECTED] wrote: Hi, Thanks for the reply. Well to be more specific then I will give you an example of what I have tried as a test. I write a basic servlet that simply prints a line of text to the screen. If i compile it and deploy it, all is good. If I then make a modification to that that string in the source file, recompile then RELOAD (using ant), the servlet still outputs the ORIGINAL string (before the modification). The same thing happens If i recompile then press 'reload' in the tomcat manager application instead of using ant. I tested this, and it (of course) works fine. If i perform the steps above on the latest tomcat 5.0 (rather than 5.5), the NEW string would be printed out after the reload. Any ideas? Coz i'm stumped. Well, don't plan to upgrade ever, because the bug will obviously never be fixed. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reload on Tomcat 5.5
On 5/22/05, Parsons Technical Services [EMAIL PROTECTED] wrote: Robert, Now that Remy has tested it in his perfect world, this gives some direction to work in. It would appear that with a basic setup, which we can only assume since Remy assured you that it works, that there must be a OS issue. I wonder what Remy runs? If you decide to dig deeper, I would layout the code for the two versions and see where they differ. Then with this information you could submit a bug report with all the details. Hopefully it could be changed unless there was a compelling reason. I am so glad that Remy pointed out that I was wrong, but had no explanation for why you were having problems. Considering that I was only suggesting a direction to look in. But then again if you had been running Windows then I may have been right. Don't let the snotty attitude get to you. You encounter those type on the list from time to time. Please try to make sense next time. Writing inaccurate statements while appearing to know things will confuse people, and will be much worse than posting nothing. If you don't really know, then don't post funky theories as facts. Your main assertion is baseless 5.5 has a hard time letting go of the cache/workfiles. Do you actually know what you are talking about ? I suppose not. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache vs Tomcat WRT Security
On 5/19/05, Mark [EMAIL PROTECTED] wrote: I was very interested in the discussion concerning Apache vs Tomcat WRT Performance. While I cannot argue with the performance numbers, I do like putting Apache in front of Tomcat for 2 reasons that I have found so far. 1. SSL. If I am going to be serving pages whether they be dynamic or static, I think Apache handles the SSL communications and key storage better. In tests that I have run, the crypto that needs to be done to support SSL is faster in C than Java. Also, Tomcat stores any key information in a flat file, where Apache will prompt for a password on startup. Now some administrators might like this better, because Tomcat will then start automatically at boot time, I would not want any password of mine sitting in the clear in a test file. The next Tomcat 5.5 release will include APR based connectors, where SSL will (predictably) use OpenSSL. 2. If you are hosting your site using port 80 on Unix boxes this means running Tomcat as root. I can think of very few reasons why Tomcat needs to be run as root. Apache has the ability to 'downgrade' user privileges once Apache is started. I think you should have googled for that. You can use either kernel level redirection (iptables, for example), or use jsvc. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What are those No such list! s and Illegal IMail List Server Command! ?
On 5/17/05, Will Hartung [EMAIL PROTECTED] wrote: I'm confident the Powers That Be are working diligently to fix the problem, whatever the problem may be, so I'm not taking any dramatic measures. I don't know about that (at least in the immediate future). Yoav is away this week, and the ASF email servers are having major problems. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: strange autodeploy behaviour on 5.5.9
On 5/13/05, teknokrat [EMAIL PROTECTED] wrote: I don't understand this. I am packing my MyApp.xml context with the war ( in the root ). Is this wrong? Whats are the surefire instructions to have your war hot deploy? The bug linked is not related to your situation in any way (it should be obvious reading it). You seem to be experiencing file locking problems, so read the FAQ on Windows file locking. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Autodeploy not working on Tomcat 5.5.9
On 5/10/05, Marquez, Omar [EMAIL PROTECTED] wrote: Hi Luntz, Thanks for answering. this is from my server.xml Host appBase=webapps autodeploy=true unpackWARs=true name=localhost Context path=/webapp reloadable=true WatchedResource/usr/local/tomcat/conf/context.xml/WatchedResource WatchedResourceWEB-INF/web.xml/WatchedResource /Context Context path=/OES2 reloadable=true WatchedResource/usr/local/tomcat/conf/context.xml/WatchedResource WatchedResourceWEB-INF/web.xml/WatchedResource /Context /Host Contexts hardcoded in server.xml are not autodeployed or manageable (except to some extent through the admin webapp). They are hardcoded and always deployed on startup, and that's it. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP monitoring tool
On 5/9/05, Gabriel Belingueres [EMAIL PROTECTED] wrote: Hi, Are there any DBCP monitoring tool that allow me to monitor how many open connections (and other stats) does DBCP holding? With Tomcat 5.5.4+, DBCP datasources should have an associated MBean, with all the useful statistics. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New logs showing up under Tomcat 5.5.9
On 4/29/05, Ryan Daly [EMAIL PROTECTED] wrote: All: Just upgraded to 5.5.9 yesterday. Can anyone quickly tell me what the extra log files are in the logs directory? I'm getting: admin.2005-04-28.log, catalina.2005-04-28.log, host- manager.2005-04-28.log, localhost.2005-04-28.log, and manager.2005-04-28.log They're all 0 bytes. Can I stop them from showing up? These files shoudn't be empty. You can read about logging configuration in the docs: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/logging.html -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC v5.5.9 Won't Server *.htm Files
On 4/27/05, Bob Bronson [EMAIL PROTECTED] wrote: Hello all, I'm sure this must be a configuration issue. I am running TC 5.5.9 as a stand-alone server (not w/Apache). The problem I'm seeing is that when I point my browser to an index.htm file, Tomcat gives me a 404, telling me it cannot find index.jsp. Please notice I said, index.htm and not index.html. Here's a peek at the HTTP headers as captured by Firefox. I'm only showing the relevant headers. GET /fred/bob/index.htm HTTP/1.1 Host: xxx.test1.com HTTP/1.x 404 /fred/bob/index.jsp Server: Apache-Coyote/1.1 Is that crazy? I'm asking for index.htm and it *DOES* exist. If I rename it to index.html everything works fine. I know what you're thinking -- probably I do not have the welcome files set right in my default web.xml. Well, here it is: welcome-file-list welcome-fileindex.html/welcome-file welcome-fileindex.htm/welcome-file welcome-fileindex.jsp/welcome-file /welcome-file-list And I am *NOT* overriding these in the web app's web.xml. Can someone running TC 5.5.9 as a standalone server please see if you can serve an index.htm file? As it did sound funky enough to be verifiable, I tried it. Renamed index.html - index.htm in servlet-examples, but it worked fine (/servlet-examples/ returns the file, as does /servlet-examples/index.htm, but /servlet-examples/index.html returns a 404). -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.x returns wrong value for request.getRequestURI()
On 4/15/05, Yaakov Chaikin [EMAIL PROTECTED] wrote: Hi, Using Tomcat 5.5.7 (tried Tomcat 5.5.9 with the same results) on Windows XP. When forwarding to a JSP page that is located in /WEB-INF/jsp/success.jsp and calling: %= request.getRequestURI() % inside the success.jsp page, the result I get is: /WEB-INF/jsp/success.jsp I am pretty sure that according to the API, this is the wrong result. It should have returned the URI of the **request**, not the path to the resource. Is this a known bug or there is some weird Tomcat setting that I need to change. I ran this on Tomcat without changing any of the original settings. BTW, the same is true of request.getRequestURL(). It returns (peculiar enough): http://localhost:8080/WEB-INF/jsp/success.jsp This is not a bug, as it's intentional, and hasn't been shown to contrdict the spec. The spec seems to hint that this should use the path elements (but is very vague). I didn't quite agree with the change, but didn't actually care about the issue, so you can try asking for clarifications to Sun or on tomcat-dev. If you want to change that, hack the request wrapper code a little, it's very easy. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.x returns wrong value for request.getRequestURI()
On 4/15/05, Yaakov Chaikin [EMAIL PROTECTED] wrote: I checked out the spec section 8.4.2 Forwarded Request Parameters. It does seem to me that it implies that the parameters is where one would get the original URI from. However, there are still 2 problems that I can see: 1) The API says: URL the client used to make the request 2) 8.4.2 says that these parameters are NOT to be set if you obtain the RequestDispatcher object using getNamedDispatcher() method. How would you get at the original URI/URL then (without custom coding)? This is not constructive argumentation. 1) Applies to the core request class behavior. Cool, it works. The RD has to wrap it using a request wrapper, so it does not apply. 2) How about trying things instead of making what-if theories ? (hint: it works fine) ;) -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.x returns wrong value for request.getRequestURI()
On 4/15/05, Yaakov Chaikin [EMAIL PROTECTED] wrote: 1) Applies to the core request class behavior. Cool, it works. The RD has to wrap it using a request wrapper, so it does not apply. So, what you are really saying is that the API should have pointed out that getRequestURL() does not work the same way every time. Then, I am not sure how anyone could have arrived at the conclusion that the words ... URL the **client** used to make the request... really means unless something else happens behind the scene and the returned value is no longer what the **client** used. That doesn't seem strange to you, taking only into account what has been said? I'm just pointing out you're not actually using the same class. The javadoc for the base class mentions the behavior of the non-wrapped base request class. After going in the request dispatcher and wrapping, this behavior is not the same. 2) How about trying things instead of making what-if theories ? (hint: it works fine) ;) I haven't tried this particular part. True. I HAVE tried everything else I mentioned however. Are you saying that how things really work ONCE AGAIN is not the way the servlet spec describes they should? Quote 8.4.2: If the forwarded servlet was obtained by using the getNamedDispatcher method, these attributes **must not be set.** Well, the path values are simply set to the original ones, and, indeed, there are no attributes. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JULI and logging
On 4/14/05, Jonathan Eric Miller [EMAIL PROTECTED] wrote: What I did was change my common/classes/logging.properties file to the following. With this setup, everything goes into catalina.out. Note, I found that if JULI is enabled, it appears to ignore the java.util.logging.config.file property if you passed it in as a system property. It does not ignore it, but virtually no logging will go to the root logger. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Way to specify SingleSignOn session timeout?
On 4/14/05, Jonathan Eric Miller [EMAIL PROTECTED] wrote: After looking at the code, it looks like the SSO session doesn't go away until all other sessions for the user have expired. So, as far as I can tell, the SSO session doesn't have it's own session timeout as far as I can tell. Indeed. OTOH, if one of the sessions is explicitely invalidated, the SSO will go away right away. I think that's the most appropriate behavior, but changing it is very easy using a little code hacking. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Tomcat 5.5.9 voted stable
On Apr 11, 2005 9:35 PM, Christoph Kutzinski [EMAIL PROTECTED] wrote: Yoav Shapira wrote: Please note that while all core features have been tested and voted stable, there is a known issue in this build related to the clustering module. The fix for this issue is available by itself at Bugzilla, and will be included in subsequent Tomcat releases. Again, this issue only impacts users of Tomcat's native clustering module. Where can I find information about this issue? I found nothing in the release notes. It's here: http://issues.apache.org/bugzilla/show_bug.cgi?id=34389 -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.x and Java 1.5
On Apr 7, 2005 11:15 AM, Steiner, Stephan [EMAIL PROTECTED] wrote: Hi I'm trying to compile a couple of jsp pages that use Java 1.5 syntax. I followed the Jasper how-to and replaced the jdt jar with the latest ant.jar (taken from the Ant 1.6.2 distribution). After a restart of Tomcat, Tomcat now uses the JDK compiler (I see different error message for my Java 1.5 code). However, the default is to write code compatible with JDK 1.4. So I added the following lines to my web.xml config file (in the jsp servlet section) and restarted Tomcat again: init-param param-namecompilerSourceVM/param param-value1.5/param /init-param init-param param-namecompilerTargetVM/param param-value1.5/param /init-param After a restart, trying to access any page yields a 404 error, with no entries in the logfiles. Setting the version number to 1.4 instead yields the same behavior. Removing those two init-params again and everything is back to normal, but I still can't use Java 1.5 features. Is there anything I'm missing to run Java 1.5 code on Tomcat 5.5.x? I updated JDT in Tomcat CVS to 3.1M6, as well as handling of those two properties (which may or may not fix Ant, as I didn't test it), so you can try building a new Jasper from CVS. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Threads / Tomcat Lite
On Apr 6, 2005 12:43 AM, Steffen Heil [EMAIL PROTECTED] wrote: Hi 1. Question I need to store some information which differs for each request. My problem: I need it at a place where I have no access to the request, the response or the session. Now, I can also do it using ThreadLocal variables, but these take time. I would prefer to use a custom Thread class for the Processors and to extend that by an aditional variable. I could then cast Thread.currentThread() to my own Thread class and use the variable. So, is it possible to specify, which class is used? Well, you should have looked at the thing returned by Thread.currentThread() first, I think. This would have answered all your questions. However, ThreadLocals are fast and efficient, so I recommend you use them. 2. Question Is it possible to use the HTTP connector of tomcat only? Everything I have is served by a single servlet. I do NOT need logging, filters, mappings (other than the single one), and so on. Every request goes all the way through tomcat's valves and filters. This takes a little time. A little time I'd like to save. Any way? Overhead added is negigible (really, I mean it), so I recommend you don't bother. Although you may not need some of the features, I think you are probably using IO. The Tomcat HTTP core (which is indeed fully independent, so you could use it as a HTTP server) basically only allows using byte arrays for IO, which is more restrictive obviously. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat taking 125 seconds to launch
On Apr 3, 2005 11:04 PM, Michael Mehrle [EMAIL PROTECTED] wrote: Hi Mark: Okay, the machine is a P4, 1GB RAM (512MB assigned to tomcat), and besides Tomcat 5.5.9, there's Apache running and mysql. Apache is not in use much. I have the apache logging set to WARN, so the slowdown is not due to excessive logging. The site is running an image gallery and there are probably around 100 jps for the gallery and image pages. I am not sure if adding jsps does affect the startup time. The configuration is a modified version of appfuse 1.5 (struts and hibernate) - so this should give you a good idea of how it is structured. FYI: on my development machine here at home Tomcat starts in 28 seconds - identical project and configuration. Any help would be greatly appreciated - if you need any configuration files, just ask and I'll email them to you. You didn't post anything really relevant, but maybe it could be caused by the port binding (for some reason). -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.5.x JDBCRealm problem - wasn't this fixed?
On Sun, 27 Mar 2005 16:57:53 -0800, Michael Mehrle [EMAIL PROTECTED] wrote: Sorry for reposting this, but I'm really desperate - anyone?? In 5.5.9 (see the changelog). We recommend using the data source realm, BTW, which does everything much better. I just switched from 5.0.28 to 5.5.8 on my Fedora server. The app works fine but after some inactivity of approx 7 hours I try to log in and get the following error: at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) [tdx] WARN [http-8080-Processor23] JDBCRealm.getPassword(555) | Exception retrieving password for molecool If I recycle tomcat it works fine and as long as I keep hitting the server I don't get this problem. However, if I am gone for a few hours and come back I encounter this problem. Now, I did some digging online and others have encountered this as well. But I was under the impression that this bug was fixed and that 5.5.8 wasn't leaking connections anymore. Just for sh...ts and giggles I tried 5.5.7 and it's got the same problem. Here's my cofiguration: Context path= docBase=ROOT debug=99 reloadable=true antiJARLocking=true antiResourceLocking=true Realm className=org.apache.catalina.realm.JDBCRealm debug=99 driverName=@DB-DRIVERNAME@ connectionURL=@DB-URL@ connectionName=@DB-USERNAME@ connectionPassword=@DB-PASSWORD@ userTable=app_user userNameCol=username userCredCol=password userRoleTable=user_role roleNameCol=role_name / Resource name=jdbc/tdx auth=Container type=javax.sql.DataSource maxActive=100 maxIdle=30 maxWait=1 driverClassName=@DB-DRIVERNAME@ username=@DB-USERNAME@ password=@DB-PASSWORD@ url=@DB-URL@ defaultAutoCommit=true removeAbandoned=true removeAbandonedTimeout=60 logAbandoned=true/ /Context I would really appreciate some help here. There appears to be some jakarta-.jar file that fixes this, but I was unable to dig it up. I also tried to get tomcat out of cvs, but the build process seems to be more than I can handle at this point (missing references). This site needs to be up and running by Tuesday - ANY pointers would be very welcome ;-) Michael -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.5.x JDBCRealm problem - wasn't this fixed?
On Mon, 28 Mar 2005 09:28:24 -0800, Michael Mehrle [EMAIL PROTECTED] wrote: Fixed indeed - I was up late yesterday and jumped on that 5.5.9 release like it was manna from heaven (best analogy I could think of - I'm not religious). Logged in this morning after a night of inactivity and everything seems to be working :-) Good. Thanks for taking care of this, guys - please forward my regards to the person who fixed this. I also must point out that everything seems to be a bit snappier now - have there been any performance increases? I'm running an image gallery all through tomcat, so it's hosting *everything* - looks a lot faster than before. Good job. There were no performance improvements since 5.5.4, so Ithere should not be any difference with the new build. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trying to disable Coyote gzip compression only when there is a server response status code of 500...
On Tue, 22 Mar 2005 13:39:55 -0500, Eric Butler [EMAIL PROTECTED] wrote:
First of all, thanks to all the developers and users that have
contributed to Tomcat. It's quite an amazing piece of software.
I'll start by telling you why I am trying to do this, what approaches I
have taken in my attempts to do it, and then I'll ask for some
suggestions on other approaches that may work better.
*Why*
We have an MS .Net (1.1) client talking SOAP over HTTP to Webservices
built on Sun's JWSDP 1.3 (via Tomcat). There is a pretty strict
requirement to compress responses as they are usually 200-1000KB. There
is a 'lack of feature' in the MS .Net Webservice client implementation
in that it is not possible to decompress the HTTP response when there is
a server response code of 500. The SOAP spec requires that SOAP Faults
on the server set the response code to 500, and thus we are unable to
process any SOAP faults on the client. In all other cases we are cool
in decompressing the responses. Since there don't exist any options for
us on the client we are limited to the server for solutions.
*Approaches attempted and failed*
-Servlet filters - a servlet filter only has access to the
HttpServletRequest and the HttpServletResponse and neither of these is
aware of the response status code.
Wrap the response object. A servlet like the compression filter has to
wrap anyway to be able to work.
-Coyote's compression option with a numerical value higher than all Soap
Fault sizes - it seems that the content-length of the response is always
set to -1, either by Sun's JWSDP or because the HTTP response is
chunked. I'm not sure which is the cause, but when the content-length
is -1, the response is always compressed.
-We tried an endless list of things on the .Net client in an attempt to
decompress the SOAP Fault responses to no avail.
*Approaches attempted and suceeded*
-Modifying org.apache.coyote.http11.Http11Processor.class by adding this
immediately inside of isCompressible()
if ( response.getStatus() == 500 ) {
return false;
}
I know this isn't pretty but it works. This will be acceptable if I
can't find a better option, but it will require that each time we
upgrade Tomcat, we'll need to compile a custom Http11Processor. I'll
also need to check that we aren't violating the Apache License.
It obviously does not violate the Apache license.
--
x
Rémy Maucherat
Developer Consultant
JBoss Group (Europe) SàRL
x
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.7. server.xml doc may be buggy...is it bugzilla time?
On Thu, 10 Mar 2005 12:21:29 +0100, David Tonhofer, m-plify S.A. [EMAIL PROTECTED] wrote: 00Exception performing authentication 01 javax.naming.NameNotFoundException: Name jdbc is not bound in this Context 02 at org.apache.naming.NamingContext.lookup(NamingContext.java:769) Ah, cool, so you did not read the docs for the datasource realm, then ... http://jakarta.apache.org/tomcat/tomcat-5.5-doc/realm-howto.html#DataSourceRealm - localDataSource Out of luck? Bugs related to other Tomcat versions helped out: http://issues.apache.org/bugzilla/show_bug.cgi?id=24723 http://issues.apache.org/bugzilla/show_bug.cgi?id=24836 I put the Resource element inside the GlobalNamingResources element, described here: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/config/globalresources.html ...and it worked! Makes sense. Additionally: The 'factory' attribute of the 'Resource' element is mentioned nowhere... o_O which is **BAD** because w/o the factory value the Realm Authentication seems to reduce to 'Access All Areas' - you don't get no error in the catalina log either. You indeed should not be specifying the factory, and it works fine. Please stop whining. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDBCRealm changes from Tomcat 5.0.x to 5.5.x
On Wed, 09 Mar 2005 17:39:21 -0800, alexander dosher [EMAIL PROTECTED] wrote: and an Engine Realm className=org.apache.catalina.realm.DataSourceRealm name=UserDatabase and i get java.lang.NullPointerException at javax.naming.NameImpl.init at javax.naming.CompositeName.init at org.apache.naming.NamingContext.lookup (etc.) so please accept my application to the Frustration Club. :( You get a membership to the RTFM club instead ;) http://jakarta.apache.org/tomcat/tomcat-5.5-doc/realm-howto.html#DataSourceRealm The JDBC realm in 5.5.8 obviously still has the bug related to connection handling, as I only fixed it two days ago. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDBCRealm changes from Tomcat 5.0.x to 5.5.x
On Wed, 9 Mar 2005 10:40:37 -0500, Phillip Qin [EMAIL PROTECTED] wrote: Could any one who has tested it post his result? I am really frustrated by the sometime buggy 5.5 releases and I had to revert to 5.0.28. You can also use the realms form 5.5.4, as they don't have problems. The regressions were introduced when adding digest authentication support to the database realms. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDBCRealm changes from Tomcat 5.0.x to 5.5.x
On Tue, 08 Mar 2005 14:28:12 -0800, alexander dosher [EMAIL PROTECTED] wrote: i'm getting the same problem, w/MySQL 4.1.8 3.1.6 connector (except my error is Software caused connection abort rather than broken pipe - but same underlying cause, MySQL timing out the connection). autoReconnect doesn't work for me either. sounds like perhaps i should bail on 5.5.* go to 5.0 for a while? I'd be extremely glad if you could test this possibly fixed realm. Replace the existing class in server/lib/catalina-optional.jar. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDBCRealm changes from Tomcat 5.0.x to 5.5.x
On Tue, 08 Mar 2005 15:16:41 -0800, Hassan Schroeder [EMAIL PROTECTED] wrote: Richard Mixon (qwest) wrote: We upgraded from Tomcat 5.0.19 to Tomcat 5.5.7 in production and are now getting JDBC connection errors when the site has not been accessed for a while. This is happening when a user tries to login - we use a JDBCRealm to authenticate the user. Would using the DataSourceReal provide any help here? I'm using a DataSourceRealm with 5.5.7 and not seeing any problems reconnecting at any time (MySQL 4.1.7 + Connector/J 3.1.6)... Be careful about this bug with the DataSourceRealm (fixed in 5.5.8): http://issues.apache.org/bugzilla/show_bug.cgi?id=33357 Similarly, I would appreciate testing of the fix. I agree there's absolutely no reason to use the regular JDBC realm, which can be a bottleneck in some cases. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDBCRealm changes from Tomcat 5.0.x to 5.5.x
On Tue, 8 Mar 2005 16:28:22 -0700, Richard Mixon (qwest) [EMAIL PROTECTED] wrote: Remy, Thanks - but where do I get the new class file? The Apache mail server, which, BTW, must be the worst mail server in existence, chooses to let through all the viruses and spammers of the world, but is refusing my perfectly legitimate attachement. So sorry, you have to either build it from CVS (which is easy) or get it from a nightly build. I'd like to add that the DataSource realm works differently from the JDBC realm. As a result, it would reconnect transparently, and the problem you have won't occur. If you decide to try the data source realm, I recommend using the version from 5.5.8, unless you expect a really low amount of authentications (it will take a little time for the connection pool to reclaim the resources which are not properly closed by the realm). -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.5.8 release timeframe?
On Mon, 7 Mar 2005 15:07:15 -0500, Andy Kriger [EMAIL PROTECTED] wrote: I've read the FAQ regarding 'when it's ready' and I haven't seen anything about this in the mailing list archives, however, I still need to be able to answer this question for my boss. We started up the 5.5 path with .4, which had a bug with POST and basic auth that required upgrading to .7 which has a bug with DataSources not closing connections that is fixed in .8 - can anyone give a timeframe for a 5.5.8 release? A rough scale would be fine - days? weeks? months? Even a guesstimate based on experience with how long previous alpha's took to release would help me ease my boss's concerns. Well, it's not that hard to either: - use 5.5.8 even if we have a label alpha; if you ask me, it's stable, but we simply didn't vote on it (and since the vote still hasn't happened, I'd say we'll go with the next build instead) - get the replacement class you need from 5.5.8, or from CVS, etc :) -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to approximate tomcat-5.0/4.x/3.x logging in 5.5?
On Thu, 03 Mar 2005 12:11:27 -0500, Adrian Robert [EMAIL PROTECTED] wrote: That's extremely odd. What version of Tomcat are you running? That's a bug because WEB-INF/classes should be put in the classpath before jars in WEB-INF/lib. I agree it's very odd. This is 5.5.7, with the 1.4 compatibility package on MacOS. I've experienced similar issues before with different tomcat versions, though I had forgotten that in this case.. Note I do NOT unpack the app from a war, just copy the full hierarchy straight under webapps. Also, the WEB-INF/classes/log4j.properties file was a symblic link. Maybe one of these makes a difference? Yes, I think the symlinking is the issue. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to approximate tomcat-5.0/4.x/3.x logging in 5.5?
On Wed, 02 Mar 2005 09:22:33 -0500, Adrian Robert [EMAIL PROTECTED] wrote: ... log4j.logger.org.apache.catalina.core.ContainerBase.[Catalina].[localho st].[/myapp]=INFO, MYAPP log4j.additivity.org.apache.catalina.core.ContainerBase.[Catalina].[loc alhost].[/myapp]=false I don't understand this bracket notation. Is it documented anywhere? Is interpretation of it something implemented by tomcat or by log4j? Would it help me achieve what I'm trying to get without changing my webapp's code away from ServletContext.log()? The logger names used in Tomcat are documented in the configuration pages. For example for webapps, it's here, in the Logging paragraph: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/config/context.html -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to approximate tomcat-5.0/4.x/3.x logging in 5.5?
On Wed, 02 Mar 2005 09:21:08 -0500, Adrian Robert [EMAIL PROTECTED] wrote: On Mar 1, 2005, at 6:45 PM, Remy Maucherat wrote: On Tue, 01 Mar 2005 18:18:49 -0500, Adrian Robert [EMAIL PROTECTED] wrote: However, I can't seem to find the right combination of log4j.properties lines, or maybe I'm trying something impossible. (I can't find good docs on the uses of log4j.properties when used inside the hierarchical classloading context that tomcat provides.) What keeps happening is that the webapp's log statements keep going into the global tomcat log. Would I be better off with JDK logging instead? I am working at the moment on a small package (which will be an implementation of java.util.logging) which will allow you doing that using the JDK logging. The main issue with it as supplied in the JDK is that there is only one global configuration per JVM. The trick is to make that per classloader, with delegation, so that webapps are isolated. At the moment, I think log4j is your only choice (unfortunately, I'm no expert, so I can't give you tricks with this particular configuration). In the same package, I will also provide a handler with daily rotation. It should be done by the end of the week (it doesn't work at the moment, I'm busy debugging ;) ). Great news. I'm happy to help test this. I'd rather use JDK logging than log4j if possible to avoid an additional deployment dependency. Actually, this is still an extra dependency: you have to add a JAR (10KB at the moment, but it'll likely grow to 12KB once I finish the needed extensions to the standard java.util.logging) for the core (the LogManager) and the rotating file handler (the JDK impl's handler don't have anything which rotates). It works by providing a replacement impementation for the JDK's LogManager which keeps a per classloader set of loggers. This is configured using a per classloader logging.properties (same format as the main logging.properties of the JDK, but with a few additional tricks to allow more flexibility with defining handlers and assigning them to loggers whenever needed). Properties files are simple, and are a good default. If no logging.properties exist anywhere, the JDK configuration will be used. Support for other configuration sources can be done using separate LogManager implementations. At the moment, the code will live in the Tomcat CVS, but the general consensus is to migrate it to commons eventually. We'll see. I don't know either if it will be included in the Tomcat binary; at the moment, I'd say it will not. The seed code for the new LogManager (which is attached to bug 33143) is here: http://issues.apache.org/bugzilla/attachment.cgi?id=14036 It doesn't actually work, and all it does is separate logger instances (which is quite good already, as you can programmatically set levels, assign handlers, etc, but you need to code for java.util.logging to use that). So I'm working on extending it at the moment to allow non programmatical configuration, where your webapp can simply be coded for commons-logging. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to approximate tomcat-5.0/4.x/3.x logging in 5.5?
On Wed, 2 Mar 2005 11:09:56 -0600, Jacob Kjome [EMAIL PROTECTED] wrote: Quoting Adrian Robert [EMAIL PROTECTED]: exists. This would continue to make Tomcat-5.5 more involved in logging than it should, though. I think Yoav Shapira has it right when he says that Tomcat should not really be directly involved in logging, but use the external implementation. I'm not sure what the solution is. Probably needs more discussion. That's the idea. Logging services should be external, rather than proprietary to Tomcat. the problem comes that we need some kind of defaults (like the current one, which is use whatever java.util.logging defaults are configured). Hmm.. I'm using log4j-1.2.9. I had the jar in both places but wasn't getting the isolation since my webapp was still pumping things into tomcat.log according to the container's log4j.properties.. However, I'm creating the logger in a static block in one of my webapp's classes -- could that have been the issue? Do you have webapp libraries sitting in a shared classloader such as shared/lib or common/lib? That would do it. 1. Make sure all your application classes are in WEB-INF/lib or WEB-INF/classes 2. Make sure log4j.jar is in WEB-INF/lib (remove commons-logging.jar if it is there. If you don't specifically need it, it can, and will, cause problems for you) 3. Make sure log4j.jar and commons-logging.jar (not commons-logging-api.jar!!!) are in common/lib 4. Make sure you have log4j.properties in both common/classes and WEB-INF/classes. You might even want to switch to using a log4j.xml config file for your webapp just to be sure that you aren't picking another log4j.xml file improperly distributed in a jar file. If you do all the above, logging should work as you expect. Note that for ServletContext.log() statements to go to context-specific files, you will still have to define the loggers as detailed in the example log4j.properties that I sent in my previous email. It's a bit tricky sometimes. For example, getting the container logger a bit too early, when the context CL isn't set to the webapp CL (it doesn't exist yet) can get you a logger based on the main configuration. That's an issue with the current CVS code, but I think it should be ok with the version used here (although it's tough to be 100% sure). -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to approximate tomcat-5.0/4.x/3.x logging in 5.5?
On Tue, 01 Mar 2005 18:18:49 -0500, Adrian Robert [EMAIL PROTECTED] wrote: I'm having trouble approximating the earlier tomcat per-context Logger functionality using log4j under tomcat-5.5. Basically, I would like to have one file coming out under $CATALINA_BASE/logs/ per web application context. This appears to be no longer possible through ServletContext.log(). So I tried using log4j: 1) put log4j.jar, commons-logging.jar in common/lib AND webapps/*/WEB-INF/lib 2) put log4j.properties in common/classes AND webapps/*/WEB-INF/classes However, I can't seem to find the right combination of log4j.properties lines, or maybe I'm trying something impossible. (I can't find good docs on the uses of log4j.properties when used inside the hierarchical classloading context that tomcat provides.) What keeps happening is that the webapp's log statements keep going into the global tomcat log. Would I be better off with JDK logging instead? I am working at the moment on a small package (which will be an implementation of java.util.logging) which will allow you doing that using the JDK logging. The main issue with it as supplied in the JDK is that there is only one global configuration per JVM. The trick is to make that per classloader, with delegation, so that webapps are isolated. At the moment, I think log4j is your only choice (unfortunately, I'm no expert, so I can't give you tricks with this particular configuration). In the same package, I will also provide a handler with daily rotation. It should be done by the end of the week (it doesn't work at the moment, I'm busy debugging ;) ). -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.7 hangs on startup
On Fri, 25 Feb 2005 17:13:41 -0500, Curtis, John G [EMAIL PROTECTED] wrote: Having a problem getting Tomcat 5.5.7 to start. The configuration is basicly the default except for some trival changes to the tomcat-user.xml. The catalina.out leads me to believe it's a problem with the ajp, but that's just my best guess 'cause it hangs just prior to starting the connector: tail catalina.out Feb 25, 2005 5:10:10 PM org.apache.catalina.core.ApplicationContext log INFO: ContextListener: contextInitialized() Feb 25, 2005 5:10:10 PM org.apache.catalina.core.ApplicationContext log INFO: SessionListener: contextInitialized() Feb 25, 2005 5:10:12 PM org.apache.catalina.core.ApplicationContext log INFO: ContextListener: contextInitialized() Feb 25, 2005 5:10:12 PM org.apache.catalina.core.ApplicationContext log INFO: SessionListener: contextInitialized() Feb 25, 2005 5:10:15 PM org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on http-8080 Hangs here forever. OS is Solaris 8 Java is version 1.5 I have the same configuration working fine on a Windows 2000 and Windows XP box. If Tomcat is hung, always try to get a thread dump. I suppose the problem occurs when binding the server socket. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Free online presentation on native webserver integration and Tomcat
Hi, Mladen Turk and myself will do a free (registration required) presentation tomorrow (Wednesday, February 23, 2005 at 1pm Eastern Daylight Time (GMT -04:00, New York)), mostly on native web server integration with Tomcat. http://www.jboss.org/services/online_education Topics which will be discussed include: - short intro on Tomcat inside JBoss - mod_jk configuration - presentation of upcoming mod_jk features - mod_proxy presentation Nearly half of the presentation will focus on ongoing native connector development and roadmap. It will be concluded by a demo of a failover scenario featuring the newly added jkstatus. I know there are quite a few people who are a bit confused about where this part of the Tomcat development is going ;) -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Free online presentation on native webserver integration and Tomcat
On Tue, 22 Feb 2005 12:50:59 +0100, Mladen Turk [EMAIL PROTECTED] wrote: Allistair Crossley wrote: February 23, 2005 at 1pm Eastern Daylight Time (GMT -04:00, New York). I believe this should be GMT -5 however? No? February 23, 2005 at 18:00 GMT. So calculate to your own timezone :). I think NY is GMT -5 indeed. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Free online presentation on native webserver integration and Tomcat
On Tue, 22 Feb 2005 12:24:28 -, Allistair Crossley [EMAIL PROTECTED] wrote: Yep, I was just pointing out the the Jboss site is inaccurate and may cause confusion. 1300 EDT is 1300-5 = 0800 not 1800, so us Europeans will all have to get up rel early in the morning ;) No, it's the opposite, it's late ;) It's 13:00 + 6 for the Paris timezone (= 19:00 = 7 PM), and 6 PM for London. I suppose the time is more to accomodate the west coast. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to prevent Context Reload upon changing web.xml
On Tue, 22 Feb 2005 14:21:24 -0800, Neeraj Vora [EMAIL PROTECTED] wrote: I migrated from Tomcat 4.0.2 to Tomcat 5.5.7. The former was not reloading the context if I changed application's web.xml file after deployment. The latter does that. Is there a way to prevent it? During the searching for this I read a post that having a context entry with reloadable attribute set to false does not prevent Tomcat from reloading the WebApp upon touching the web.xml. Look in conf/context.xml. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ThreadDeath with tomcat 5.5.7 and bouncycastle
On Sun, 20 Feb 2005 09:00:58 +1100, Adam Jenkins [EMAIL PROTECTED] wrote: Hi All, I'm getting a really odd error when I try to init a ciphers (or any other artifact for that matter) using BC as the provider in tomcat 5.5.7 (struts application). The call is simply final Cipher rsaCipher = Cipher.getInstance(RSA/ECB/PKCS1Padding, BC); and I get the following: java.lang.ThreadDeath at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1221) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1181) at java.security.Provider $Service.getImplClass(Provider.java:1116) at java.security.Provider $Service.newInstance(Provider.java:1074) at javax.crypto.Cipher.getInstance(DashoA12275) at javax.crypto.Cipher.getInstance(DashoA12275) The bouncy castle libraries are included in the classpath, and are being initialized correctly in the servlet init with the call: Security.addProvider( new BouncyCastleProvider()); JVM Details: java version 1.5.0-rc Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) Client VM (build 1.5.0-rc-b63, mixed mode) uname -r: 2.6.8-gentoo-r10 Anyone have any ideas? Yes, plenty :) The first one is to not crosspost, especially to lists where it is OT. The second one is, don't put your security provider in WEB-INF/lib unless you plan to remove it when the webapp is stopped (or don't expect to reload your application). Even if you do remove it, it's a little bit risky, and IMO bad design to do this kind of thing inside a webapp. And the third one is to post full stack traces. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: running tomcat using sablevm
On Fri, 18 Feb 2005 09:54:30 +0530, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hello, Has anyone tried running tomcat using sablevm (JVM). I am trying to run tomcat but it fails. It gives ClassDefNot Found error. I don't know how to go about running the tomcat. Any suggestions or any help is appreciated!!! No idea about Sable, but Kaffe from CVS works, as long as you help it by adding stuff in the classpath (commons-logging-api.jar and jmx.jar). Basically it doesn't read the manifest which are in JARs yet. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: running tomcat using sablevm
On Fri, 18 Feb 2005 16:48:36 +0530, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Where could I find the changes which you merged. Please help me out as I need it to fix my sablevm problem. I think you should give up on sable at the moment. I have never heard of anyone doing anthing Tomcat related with it, so it doesn't look good. Apparently, if you get Kaffe (www.kaffe.org) from CVS and build it, you might be able to run Tomcat 5.5 (with the usual JDK 1.4 compat for the jmx.jar, unless they also merged in a JMX impl) out of the box. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jasper 2 problem with core taglibs in 5.5.7?
On Wed, 16 Feb 2005 16:40:25 +, David Kennedy
[EMAIL PROTECTED] wrote:
Hi folks,
I have a Ant build which includes pre-compilation of JSPs. This has been
working happily during prototyping with Tomcat 5.5.4, but has broken now
that we have moved to Tomcat 5.5.7 as the latest stable build, which
worries me a lot.
The error I get during the build is:
org.apache.jasper.JasperException: The absolute uri:
http://java.sun.com/jsp/jstl/core cannot be resolved in either web.xml
or the jar files deployed with this application
The Ant task:
target name=define-jasper2-task
taskdef name=jasper2 classname=org.apache.jasper.JspC
classpath
path id=jspc.classpath
pathelement location=${java.home}/../lib/tools.jar /
fileset dir=${tomcat.dir}/server/lib
include name=*.jar /
/fileset
fileset dir=${tomcat.dir}/common/lib
include name=*.jar /
/fileset
fileset dir=${lib-dir}
include name=*.jar /
/fileset
/path
/classpath
/taskdef
/target
${lib-dir} contains jstl.jar and standard.jar, and the line in
the JSPs causing trouble is:
%@ taglib uri=http://java.sun.com/jsp/jstl/core; prefix=c %
I understand this sort of error to be typically to do with JSTL1.0/1.1,
but I don't think this is an issue here, especially as 5.5.4 works fine.
The ONLY thing I change is the value of ${tomcat.dir}. Has anyone seen
this, or can anyone suggest a resolution?
http://issues.apache.org/bugzilla/show_bug.cgi?id=33373
--
x
Rémy Maucherat
Developer Consultant
JBoss Group (Europe) SàRL
x
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Deploying with Tomcat 5.5
On Wed, 16 Feb 2005 13:40:12 -0500, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Is there not a way to deploy a WAR file in Tomcat 5.5 to a new virtual host without having to use the Admin web module to add the new host element and or manually modifying the server.xml file. I can seem to find any documentation on this. I know in JBoss you can include an XML file that has the host information in it so it deploys properly. I had plans to do a small host manager webapp similar to the regular manager. This would be the cleanest solution. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat vs Jetty
On Sat, 12 Feb 2005 10:51:53 +0100, PA [EMAIL PROTECTED] wrote: On Feb 12, 2005, at 06:20, Peter Lin wrote: For those who are curious. I decided to run apache AB against jetty to see if there are any differences. If you are into this kind of micro-benchmarks, take a look at Simple: http://simpleweb.sourceforge.net/ Niall Gallagher ran some comparisons between Apache, Resin and Tomcat: http://simpleweb.sourceforge.net/performance/comparison.php Quite instructive :P Unless Peter does a round of benchmarking on that, I see nothing but misinformation. Right now, the test is not very fair (conviniently old Tomcat version; not the same application code appeared to be running on both servers as the other one doesn't support the servlet API) and not very well specified either (there's text about the test, but I don't understand it in a way that woud allow me to reproduce the test). -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: Compression in the server.xml
On Wed, 09 Feb 2005 06:31:07 -0500, Tim Funk [EMAIL PROTECTED] wrote: No. They are written in 2 different languages and have 2 different purposes. Indeed. Integration will improve, though (the Apache/Tomcat connector will be bundled in Apache and will be compatible with all the other module combination (such as cache + ssl + gzip). -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MemoryError: PermGen space after several redeployments
On Tue, 08 Feb 2005 11:26:50 +0100, Peter Rossbach [EMAIL PROTECTED] wrote: Hello Matt, I hope we have fix that with 5.5.8 see: http://issues.apache.org/bugzilla/show_bug.cgi?id=26135 You can use a context listener to clean that up. The container can't always cleanup after the application, so if you want to really use redeployment, then you need to make sure that applications are reasonably well designed. Easy example of a leak that can't be fixed by the container: put a JAR in common with a static class keeping references to some of the application objects (ex: some sort of server global cache), and don't clean these up. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.7/DataSourceRealm/Manager app
On Tue, 8 Feb 2005 16:39:40 -0500, Phillip Qin [EMAIL PROTECTED] wrote: I am having serious issue with Tomcat Manager app using DataSourceRealm during upgrading from Tomcat 5.0.28 to 5.5.7. The issue is, after I accessed Tomcat Manager app couple of times, I got this exception It could be this issue: http://issues.apache.org/bugzilla/show_bug.cgi?id=33357 The patch needs some testing, but you can grab the replacement class from a nightly build, or build it from CVS. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.7/DataSourceRealm/Manager app
On Tue, 08 Feb 2005 21:49:16 +, Mark Thomas [EMAIL PROTECTED] wrote: It is a known bug that has been fixed and will be included in 5.5.8. Sorry. Did it exist in 5.5.4, or is it a regression ? -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version control in WebDAV component of Tomcat
On Mon, 07 Feb 2005 22:25:20 +0800, Wong Onn Chee [EMAIL PROTECTED] wrote: Hi, I am new to the latest version of Tomcat 5.5. I know that it has a bundled WebDAV component, but I can't get the version control feature working. Does any one know how I can do it? If you mean Delta V, then there's no support for that, and you should look into using Slide instead. The Tomcat WebDAV servlet supports WebDAV level 1, with partial level 2 support (some complex locking operations are not supported). -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Solaris 10 Tomcat 5.5.7
On Mon, 7 Feb 2005 12:55:56 -0500, Chad Kellerman [EMAIL PROTECTED] wrote: Tomcat Users, I thought I would test out Tomcat 5.5.7 on a Solaris 10 (Ultra 60) so see how it performs. Here is what I did. edited /etc/profile JAVA_HOME=/usr/java export JAVA_HOME exploded the tar ball in /opt/ then created a link to jakarta.XX.XX name tomcat I started tomcat, it started but there are messages in the catalina.out file that don't make sense. catalina.out SEVERE: Exception starting filter Compression Filter java.lang.ClassNotFoundException: compressionFilters.CompressionFilter Then I tried to go to the example pages on http://localhost:8080/jsp-examples/ and recieved an error. Feb 7, 2005 11:12:09 AM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Allocate exception for servlet org.apache.jsp.jsp2.el.basic_002darithmetic_jsp javax.servlet.ServletException: Wrapper cannot find servlet class org.apache.jsp.jsp2.el.basic_002darithmetic_jsp or a class it depends on I have java 1.5.0_01 and Tomcat 5.5 installed on a Fedora server and everything works fine, but the java on the SOlaris server seems to mess things up a bit. Anyone else see this? Anyone else have a fix? Did you use GNU TAR to extract the .tar.gz ? -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Updating running WARs?
On Fri, 04 Feb 2005 17:45:12 -0600, Jonathan Wilson [EMAIL PROTECTED] wrote: Someone else will be able to attest to this better than I, but there is a known issue with the classloader [I think] that doesn't release memory on a undeploy..eventually you'll run out of memory after a certain number of deploy/undeploys. You could try using the jvm's -Xmx modifier in your startup/catalina shell, which may buy you more time[guru input here, please]... Do you mean this ? http://issues.apache.org/bugzilla/show_bug.cgi?id=26135 It turned out to be a JDK feature ;) But my app starts up lightweight so I can schedule downtime a couple of hours or so in advance, then drop tomcat for a few minutes while I deploy manually. Maybe you could use the Manager: Stop the Service, undeploy, stop TC, start TC, deploy the service using the Manager, start service if necessary. It is indeed difficult to guarantee that everything will be cleaned up, unless the application is reasonably well written. In case of issues like usage of the bean instrospector as mentioned above, some explicit cleanup is required (now done automatically by Tomcat, but this will only be in the next release). See the bug report for info on workarounds. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is there any option for .rar files on Tomcat 5.5.7
On Thu, 03 Feb 2005 18:04:00 -0500, Edmon Begoli [EMAIL PROTECTED] wrote: I understand that Tomcat is not a full J2EE app. server, but I would like to know if there are any options to deploy .rar JCA adapters on Tomcat 5.5.7? No, Tomcat doesn't support JCA, sorry. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: article draft - Summary of benchmark
On Tue, 1 Feb 2005 15:18:59 -0500, Peter Lin [EMAIL PROTECTED] wrote: I've updated the document with more charts from the excel spreadsheet and tried to make the explanations more clear. I'm really interested in the part of your tests which show certain new CPU architectures showing a big improvement in Java. I suppose it benefits a lot from large caches (Pentium M, Opteron), and I suppose more regirsters won't hurt either (x86-64). -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SocketException: Too many open files
On Tue, 01 Feb 2005 17:29:51 -0600, Stephen Charles Huey [EMAIL PROTECTED] wrote: I'm running some simple but fast-pounding test programs against our Tomcat server from a machine on the same network, and we've been tuning our database, etc, based on this. But right now, I'm seeing a new one coming out of our Java code whenever we try to open a URL: java.net.SocketException: Too many open files If you're on Linux, use ulimit -a to see what the limits are, and ulimit -n to change the value. However, only root is allowed to get more than 1024 files (does somebody knows why ?). -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat'evolution abstract
On Sat, 29 Jan 2005 19:02:25 +0100, Philippe Mathieu [EMAIL PROTECTED] wrote: Hi, I'm a little bit lost in the releases; Does anyone could tell me precisely since which release ... : - Tomcat takes account of JSP 2.0 ? 5.0+ - Realms are integrated in Tomcat ? 4.0+ (with API changes) - DBCP (pools) are integrated in Tomcat ? 4.1+ - the invoker servlet in not set by default ? (4.1.12 ?) Yes. - The DataSourceRealm is integrated in Tomcat ? 4.1.something - Context description can be put directly in catalina/localhost ? 5.0.0+ - DBCP syntax has been changed ? (5.5.4 ?) 5.5.0+ - loggers have disappeared ? (5.5.4 ?) 5.5.0+ - JDK 1.5 compliant ? (5.5.4 ?) 5.5.0+ - Removal of DefaultContext (replaced by conf/context.xml and other per host files) 5.5.0+ - JDT as the JSP code compiler 5.5.0+ (but it had very serious bugs in that build ;) ) -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ThreadPool logFull ERROR
On Fri, 28 Jan 2005 16:14:10 +0800, fan lianjie [EMAIL PROTECTED] wrote: i USE tomcat 5.54. 2005-1-28 15:59:42 org.apache.tomcat.util.threads.ThreadPool logFull : All threads (200) are currently busy, waiting. Increase maxThreads (200) or check the servlet status Did you try out what it says ? If you're using the HTTP connector, you could also try to set strategy=ms on the Connector element to see if it helps (I've been looking for people experiencing problems with the default thread pool to try out the alternate one). If you think you shouldn't be getting this because your website is low traffic, could you give more details ? -- x Rmy Maucherat Developer Consultant JBoss Group (Europe) SRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exploded WAR deployment in Tomcat 5.5
On Fri, 21 Jan 2005 10:45:35 +0100, Wouter Boers [EMAIL PROTECTED] wrote: Hello, I have found some strange behaviour in de Tomcat manager. When adding an exploded WAR directory, for example file:///c:/java/foo with context foo, Tomcat 5.5 starts to copy the *complete* C drive to TOMCAT_HOME/conf/Catalina directory. Tomcat 5.0 does not suffer from this problem. Is this an known issue? I haven't found it in the bug list or mail archive. This (really stupid) bug has been fixed in build 5.5.6+. The cause is that a check is missing for the case the path for the config XML file is empty. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Apache Jakarta Tomcat 5.5.7-alpha Released
On Fri, 21 Jan 2005 11:15:37 +0100, Lionel Farbos [EMAIL PROTECTED] wrote: On Thu, 20 Jan 2005 19:05:52 + Mark Thomas [EMAIL PROTECTED] wrote: Lionel Farbos wrote: Question : What is the reference or stable version for servlet 2.4 ? Is it Tomcat 5.0.28 or Tomcat 5.5.4 ? I don't understand why you implement 2 versions (2 branches) for this servlet API ...? http://jakarta.apache.org/tomcat/index.html has answers to these questions and more. If I post theses questions, it's because theses answers are not clear for me... So, I re-post my question differently : For production purposes, I want the most stable Tomcat Version (Servlet API 2.3 or 2.4); so, what version should I use ? TC4.1.31, TC5.0.28 or TC5.5.4 ? In my memories, TC5.0.x was not usable before 5.0.19 but she was announced stable... So I prefer requiring Tomcat developers' point of view. 5.5.4 is quite stable. The place where it had issues is the webapp hot deployer, which was rewritten (the 5.0.x deployer didn't do hot deployment very well overall, so I suppose you're losing something, but not much). I think the problems have now been addressed in the latest 5.5.7 build (which hasn't been rated stable yet). Virtually all the other issues were bugs affecting 5.0.x as well, and those weren't all backported yet. You can see the changelog here: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/changelog.html If you're deploying on a new server, I recommend starting your process using the latest stable branch. If you're updating, and since there's likely a new stable build coming soon, you could wait for it. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Apache Jakarta Tomcat 5.5.7-alpha Released
The Apache Jakarta Tomcat team is proud to announce the immediate availability of Tomcat 5.5.7-alpha. This build contains numerous bug fixes, documentation updates, and other improvements. Release notes: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/RELEASE-NOTES Please refer to the change log for the list of changes: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/changelog.html Downloads: Binaries: http://jakarta.apache.org/site/binindex.cgi#tomcat-5.5 Sources: http://jakarta.apache.org/site/sourceindex.cgi#tomcat-5.5 The Apache Jakarta Tomcat Team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bug in tomcat 5.5 and sticky sessions because of problem with jvmRoute parameter?
On Thu, 20 Jan 2005 13:15:58 +0100, Christian Schuhegger [EMAIL PROTECTED] wrote: hello, i've just tried to set-up tomcat 5.5 with apache2 and mod_jk version 1.2.8 in a load balancing set-up with sticky sessions. when i give as jvmRoute parameter the string tc1 my sessionids look like: BF20EF21CC52EA0659B1E079015D7B56.tc1.tc1 and i see in the mod_jk.log file that no worker with the name tc1.tc1 could be found! i've circumvented the problem currently by doubling the name in the workers.properties file as follows: -- snip start -- worker.list=load worker.load.type=lb worker.load.balance_workers=tc1.tc1,tc2.tc2 worker.load.sticky_session=True worker.tc1.tc1.port=12013 worker.tc1.tc1.host=localhost worker.tc1.tc1.type=ajp13 worker.tc2.tc2.port=12013 worker.tc2.tc2.host=remote worker.tc2.tc2.type=ajp13 -- snip end -- was this problem already noticed? did i do something wrong? or should i file a bug report? - Added jvmRoute=tc1 on Engine - Accessed http://127.0.0.1:8080/servlets-examples/servlet/SessionExample - Session ID displayed is 8DBBCECBCAD078E18C07401A076734B0.tc1 -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Expect: 100-continue
On Wed, 19 Jan 2005 13:54:36 +0100, Julian Reschke [EMAIL PROTECTED] wrote: Remy Maucherat wrote on tomcat-dev: Tomcat always automatically sends a 100-continue when going into the filter pipeline if an expectation is requested. This should be on tomcat-user, BTW. So are there any plans to improve this, for instance by implementing options 2bc? It's more complex, and the benefits are not that huge, so I'm not very motivated for doing it ;) -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: performance/scalability impact of many webapps in one container
On Tue, 18 Jan 2005 13:12:06 -, Varley, Roger [EMAIL PROTECTED] wrote: For reasons beyond my control, a web application (apache/Tomcat/PostgreSQL) that I support will need to be partitioned into one context per customer (to support one database per customer). I'm wondering: Do you really need one database per customer? In a similair situation, we resolved this by adding a client code to all our database tables indexes. Each customer/client was given their own URL to access the system and a filter used the incoming url to load a client code into the request headers before passing the request to a single servlet. Obviously, it all depends on the isolation level you want. For example, you can restrict what web applications can do in a multi-user environment by using the security manager. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] Tomcat training in Paris
Hi, Sorry for the ad, but maybe it could be of interest to some people here. I'm doing a 2 day training on Tomcat in Paris in february. The training is on advanced topics and covers mostly Tomcat 5.5. Details are available here: http://www.jboss.com/services/training/EMEAcourses#paris-tom -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: latest set of Benchmark results
On Sun, 16 Jan 2005 13:15:01 -0500, Peter Lin [EMAIL PROTECTED] wrote: Here is the latest set of benchmark results. I discovered an error in my test plan for 40K PNG, so the results for that one was off. All of the other results should be accurate. I re-ran the tests. Server: AMD 2ghz 1Gb RAM Redhat FedoraCore1 Client: Gateway laptop 450 1.4ghz centrino Windows XP pro jdk1.4.2 jmeter nightly build 16 port Switch Linksys 10/100 CAT5 cables All threads ran for 1000 iterations. thread scenario: 5, 10, 15, 20, 25, 30 image/html size: 1, 10, 20, 40, 80, 160 The test includes 5.0.19 (aka 5.0), 5.5.4, apache 2.0.50, apache 1.3.3. I hope people find it interesting and useful. It will take me a week or two to write up the results and generate the graphs. Does the -server option do anything other than use more memory ? ;) -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: performance/scalability impact of many webapps in one container
On Mon, 17 Jan 2005 15:02:28 -0700, Joel McGraw [EMAIL PROTECTED] wrote: For reasons beyond my control, a web application (apache/Tomcat/PostgreSQL) that I support will need to be partitioned into one context per customer (to support one database per customer). I'm wondering: 1. What the performance implications are (if any) of having up to 300 contexts in one container? With Tomcat 5.x, it's ok, it will just use more memory. With 4.x, it's bad (one background thread per context = 300 background threads). 2. Are there any scalability issues of which I should be aware? - You might have tons of sessions, so increase the VM's memory - And the usual: one application doing bad things could take the whole server down, which will be a lot more noticeable for users -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: more benchmark results
On Fri, 14 Jan 2005 08:11:11 -0500, Peter Lin [EMAIL PROTECTED] wrote: Per Remy's request, I ran some more tests last night with larger number of threads. the configuration of the test plan is as follows 1K png: 10, 50, 100, 150 threads 10K png: 10, 50, 100, 150 threads each thread as was to 1000 iterations. ramp up times: 1, 5, 10, 20 seconds Server: Redhat fedora Core1 AMD 2ghz 1Gb RAM tomcat 5.0.19 Sun jdk1.4.2_03 Client: gateway 450 laptop 1.4ghz centrino 1Gb RAM jmeter nightly build sun jdk1.4.2 I plan to re-run these tests with the latest 5.0.x release this weekend and per Remy's request I will also test 5.5.4 with jdk5 for comparison. And no FC 3 ? ;) I think it would run fine on your computer, and it's a higher quality distribution overall (it doesn't have the stupid NPTL backport that FC 1 has). Or you could try Ubuntu (I plan to switch to that distro when they release hoary). Anyway, I'd be interested if you tried stressing a little the thread pool I added in 5.5 (strategy=ms threadPriority=7 on the Connector element) to see if it gives a difference in the error rate (and also if it's not completely broken). You may want to increase maxThreads as well for your tests (it's 150 by default, which is dangerously close of the concurrency used by your client) -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: some TC5 benchmark results for static file
On Thu, 13 Jan 2005 10:16:08 -0500, Peter Lin [EMAIL PROTECTED] wrote: I've started a series of benchmarks to measure tomcat5 performance for static files and compare it to apache2. Here are the results I have so far. I thought others might find it interesting. Server: Redhat Fedora Core 1 AMD 2hgz 1Gb ram jdk1.4.2 TC5.0.x ( have to double check the release number) I would like a quick comparison with the new stuff, and tests with higher concurrency (if possible): FC 3 + JRE 5 + Tomcat 5.5.7 Especially if you plan to write an an article, I'd be glad if you used the best available platform :) -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat arbitrarily freezes
On Tue, 11 Jan 2005 13:51:13 +0100, Oliver Schoenwald [EMAIL PROTECTED] wrote: Hi! five days after my first question and no answer in sight. To bad. So far, we have switched from JDK 1.4.2 to JDK 1.5 and from Tomcat 5.0.27 to 5.5.4 and the problem persists. However, while under JDK 1.4.2 it was always the thread with id #2 under JDK 1.5 it is still the thread VM Thread, but now under id #4. Using the better debugging features of JDK 1.5 (jstack, jmap) we could pin down the problem in more detail: whenever the problem starts, the output of jstack and jmap shows that these debugging-tools have more and more problems to give information about certain memory areas. When the problem reaches its climax, a bug number of memory areas are marked by jstack with an Error occurred during stack walking:-Message or by jmap with UnmappedAddressException. You see, at the moment we are only guessing what problem we have here. Maybe someone has an idea how to analyze the problem more properly or even know how to solve it (without changing some of the components like using another servlet container engine or another JVM). If you don't get any answers, it is that people don't have any ideas and / or nothing useful to say. For example, this is the first time I hear about a problem with this internal VM thread. While other Tomcat arbitrarily freezes issues are well known on some OSes, this one is brand new to me. You seem to assert that this is a common problem encountered by many people, and you also seem certain that your problems come for that (which means bad luck, as this is an internal VM thread). Can you give links giving more details about this ? -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Errors Starting Up Tomcat 5.5
On Mon, 10 Jan 2005 16:51:13 -0800, Ryan Austin [EMAIL PROTECTED] wrote: I just read that you need jre 1.5 or later and I was using j2sdk1.4.2_06. Could this be the cause of the errors I am seeing? I will update it and give it a try. You can still use 1.4, if you use the compat package which adds a few JARs. Usually, you notice something is wrong because Tomcat doesn't start, and displays an error about JMX missing. I suppose you have JMX somewhere on your classpath already. I suppose the XML parser in JDK 1.4 will have issues with schemas, so any 2.4 style web.xml would create problems. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC Drops bytes when client uses Chunked Encoding AND specifying Content-Length at the same time.
On Thu, 30 Dec 2004 17:58:09 -0800, Ian Huynh [EMAIL PROTECTED] wrote: We are using TC 5.0.28 on JDK 1.4.2 We have a client who POST to TC using header Transfer-encoding: chunked and at the same time specify the Content-Length header when posting to us. It seems that if the Content-Length is specified, TC is dropping the last few bytes..?? This same customer claims that his code works with the Jetty Servlet (which is the old embedded servlet in JBoss 3.2.1 and earlier). We have done some prelim testing and confirmed that a) if Content-Length is NOT specified and Chunked encoding is used, TC works as specified. b) Jetty works either way (with or without Content-Length). My questions are: 1. what is the correct behavior in HTTP 1.1? I've read through the spec but am unable to ascertain whether or not Content-Lenght should NOT be used when chunked encoding is used. 2. Is this a bug in TC? Unfortunately, our client isn't able to modify the code to NOT include the Content-Length or NOT use Chunk encoding This should be fixed in CVS, but your HTTP client is completely broken. I'm sure it won't be the last problem you'll have with it. You're lucky that this case is to be explicitely supported ... -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Authentication isn't working with mod_jk 1.7.3 beta.
On Fri, 17 Dec 2004 10:55:27 -0500, Jim Lynch [EMAIL PROTECTED] wrote: The request is making a single entry into the log. 198.149.32.31 - - [17/Dec/2004:09:46:27 -0600] GET /resources/input HTTP/1.0 401 667 If I go to port 8080 and get validated, then it works without the port 8080. It's normal that you get a 401 back. Then your browser should display the auth popup. Use a telnet to see the reply sent by Tomcat on both ports. Especially pay attention to the presence of a WWW-Authenticate header. The rest (except the 401 status code) is almost irrelevant. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does TC 5.5 have some type of farm deployer?
On Mon, 13 Dec 2004 11:09:43 -0500, Shapira, Yoav [EMAIL PROTECTED] wrote: Hi, This proposal is from Peter Rossbach, who's since become a Tomcat committer. I don't think the proposal was ever formally raised and discussed: this is the first time I've seen it. So it's certainly not been implemented, and highly unlikely to be in a Tomcat release any time soon, but if he's still working on it then it might eventually make it into Tomcat. Peter has added back farm deployment in 5.5.5. It's quite different from the farm deployer in 5.0.x, so probably we can assume it replaces whatever the proposal was. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.4 Ant Task
On Mon, 13 Dec 2004 11:34:08 -0600, Gregg [EMAIL PROTECTED] wrote: I recently migrated from Tomcat 5.0.x to 5.5.4. Everything seems to work great except the Ant Tasks. Deploy works just fine but when I do the undeploy task the folder that contains my webapp does not get removed. So when I go to deploy again, it says it can't because the context already exists. With 5.0.x the context was removed completely. Does anyone know if this is a bug or if the behavior of the ant tasks have changed? I couldn't find anything specifically about this in the changelog. There's a FAQ entry on this: http://jakarta.apache.org/tomcat/faq/windows.html#lock -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.4 Ant Task
On Tue, 14 Dec 2004 01:13:04 +0100, Siarhei Dudzin [EMAIL PROTECTED] wrote: Yes, antiJARLocking and antiResourceLocking are not enabled by default. Unfortunately, non of them (together and separately) did not help to solve my problems... Try harder, it works. Read the FAQ, and verify that they are actually enabled. If antiResourceLocking is enabled, you should notice it, as you'll get a cool extended coffee break while Tomcat starts, but you cannot possibly get any locking (unless you do really crazy stuff, like accessing files directly yourself using harcoded file paths). -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5 notably slower than tomcat 4...more info
On Sun, 5 Dec 2004 18:31:47 -0600, Dan Foreman [EMAIL PROTECTED] wrote: Hi, I've learned more since my last questions about tomcat 5 vs 4 performance. The reason that it seems so much slower is that there are more than twice as many packets being returned from the application server...most of which are SYN/SYN-ACK packets (no exaggeration, from 300 packets in tomcat 4 to 800 in tomcat 5). Initially the SYN requests come from the browser (true for IE and FireFox). Theorizing that the problem could be solved changing the connectionLinger setting from the default of 0 to 2000 ms we tried, but had no consistent change in the amount of SYN/SYN-ACK packets being exchanged between the browser and tomcat. The inconsistency in behavior leads me to believe that the problem is somehow related to load (network/cpu/etc), on occasion tomcat 5 will respond as tomcat 4 does (no extra chatter). Tomcat 4 running across the same exact network, through the same context switch does not exhibit this everthere is a single SYN/SYN-ACK initially and then just typical request/responses. Anybody else seen this? No. You'll need to look at this in detail, and I recommend doing some of the testing with really simple stuff (such as static files). -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
