Re: Ant install tasks
Robert D. Abernethy IV wrote: I was getting this same error and it took me some time to get around it. First, I decided to use a WAR file to deploy, rather than an unpacked directory. Second, I had to comment out the jasper2 task in the compile target because it was messing up my web.xml file in unimaginable ways. It is supposed to automatically add the mappings for the compiled JSPs. It doesn't do that in your original web.xml. The result is not supposed to be messed up, and there's an attribute (with an explicit name) which triggers that. Do I get more details about what went wrong ? I would switch to deploying via WAR file and check your web.xml file for problems. Are you using the Deployer package to deploy? -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC 4 -oreillyMultipart- TC5: Corrupt form data: premature ending
Dirk Griesbach wrote: Rémy, how would you have done it ? Maybe there can be applied a fix to it. You could add a sys.out in their readLine() method to see what is actually being read :) -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC 4 -oreillyMultipart- TC5: Corrupt form data: premature ending
Shapira, Yoav wrote: Howdy, If I were you, Senor Griesbach, I would dump COS in favor of jakarta commons fileupload instead of spending significant time debugging intricate input stream problems... But that's just me, and I'm not a patient debugger ;) What cos is doing is bad IMO (it should read in a byte buffer, IMO, and work in there, instead of using inefficient methods - which also generate Strings, so it's even more inefficient). I don't know what commons-fileupload is doing, but it works (he manager servlet uses it). But, I don't know, maybe there's an obscure bug with input. -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What is jakarta-tomcat-5.0.16-embed.zip ?
Shapira, Yoav wrote: Howdy, People who want to embed tomcat in their own applications, e.g. JBoss developers ;) It was created (by Costin) to: - test and debug JMX startup - improve embeddability - because some people wanted a smaller distribution (and the old LE wasn't actually useful, except to create problems ;-) ) AFAIK, it runs almost like a standard version of Tomcat, and is actually simpler (all shared stuff goes in lib, and webapps go in webapps). More JMX features will need to be added to be able to configure everything, but the essential stuff should be here. -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [TOMCAT] 5.0.16
Schalk wrote: Derek My JAVA_HOME points to j2sdk1.4.2/lib/tools.jar No, it should point to the base path of the JDK (ex: c:\j2sdk1.4.2). -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC 4 -oreillyMultipart- TC5: Corrupt form data: premature ending
Shapira, Yoav wrote: Howdy, Another issue came up comparing TC4 and TC5: using the oreilly multipart lib on TC5 causes the error ...Corrupt form data: premature ending on POST uploads. As stated in the FAQ's at http://www.servlets.com/cos/faq.html this problem is merely due to the webcontainer and has been fixed with Tomcat 4. Umm, you misread that section of the FAQ. It states that there are many possible causes for this bug. A small subcase (IE, client hitting stop then starting again, leading to empty input stream) was isolated and fixed in a couple of containers (tomcat 4.0 and weblogic 6.1 according to the FAQ). I tested and can state that this problem doesn't occur with TC4. But it is apparent with TC5 again. Will this be fixed ? If you provide a concise description along with a test case or steps to reproduce your problems, there's a chance it might be fixed. There has been enough testing for uploading (with the standalone connector, at least, but there's no difference with JK for this), that I can confidently say that there's very little likelihood of a Tomcat bug in this area. Maybe if the thing uses readLine on the Tomcat provided reader (a rather annoying method to implement, so maybe there could be a bug), but in the unlikely case it does, I recommend dumping that library in favor of commons-fileupload (readLine is by definition awful performance wise). -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC 4 -oreillyMultipart- TC5: Corrupt form data: premature ending
Dirk Griesbach wrote:
Rémy,
I had a look into the sources. There it reads:
class MultipartParser:
do {
String line = readLine();
if (line == null) {
throw new IOException(Corrupt form data: premature ending);
}
(:-)
By which method should 'readLine()' be replaced to achieve best performance
?
Yes, but what does this readLine method does and when is it called ?
I was talking about request.getReader().readLine().
--
x
Rémy Maucherat
Senior Developer Consultant
JBoss Group (Europe) SàRL
x
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC 4 -oreillyMultipart- TC5: Corrupt form data: premature ending
Dirk Griesbach wrote: Rémy, this copy is of type javax.servlet.ServletInputStream.readLine() acquired by HttpServletRequest.getInputStream(); Would you agree that this is a good idea ? Are you sure ? There's a ServletIS.readLine(byte[] b, int off, int len) method, but no readLine returning a String (that's in the BufferedReader). SevletIS.readLine is not optimal already (I thought nobody would use it). Maybe it would be a good idea to attempt to reimplement it eventually. -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC 4 -oreillyMultipart- TC5: Corrupt form data: premature ending
Dirk Griesbach wrote:
Rémy,
I'm quite sure. With a summary of oreilly´s sources I see:
class MultipartParser {
...
private ServletInputStream in;
private byte[] buf = new byte[8 * 1024];
...
ServletInputStream in = req.getInputStream();
...
do {
String line = readLine();
if (line == null) {
throw new IOException(Corrupt form data: premature ending);
thrown when using TC5, but not on TC4
}
...
private String readLine() throws IOException {
int result;
StringBuffer sbuf = new StringBuffer();
do {
result = in.readLine(buf , 0, buf.length);
...
sbuf.append(new String(buf, 0, result, encoding));
}
...
return sbuf.toString();
}
}
looks quite normal, doesn't it ?
If they're doing *that*, they might as well use the buffered reader
readLine method ;-)
Byte by byte input works (it's inefficent, obviously, but it works).
I recommend adding some debug in their readLine method to see what is
being returned.
--
x
Rémy Maucherat
Senior Developer Consultant
JBoss Group (Europe) SàRL
x
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Upgrade from 4.1.29 to 5.0.16, logging is too verbose?
Ryan Cornia wrote: I was running tomcat 4.1.29 with a log4j jar in the $CATALINA_HOME/common/lib folder and a log4j.properties file in $CATALINA_HOME/common/classes folder. This worked fine, and kept the log messages at the level I wanted them. When I installed 5.0.16, I put the log4j jar and properties file in the same locations listed above, but now when tomcat starts, it spits out a ton of INFO: messages into catalina.out, so I don't think it is actually using the log4j configuration. Any ideas on what might have changed? Is this how I should setup log4j to be used within tomcat? Tomcat 5 only supplies the c-l API, and put it in the system classpath, to avoid the problems with c-l seen in Tomcat 4.1. You have to supply the commons-logging wrapper for log4j (it's in the default c-l JAR), and put it next to the log4j JAR. Otherwise, I think log4j won't get used. -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.x and JBoss
J.L. wrote: Hi, I want to use JBoss 3.2.2 and Tomcat 5.0.14. The problem is that I have to replace the JBoss embedded Tomcat, by the 5.0.14 version (I need local access between servlets and EJBs). I have heard I can do that by recompiling JBoss with Tomcat 5.0.14, but I have no idea how to do that. If you have any ideas... JBoss 3.2.3 includes the latest Tomcat 5.0.16 build (the SAR is ready to build in docs/examples/tomcat). There are some details here: http://www.werner.be/blog/page/werner/20031202#jboss_3_2_3_with -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best JVM for Tomcat
Vic Cekvenich wrote: I use BEA's jRockit (but with tomcat 5) on Fedora. How does this work ? I've had trouble with jRockit on Linux, plus there's the new Posix threads reportedly causing problems. Maybe Fedora + new JRockits would help, but hard data would be useful. Are you using TC standalone ? Does the VM ever crash ? -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Apache Tomcat 5.0.16 Stable released
The Tomcat Team announces the immediate availability of Apache Tomcat 5.0.16 Stable. Please refer to the changelog for the list of changes. Downloads: Binaries: http://jakarta.apache.org/site/binindex.cgi Sources: http://jakarta.apache.org/site/sourceindex.cgi The Apache Tomcat Team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: deployment quirk in Tomcat5. Bug?
Jacob Kjome wrote: When deploying war files in Tomcat-5.0.16, I noticed something a little odd. After using the ant manager deploy task and then doing an undeploy, manually dropping the war file into CATALINA_HOME/webapps trigger auto-deployment. For example, say I have myapp.war. I just drop this into Tomcat5's webapps directory and it deploys the app as expected. I can do an undeploy via the html manager interface and it undeploys as expected. I can repeat this ad- infinitum and everything works fine. Now, I deploy myapp.war via the ant manager deploy task and it deploys as expected. Then I undeploy it with the html manager interface. Now I try dropping the war file manually into webapps as explained above. This time, the war does not deploy. If I restart Tomcat5, manual deployment works fine again...until after the first time I use the ant manager deploy task, of course. I can't imagine this is expected behavior. Well, at least I didn't expect it. Can anyone else confirm what exactly expected behavior is before I report a bug on this? Don't bother: there's no use case for this, other than giving me a headache. I don't find auto deploy very useful anyway, given that Tomcat doesn't have a fancy deployer like JBoss. It works much better when used in its simple scenario (you want to deploy or update a WAR) rather than more complex stuff, when you should really use the manager. For non development stuff, forget about the auto deployer, and use exclusively the manager. BTW, for updating a WAR with the auto deployer, you don't need to undeploy first with the manager, and then copy the WAR over again: simply overwrite the WAR and the webapp will be undeployed and then redeployed. -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: GZIP-encoding/mod_gzip and Tomcat??
Ron Andersen wrote: Thanks! I was reading the Wrox's Professional Tomcat book and it states that Tomcat's web servers does not support Virtual Hosts. Does it now support Virtual Hosts? The book is wrong: even Tomcat 4.0 supported vhosts. -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat stats and performances
[EMAIL PROTECTED] wrote: Hi to all, I have two questions. We have Tomcat as server for a struts web application. First, don't crosspost. Thanks. - We need do stats for that web application, stats like what pages user enter, who user enter more to the application, performance stats ... I have seen that one choice is do a manual filter, other choice use awstats. I would appreciate information about that of someone that have experiencia on stats, and he can help me to choose the best choice on time and effort. You should use Tomcat 5 and precompile your web application to do that so that your JSPs are mapped as individual servlets. You can do that using the Tomcat 5 deployer tool. The status servlet will then display statistics for the HTTP connector and the indivudual webapps and servlets. - The second question is about performance, here we have tomcat and when most user enter to the application the server don't reply very well. I have read that is better have APACHE as web server and TOMCAT as server container, is that true? would I improve the performance? or the solution is customize tomcat better?. Tomcat HTTP has lower latency than JK, so you'll get better performance with HTTP unless there are very few requests for dynamic content. Tomcat 5 is also a little bit faster than TC 4.1. However, I think your bottlenecks come from either your application, the database setup you're using, or too little bandwidth (if you have a public site). -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: When is Tomcat 5 Release version scheduled to come out?
Antonio Fiol Bonnín wrote: Hello, I'll begin from the end... I did not present evidence, that is true, but I explained the symptoms. I tested three configurations: 1 Apache + 1 Tomcat;1 Apache + 2 Tomcat;1 Apache + 3 Tomcat All three gave me very similar performance results. Measurement tool was JMeter. Difficult pages were generated faster using three tomcats than using one tomcat, and trivial pages were faster with one tomcat. Probably all this is due to the overhead of replicating the sessions, but I am not sure. We also used Apache AB to test it. We did it against one nearly static JSP page. With low concurrency levels (less than 5), 2 tomcats give more throughput than one. With higher concurency levels (5 or more), 2 tomcats give worse throughput. Probably, again, I think, because of the overhead of creating hundreds of sessions and replicating them. But, again, I am not sure. You don't pretend to win the coveted Whiner Of The Month award with this, I hope. There's a lot of competition, you know. A little more seriously: - JMeter is IMO a bad load testing tool, but it's good at testing latencies. - With your AB test, you are likely creating a session each time, which is basically the worst case for session clustering. - You have to use session stickiness (the Servlet specification requires that operations related to a sigle session be bound to a single VM). - JBoss session clustering is very likely a little more optimized (although it is not currently ported to Tomcat 5; coming soon). You'll get better performance out of this form of clustering only if your webapp does a significant amount of computations. XML stuff is the prime example. If you are mostly DB based, you'll be moving the contention problems to the DB layer. Given the throughtput a single Tomcat 5 with its HTTP connector gives on a decent server, I am surprised you are having problems unless you app is really processing intensive or your expected traffic is really high. -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat 4.1.29 and static content in non Latin (ISO-8895-1) characters
Galbayar wrote:
Hi
I have same problem.
If you change apache httpd.conf file
AddDefaultCharset windows-1251
static data has to be seen Cyrillic. However it is very bad solution:-)
For a real fix, you can apply a patch to the Tomcat code:
Index: Response.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Response.java,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- Response.java 14 Oct 2003 19:21:25 - 1.29
+++ Response.java 11 Nov 2003 20:56:56 - 1.30
@@ -552,9 +552,11 @@
String ret = contentType;
-if (ret != null characterEncoding != null) {
-ret += ;charset=;
-ret += characterEncoding;
+if (ret != null
+ characterEncoding != null
+ !(Constants.DEFAULT_CHARACTER_ENCODING.equals
+ (characterEncoding))) {
+ret = ret + ;charset= + characterEncoding;
}
return ret;
--
x
Rémy Maucherat
Senior Developer Consultant
JBoss Group (Europe) SàRL
x
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Windows 98 me Tomcat 5.0.12
Colin McGuigan wrote: Hello, I wonder if anyone could help me. I have installed Tomcat 5.0.12 on my pc. It uses Microsoft 98 ME, is a PIII 866 and has 384 RAM. I have also installed j2sdk1.4.1_05. When I start Tomcat, the image with Apache Tomcat appears for a second or two and the Tomcat image appears in the task bar at the bottom right of the screen for a second or two also. They both disappear and Tomcat does not run. I have tried changing the port no from 8080. Tomcat does work when I start my computer in safe mode. Does anyone know if there is anything in particular I need to do when installing Tomcat 5.0.12 on a Win 98 me os? I have installed it successfully in work on a Windows 2000 os, so I must have the fundamentals correct. Thanking you in anticipation, If the new .exe wrapper doesn't work (it is supposed to work on 9x, but it hasn't been well tested, AFAIK), you can use the shell scripts as before. -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Settings and Performance
Jonathan Holloway wrote: Dear All, I wonder if anyone could help with the following. I'm currently using Tomcat to host a multiple choice test system. I have between 100 - 200 people logging into tomcat and sitting a test almost simultaneously when instructed to by the test supervisor. Does anybody know what the maximum number of users supported by a single Tomcat server is? I'm running a fairly good server with a dual processor setup and 1Gb of memory. When i get around 100 students logging onto a test some of the connections are refused and the server becomes very slow at handling the requests. I'm running Tomcat 5.0 in an attempt to improve this situation? Is this a better server than 4.1.24? The tomcat settings for server.xml follow, can anybody suggest how to improve the performance of this? Connector port=8080 maxThreads=400 minSpareThreads=200 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=400 debug=0 connectionTimeout=-1 disableUploadTimeout=true / I've set the processors to 2x the number of simultaneous requests I expect (200 at the mo.) starting at 200 threads initially. The accept count is set at 400 so that this number of threads are queued to be serviced by tomcat, I don't want any user to be kicked off so the connection timeout is set to -1. Can anybody suggest anything to improve the performance of this system? There's a pretty good article on the Tomcat website on performance. Did you read it ? Some comments: - yes, TC 5 is faster than 4.1, but this is a maximum throughtput mostly; applications may smooth out differences - don't disable connectionTimeout - minSpareThreads should be lower, and your value is conflicting with maxSpareThreads ... So set minSpareThreads to 50, and maxSpareThreads to 100 - as usual, the connector is not likely the bottleneck; VM settings and database access likely have more impact -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Number of instances with SingleThreadModel
cyril vidal wrote: Hi, These infos are useful but have nothing to deal with my initial question;-)) So, I ask it again, if some people know about THIS subject: is it possible in Tomcat's configuration to specify the number of servlet instances created when this servlet implements the javax.servlet.SingleThreadModel interface. No. The value is 20 instances. There's a constant you can change in the StandardWrapper class, of course, and a parameter could be added in StandardContext to set it. -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issue with Tomcat 4.1.29 default Character Encoding
[EMAIL PROTECTED] wrote: Hi All, We are having an issue with the latest version of Tomcat and how the Content Type header is being set by it now - in particular with PDFs generated by our application. The following is taken straight from the RequestDumperValve: OLD (Tomcat 4.1.24) 2003-11-11 16:11:19 RequestDumperValve[Standalone]: --- 2003-11-11 16:11:19 RequestDumperValve[Standalone]: authType=null 2003-11-11 16:11:19 RequestDumperValve[Standalone]: contentLength=24971 2003-11-11 16:11:19 RequestDumperValve[Standalone]: contentType=application/pdf 2003-11-11 16:11:19 RequestDumperValve[Standalone]: header=Content-Type=application/pdf 2003-11-11 16:11:19 RequestDumperValve[Standalone]: header=Content-Length=24971 2003-11-11 16:11:19 RequestDumperValve[Standalone]:message=null 2003-11-11 16:11:19 RequestDumperValve[Standalone]: remoteUser=null 2003-11-11 16:11:19 RequestDumperValve[Standalone]: status=200 2003-11-11 16:11:19 RequestDumperValve[Standalone]: === NEW (Tomcat 4.1.29) 2003-11-11 16:07:08 RequestDumperValve[Standalone]: --- 2003-11-11 16:07:08 RequestDumperValve[Standalone]: authType=null 2003-11-11 16:07:08 RequestDumperValve[Standalone]: contentLength=24971 2003-11-11 16:07:08 RequestDumperValve[Standalone]: contentType=application/pdf;charset=ISO-8859-1 2003-11-11 16:07:08 RequestDumperValve[Standalone]: header=Content-Type=application/pdf;charset=ISO-8859-1 2003-11-11 16:07:08 RequestDumperValve[Standalone]: header=Content-Length=24971 2003-11-11 16:07:08 RequestDumperValve[Standalone]: header=Date=Tue, 11 Nov 2003 21:07:08 GMT 2003-11-11 16:07:08 RequestDumperValve[Standalone]: header=Server=Apache-Coyote/1.1 2003-11-11 16:07:08 RequestDumperValve[Standalone]:message=null 2003-11-11 16:07:08 RequestDumperValve[Standalone]: remoteUser=null 2003-11-11 16:07:08 RequestDumperValve[Standalone]: status=200 2003-11-11 16:07:08 RequestDumperValve[Standalone]: === Obviously the change is now that the charset has been appended to the Content-Type header. This is causing a problem with IE browsers (tested on the latest 6.0 and also on 5) in that it is no longer activating the Acrobat Reader to display the file - it is instead bringing up an 'Open/Save' dialog box as if it did not recognize the Mime type - though the Type of the document is recognized as 'Adobe Acrobat' in the dialog box. I have done some searching in the documentation and in the Tomcat source on how we can disable the charset being appended - but to no avail so far (I know we can change the character encoding in the wrapper implementation of Response, but at that point in the code we only have access to the HttpServletResponse object - which does not have the corresponding setCharacterEncoding method) Am I missing something? Is there a way to set the Character Encoding in the configuration files? We are using Struts also - which I know has a 'default content type' parameter that can be set - but Im not sure this will help us in this circumstance! This issue has been correctled already. However, I'd like to point out that ISO-8859-1 is the default in HTTP/1.1 for the entity body, so the two should be equivalent. To fix the issue, you need to get a new org.apache.coyote.Response class compiled from CVS and put it in server/classes. -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: java.util.zip.ZipException while using the ant install target
Rainer Stransky wrote: On Sunday 09 November 2003 23:53, Rainer Hoeckmann wrote: I found that my build.xml was using the deployTask instead of installTask to implement the ant install command. After changing this it went possible to install my application to Tomcat. Now I'm wondering where the difference is between deployTask and the (not documented) installTask? I posted the same problem some days ago. But there was no response yet. I tried your solution but in my enviroment: - Tomcat/5.0.12 - Ant/1.6beta2 - java/1.4.0_03-b04 - OS/Linux-2.4.19-4GB Some comments: - Since Tomcat 5 is in beta, you should update regularly, as there's a significant bugfix activity (which has been slowing down after 5.0.14) - I only test with Ant 1.5.x for now - The install task is deprecated, and I recommend you use deploy instead - If you want a ready to use package to precompile and deploy webapps, look at the Tomcat 5 deployer (which is completely optional, of course) - I think the Ant tasks are quite well documented (see the Tomcat 5 manager and deployer documentation) So i tried your suggestion, and replaced 'deloy' with 'install' as task in the install target. But the 'install' target is not known by my ant. Neither deploy nor install is part of the ant core or optional task, i guess they are implemented in catalina-ant.jar which i copied to $ANT_HOME/lib A look into the jar gives the indication that there are custom tasks org/apache/catalina/ant/DeployTask.class org/apache/catalina/ant/InstallTask.class -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.14: error in opening zip file
Gerry Reno wrote: Don't know whether this has any bearing on the problem but the war file was built and deployed using maven. - First, make sure you have a $CATALINA_HOME/temp or $CATALINA_BASE/temp folder - Please post your full stack trace, it may be useful - How can this problem be reproduced ? -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HTTP response header displayed for JSP
Howard Lin wrote: When trying to fetch a simple JSP page, the following header displayed on the browser (IE 6.0 on WinXP): HTTP/1.1 200 OK Content-Type: text/plain;charset=ISO-8859-1 Content-Length: 2183 Date: Wed, 05 Nov 2003 19:42:16 GMT Server: Apache Tomcat/4.1.29-LE-jdk14 (HTTP/1.1 Connector) After click the refresh button, the text displayed correctly. But if I click the refresh button again, the above header displayed again. I searched the archive and google and couldn't find anything useful. I also changed some cookie settings in IE and that didn't fix either. The tomcat server is running standalone on a Linux RedHat 9.0 box with j2sdk 1.4.2. I don't know about this issue, but you're using a deprecated HTTP connector. Try the default one. -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Installing jakarta on linux RH9
Christopher Schultz wrote: All, The newest version (4.1.29) should be fine. If I recall, however, there was a problem with Sun's Java Virtual Machine, and RH9, which used an incompatible threading library. No, on RH 9, all VMs will actually need the LD_ASSUME_KERNEL env variable (look in the archives for the details on the problems and the workaround). Is this accurate? I use RH9 with kernel 2.4.20/i686, JDK 1.4.2-b28 without any LD_ASSUME_KERNEL setting (that I know of). Is this for a specific kernel version or architecture? The problems are with the HTTP/1.1 connector (it dies after about one day, regardless of the load). Also, there has been a GLIBC update which could have fixed the issue, so if you keep your system fully patched, you could be ok. -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Installing jakarta on linux RH9
Nathan Mcminn wrote: The newest version (4.1.29) should be fine. If I recall, however, there was a problem with Sun's Java Virtual Machine, and RH9, which used an incompatible threading library. No, on RH 9, all VMs will actually need the LD_ASSUME_KERNEL env variable (look in the archives for the details on the problems and the workaround). -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.14 Beta
Matt Raible wrote: I just upgraded from Tomcat 5.0.12 Beta to 5.0.14 yesterday. Everything's been running fine for the last 12 hours, and then I got the following error this morning: No Java compiler was found to compile the generated source for the JSP. This can usually be solved by copying manually $JAVA_HOME/lib/tools.jar from the JDK to the common/lib directory of the Tomcat server, followed by a Tomcat restart. If using an alternate Java compiler, please check its installation and access path. Should I copy tool.jar to common/lib? I've never had to do this before. Maybe not. This message may appear more often that what it should, when there's a compilation error. It should be investigated. You didn't give enough information to go much further. -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Apache Tomcat 4.1.29 Stable and Apache Tomcat 5.0.14 Beta released
Vic Cekvenich wrote: I speak for many: THANK YOU You're welcome :) Hopefully 4.1.29 will be a good release. -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Apache Tomcat 4.1.29 Stable and Apache Tomcat 5.0.14 Beta released
The Tomcat Team announces the immediate availability of Apache Tomcat 4.1.29 Stable and Apache Tomcat 5.0.14 Beta. Please refer to the changelog for the list of changes. Downloads: Binaries: http://jakarta.apache.org/site/binindex.cgi Sources: http://jakarta.apache.org/site/sourceindex.cgi The Apache Tomcat Team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5 JBoss
[EMAIL PROTECTED] wrote: Is there any way to run JBoss with Tomcat 5 instead of 4.1.27? I'm using JBoss 3.2.2. I would like to switch to 5 because of the hotswap debugging feature. You have to get the source, and build. There will be a TC 5 SAR in the output dir for the Tomcat module. Using it is not straightforward, though: - you have to replace the servlet JSP API JARs in lib - you should add commons-logging to your system classpath to avoid problems -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat stops handling HTTP connections, socket is SYN_RECV
[EMAIL PROTECTED] wrote: On Fri, Oct 24, 2003 at 16:01:48 +0200, [EMAIL PROTECTED] wrote: When everything quiets down, tomcat seems to be unable to service any http requests. Any attempt to connect to port 10003 with a web browser eventually causes a No data in response-style error message. At this point it seems the http connector listening on port 10003 has gone zombie on me: I've figured out what's going wrong. The following exception is printed once on standard out when things fail: java.lang.OutOfMemoryError: unable to create new native thread at java.lang.Thread.start(Native Method) at org.apache.catalina.connector.http.HttpProcessor.threadStart(HttpProcessor.java:1178) at org.apache.catalina.connector.http.HttpProcessor.start(HttpProcessor.java:1262) at org.apache.catalina.connector.http.HttpConnector.newProcessor(HttpConnector.java:937) at org.apache.catalina.connector.http.HttpConnector.createProcessor(HttpConnector.java:868) at org.apache.catalina.connector.http.HttpConnector.run(HttpConnector.java:1075) I looked into the source for HttpProcessor briefly; perhaps the thread.start() on line 1178 or the threadStart() call on line 1262 could be surrounded with a try/catch(OutOfMemoryError), and throw a LifecycleException? Any reason for using this connector ? It's deprecated. BTW, once there's an OOM exception, the VM is in an unpredictable state, and must be restarted. -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IMP:Problem migrating to Latest Tomcat 5
Paresh Varatkar wrote: Hi Remy Two questions 1 where Can I get the binary install for 5.0.14. http://mir2.ovh.net/ftp.apache.org/dist/jakarta/tomcat-5/v5.0.14-alpha/ (or another mirror) 2 Also do you think its possible to move the application from Tomcat to jboss easily. That's the idea :) The JB 3.2 / TC 5 integration should be released soon (likely a little after the stable TC 5 release). It needs some more tweaking, right now. -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IMP:Problem migrating to Latest Tomcat 5
Paresh Varatkar wrote: Found out thwe problem. One of our class is making hard coded refernce to resources that is creating trouble in deploying the application. One more problem though. I am trying to start Tomcat as service. It starts and stops immediately saying The apache service on computer started then stopped some services stop automatically if they have no work to do has anyone came across this. That bug has been fixed already, and 5.0.14 will have the fix. Sorry Chris, I am putting files under webapps\WEB-INF\ourapp\lib directory. No, it's webapps\ourapp\WEB-INF\lib -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: embedded tomcat 5
Mark W. Webb wrote: could you please give more information on the JMX way. thanks http://apache.crihan.fr/dist/jakarta/tomcat-5/v5.0.12-beta/bin/jakarta-tomcat-5.0.12-embed.tar.gz -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat jitters, then hangs - please help
Noam Camiel wrote: Hi folks, A week's gone by and all seems fine. Server is stable and working properly. Thanks for all who helped out! Ryan, Remi Yoav and Arthur, many thanks. It may be a good idea to document this for others who may stumble over this problem. All the best Noam Camiel Details: Problem: Tomcat Server becomes unresponsive to new requests after several hours, regardless of load. OS RH9; Tomcat 4 or 5; VM Sun or IBM (JDK 1.4) Solve: (tcsh): setenv LD_ASSUME_KERNEL 2.2.5 Thanks :) Very good news :) I think I'll need to add that in the release notes (and putting it in the FAQ would be good as well). Very weird symptoms, though. The only explanation for the bug is if the thread waiting on the socket just vanishes (there's no way it can go out of the blocking accept loop otherwise - I reviewed that quite extensively ;-)). Q: would the assume kernel 2.4 work as well ? I believe it would, but it could be worth confirming it eventually. This is not critical, obviously. -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat4 denial of service in debian...
Dan K. wrote: Yoav, So then if there is a DoS vulnerability in the normal jakarata tomcat 4.0.x distributions, would the developers consider that important enough to be looked at/fixed? I'm just trying to figure out whether the vulnerability in the debian tomcat would affect the normal jakarta tomcat versions = 4.0.4 (i'm using the normal jakarta distributed tomcat 4.0.6). Upgrading to the 4.1 branch would require more work for us. :( Let's say it would be looked at on a case by case basis. This one would probably not be fixed as I believe mush less people used TC 4.0.x standalone in production on public servers rather than with mod_jk or mod_webapp. More details on the exploit would be needed. -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC5 ssl form-based authentication mozilla
Adam Hardy wrote: I have set this up with the minimum configuration possible to try to find the problem. 1 JSP, one Struts action mapping, 1 servlet mapping, and the tomcat realm - no SSO, no filters, no templates, no SSL-redirection. With this security: web-resource-collection web-resource-nameSSL 4 Login/web-resource-name url-pattern/login.do/url-pattern /web-resource-collection auth-constraint role-nameuser/role-name role-nameadmin/role-name /auth-constraint user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint when I try to login to my login.do mapping, in mozilla I get repeated login requests from tomcat. The first time twice only, the 2nd time 5 times, 3rd time 10 times etc etc. I can see from my logging that the realm login is successful, but tomcat keeps giving the login page as stated. This does not happen in IE6 or lynx, in which the login works as normal. Has anybody else experienced this? Did you get correctly switched to SSL mode ? -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat jitters, then hangs - please help
Shapira, Yoav wrote: Howdy, Cool, please keep us updated ;) I want these linux questions better documented in the list archives ;) Given that RH 9 / HTTP/1.1 seems a fairly common configuration, this should be added to the known issues and the FAQ if confirmed. Since there are three options, I wonder how the 2.4 compat mode works out. I assume Noam played it safe, and chose 2.2 compat mode for his testing just in case ;-) I assume it would work as well as 2.2 compat, since there weren't any major problems before (again, to be confirmed; since the performance difference is likely not very significant, it's better to get stability in this case :)). -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Strange tomcat behavior
[EMAIL PROTECTED] wrote:
Hi everybody on the list!
We observed a strange tomcat behavior (tomcat 4.1.24) while running a servlet: Everything works fine some days or even weeks. Suddenly (and at random time) tomcat throws the following exceptions:
2003-10-08 11:44:48 CoyoteAdapter An exception or error occurred in the container
during the request processing
java.lang.NullPointerException
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:164)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:594)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:392)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619)
at java.lang.Thread.run(Thread.java:484)
This exception occurs some times. Suddenly tomcat throws another exception:
2003-10-08 11:46:44 CoyoteAdapter An exception or error occurred in the container
during the request processing
java.lang.NullPointerException
at java.lang.String.charAt(String.java:509)
at org.apache.tomcat.util.buf.ByteChunk.indexOf(ByteChunk.java:669)
at org.apache.coyote.tomcat4.CoyoteAdapter.normalize(CoyoteAdapter.java:578)
at
org.apache.coyote.tomcat4.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:280)
at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:221)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:594)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:392)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619)
at java.lang.Thread.run(Thread.java:484)
Note that there are no user defined classes in the stacktrace. What's the reason of this behavior?
The second one was weirder, so I looked into it:
For the TC 4.1.24 source:
CoyoteAdapter.java:578: index = uriBC.indexOf(/../, 0, 4, index);
For reference: ByteChunk.java:668: public int indexOf( String src, int
srcOff, int srcLen, int myOff ) {
ByteChunk.java:669: char first=src.charAt( srcOff );
If you get a NPE inside charAt on a constant String, I think it means
your VM has issues.
For the first one, the engine associated with the engine valve is null,
which can't happen either, but I can't demonstrate as easily that it's
not a Tomcat bug.
--
x
Rémy Maucherat
Senior Developer Consultant
JBoss Group (Europe) SàRL
x
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat jitters, then hangs - please help
Arthur Veinstein wrote: Noam, I suspect that the tomcat doesn't hangs but rather you reach the max TCP connection that your server accepts. The best will be to write a small program you run by calling a servlet which write to the output I'm a live every 10 min. Run the program after you restart the server and wait till your problem occurs, then if you see that the output string keep coming then the tomcat isn't dead just your server rejects tcp connection. I think it could be a good idea to include that kind of servlet as part of the manager webapp. Even if we manage to isolate and fix that bug, it won't solve all the other possible stability issues (VM crash, OOM), so admins could find this useful. -- x Re'my Maucherat Senior Developer Consultant JBoss Group (Europe) Sa`RL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat jitters, then hangs - please help
Noam Camiel wrote: On Thursday, October 09, 2003 5:11 PM Ryan Lissack [EMAIL PROTECTED] wrote: Hi Noam, We have experienced similar problems. You will notice in the thread dump that there is no thread from the connectors thread pool waiting on an accept I see your what you mean, I compared the thread dump to a good dump when the server is operational and there indeed I found a thread from the connectors thread pool waiting on accept: 3XMTHREADINFO http80-Processor24 (TID:0x100688E0, sys_thread_t:0x87810C0, state:R, native ID:0x41CCCF40) prio=5 4XESTACKTRACE at java.net.PlainSocketImpl.socketAccept(Native Method) This does not appear to exist in the bad dump. It is very surprising that the connector will manage to exit the accept loop without logging some kind of error (which would be in catalina.out, rather than in the main logs). Do you see some stack trace originating from the PoolTcpEndpoint or ThreadPool classes ? What OS are you on, RH9?? Yes, Im on RH9. Any ideas why this could happen? could it be some system resource limit? Is your application an intensive app? My application is not an intensive one and the hangs occur hours after i start the server (usually a day later). No idea at this point. Most (all) such reports were for RH 9. All also mention a period of about a day before an incident. -- x Re'my Maucherat Senior Developer Consultant JBoss Group (Europe) Sa`RL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.12, Windows, and file pathnames
Derek Mahar wrote: Is it the responsibility of Tomcat, the application running on Tomcat, or Java to translate or resolve Windows file paths? If it is Tomcat, does Tomcat 5.0.12 translate or resolve these pathnames correctly? VQWiki (http://www.croninsolutions.com/veryquickwiki/), a JSP Wiki engine, when run on Tomcat 5.0.9 on Linux, works as expected. However, on Tomcat 5.0.12 on Windows XP, VQWiki is unable to find and save its property file, even though this file exists and is both readable and writable. VQWiki generates the following report page: The error had the following message:C:\Program%20Files\Apache%20Software%20Foundation\Tomcat%205.0\w ebapps\vqwiki\WEB-INF\classes\vqwiki.properties (The system cannot find the path specified) The only way you can get a properly URL encoded URL is when you call getResource on the classloader. If you do a diff, you'll see there's no relevant changes that have been made to the classloader between 5.0.9 and 5.0.12. The most likely cause is that you don't have spaces in your Tomcat path on Linux, but you do on Windows. Note: The URL encoding of those paths is a feature which could be removed (it is supposed to fix problems with RMI). -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.12, Windows, and file pathnames
Derek Mahar wrote: Yes, the Linux Tomcat installation has no spaces in its installation path (/usr/local/jakarta-tomcat-5.0.9), but the Windows Tomcat installation path does (C:\Program Files\Apache Software Foundation\Tomcat 5.0). Why cannot Tomcat on Windows handle these spaces? Is URL pathname encoding a Tomcat or Java feature? Wherever this feature exists, I hope it is soon eliminated or corrected. Well, the problem is the JDK doesn't handle properly URL encoding. So there are obscure bugs sometimes. With TC 5, the idea was to properly encode URLs returned by the classloader, since this is the correct way to do stuff (otherwise, they are just invalid URLs). -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat hanging!! About to change container!! Please help!!
David Rees wrote: On Fri, October 3, 2003 at 1:02 pm, Remy Maucherat sent the following Interesting stuff about the logger. Anyway, in the dump, there's, as usual, only one connector listening on its server socket. And, as usual, it is Sun JDK 1.4.1 or 1.4.2 on Linux. I think there are way too many coincidences in these reports. I wonder what's the market share is today on Linux, but I don't even remember the last time I heard about stability issues with the IBM JDK. It's also interesting that it seems that a number of these reports are coming from Redhat 9 machines. I would confirm that the machine is running all the latest errata updates from Redhat (especially the glibc updates which have a number of thread fixes) and at the same time also upgrade to the latest 1.4.2 JDK from Sun (build 1.4.2_01-b06) if he doesn't want to try the latest from IBM. RH 9 had NGPT, and I read that most Sun VMs weren't supported under it, and the latest JDK 1.4.x was needed (whatever it is). I also read that IBM 1.4.1 was ok (although I think only 1.4.0 is available :-D). So, basically, I'm confused :) Indeed, I have noticed that these bugs with the connector all occurred on Linux 2.4 (usually, people don't mention the distro they are using, only the kernel version) + Sun JDK 1.4.1 or 1.4.2. If there's a clear confirmation of this, a recommendation not to use Sun JDKs on Linux would be added in the release notes. -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat hanging!! About to change container!! Please help!!
David Rees wrote: On Sun, October 5, 2003 1at 2:44 am, Remy Maucherat sent the following If there's a clear confirmation of this, a recommendation not to use Sun JDKs on Linux would be added in the release notes. I can't say I agree with this as I have about half a dozen machines running Tomcat on a Linux 2.4 kernel along with various Sun JDKs, and I have never experienced a JVM hang in the past year. However, none of these machines are running anything later than RedHat 7.3, a few are running Debian. All are running various almost vanilla 2.4 kernels since the 2.4.14 release. All now are running 2.4.20 or higher. If anything, instead of recommending to stay away from Linux and Sun JDK combos, I would simply add it as a comment or FAQ until there is hard documented evidence of a specific combination which causes problems. Yes, not much is known right now, and nothing will be documented until there's a decent proof on which configurations are a problem. I think it will only occur with the standlone HTTP/1.1 connector (JK stresses the thread pool, and more importantly the network stack of the JVM a lot less). Also, there are hints it can be linked to the recent Redhats (ie, not 7.3). Feel free to add useful comments to this :) (the symptoms are the connector stopping to function after about 1 day, regardless of the server load level - a stack dump will reveal all the threads are idle waiting at the right spot, but no thread listening on the server socket) -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Expected date for 4.1.28?
Shapira, Yoav wrote: Howdy, Also keep in mind that 4.1.28, like any other release, could have regression bugs ;) You'd have to test on it anyhow before going to production and finishing documentation. Unless you really need a fix from 4.1.27, you could just stick to 4.1.24 without a hotfix. Yes, since we're switching to the Tomcat 5.0 connectors, there could be regressions, although this is mostly a collection of small tweaks rather than a big rewrite ;-) As part of the switch, Tomcat 4.1.28 will require JMX and commons-modeler 1.1 to run. -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat hanging!! About to change container!! Please help!!
Shapira, Yoav wrote: Howdy, Oh, interesting... Thread-2 daemon prio=1 tid=0x084201a0 nid=0x223b waiting on condition [4e08..4e080714] at java.io.PrintWriter.print(PrintWriter.java:375) at java.io.PrintWriter.println(PrintWriter.java:515) - locked 0x44a33ae0 (a java.io.FileWriter) at org.apache.catalina.logger.FileLogger.log(FileLogger.java:293) I saw the above and the StandardHost thread stuck on PrintWriter.print. I wonder if that's OK. Maybe there's a problem with rotating the log files? Or disk space? Or file descriptors (ulimit on unix)? I would still try it without the JDBC Realm. Interesting stuff about the logger. Anyway, in the dump, there's, as usual, only one connector listening on its server socket. And, as usual, it is Sun JDK 1.4.1 or 1.4.2 on Linux. I think there are way too many coincidences in these reports. I wonder what's the market share is today on Linux, but I don't even remember the last time I heard about stability issues with the IBM JDK. -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat jitters, then hangs - please help
Shapira, Yoav wrote: Howdy, At that time, if you send the VM a SIGQUIT, what are the threads doing? I've got a thread dump at the end of the file. Please have a look and tell me if you see something odd. It seems you also have a JK connector setup: let's try to reduce the variables by running tomcat standalone with only one Coyote connector. Disable the JK/JK2/whatever connectors to Apache, especially if you're not using them anyways. Other than that, nothing unusual jumped at me from the stack trace. I have to give him some credit: there's only one connector listening on a server socket. All the threads for the HTTP connector are busy doing nothing. Now, could a better explanation of how to get in this situation be given ? -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cannot compile jsps with tomcat 5
teknokrat wrote: I just tried running my webapp with the latest release of tomcat 5 (5.0.12). Added my context to bin/catalina/localhost and changed CATALINA_HOME. The app loads fine but it refuses to compile any of the jsps. This could be a struts/tiles issue. The sample jsp/servlet examples work fine. here is the exception i keep getting ApplicationDispatcher[/lab] Servlet.service() for servlet jsp threw exception org.apache.jasper.JasperException: Unable to compile class for JSP - Make sure you have the right Jasper and API JARs in common/lib. - Clear your work dir. - Try again. If it still doesn't work, you'll have to post a test case (the tiles example from the Struts distribution works fine for me with the latest Tomcat 5 code). -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: running tomcat on port 443 as non-root
Damian Egli wrote: Hello I have to run Tomcat standalone as user e.g tomcat (non-root) on port 443. But the server doesn't start (not able to bind port 443). With 8443 everything works fine. Why can't tomcat do that like apache ? Because Java wasn't designed to allow that. There are solutions which are being worked on, such as the commons-daemon project. Tomcat 5 is designed to take advantage of commons-daemon, so it allows running a low port without root. See the docs: http://jakarta.apache.org/tomcat/tomcat-5.0-doc/setup.html Thanks for hints or help. I'm running Version 4.1.27 on SuSE 8.2 with SUN Java 2 Standard Edition (build 1.4.1_02-b06) -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using Digester in a Tomcat project causes server not to start ?
Kruse, Matt wrote: What tomcat version? I've tried 4.1.27 and 5.0.9 with the same results. Where's the digester jar that ships with tomcat? c:\tomcat\server\lib\commons-digester.jar You can't have more than one digest jar in the classloader hierarchy. So keep yours in WEB-INF/lib and make sure tomcat's is in $CATALINA_HOME/server/lib (not commons/lib or shared/lib). I do have a copy of the jar file in my project's WEB-INF\lib directory. That is what is causing the problem. If I take the jar file out of that directory, the server starts up fine, but my project won't run because it can't find the Digester class. If I directly reference the commons-digester.jar in the path above, my project will compile just fine, but Tomcat once again files to startup. This works fine for me. It is very obvious: just try one example Struts WAR (which has commons-digester.jar), and it will work fine. -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Apache Tomcat 5.0.12 Beta released
The Tomcat Team announces the immediate availability of Apache Tomcat 5.0.12 Beta. Tomcat 5.0 contains many enhancements over Tomcat 4.1, including: * Performance optimizations and reduced garbage collection * Refactored application deployer, with an optional standalone deployer allowing validation and compilation of a web application before putting it in production * Complete server monitoring using JMX and the manager web application * Scalability and reliability enhancements * Improved Taglibs handling, including advanced pooling and tag plugins * Improved platform integration, with native Windows and Unix wrappers * Embedding of Tomcat using JMX * Enhanced Security Manager support * Integrated session clustering * Expanded documentation Apache Tomcat 5.0.12 is a beta release, and contains the following known issues: * Possible crash of the Windows .exe wrapper when attempting to view its console (which can be done by double clicking on the tray icon). This will be addressed in the next release. Downloads: Binaries: http://jakarta.apache.org/site/binindex.cgi Sources: http://jakarta.apache.org/site/sourceindex.cgi The Apache Tomcat Team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DefaultServlet throws a LOT of broken pipe exceptions on mp3s
Chris Rolfe wrote: That's what I thought at first, but this happens 80-90% of the time on the 100k+ files. There are two files on the same page, one 100-200k dialog, and a 10-30k sentence. It seems to me unlikely the users are hitting stop that quickly and that often. These are reasonably fast university connections in a class setting. Could it be another request hitting the server? Mishandling of partial GETs? Related, the catalina Logger doesn't seem to take Filters (or am I missing something?). I'd like to keep this cruft (in the meantime) out of the log. I had tested the partial GET with stuff like GetRight and WinAMP (and telnet, obviously). I believe the feature works fine. This exception can only occur on a client disconnect, so the only way it could happen is if too many bytes are written (which, I belive, works fine). BTW, if you run a fileserver on Tomcat (unusal, and not the most efficient server for that use, but it works), then I think you should try 5.0.x, such as 5.0.9 or 5.0.12. -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Coyote Performance
David Morris wrote: I did some profiling of a slow page (Struts based) on a site using the Coyote connector. This site does not use Apache. It appeared that a java.net.SocketInputStream.read being invoked from org.apache.coyote.http11.InternalInputBuffer.parseRequestLine() was causing a bottleneck. In this case average response over a 5 page interaction with three being relatively simple and two being complex averaged 35 seconds per response when repeated 20 times. I changed the site to use the old and deprecated http connector and performance improved to 4 seconds per response. It appears that the org.apache.catalina.connector.http.SocketInputStream was much faster. Since Coyote is recommended, does anyone have any ideas on how I can get it to perform better? Over dozens of tests, it appears that large pages take a long time with the Coyote connector. You are of course free to use whatever you want, but I believe you are completely wrong ;-) -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Coyote Performance
Mike Curwen wrote: In exactly what manner was David completely wrong? In his identification of the bottleneck? In identifying the old connector as faster? Or is there a fundamental mistake in his whole post? Well, the different is so huge, it is not consistent at all with any measurement I've seen. So the most likely is an obvious mistake somewhere. Simple logic :) -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat, MySQL JNDI: java.sql.SQLException: Cannot load JDBC driver class 'null'
Ilja Hehenkamp wrote:
I think I know where lies the problem, however I still don't know how to
fix it...
I use the sample build.xml file from Tomcat:
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/appdev/build.xml.txt to
install, reload and distribute my sample application.
When I do an ant -install it apparantly installs the application in the
Tomcat manager, however the application doesn't show up in the webapps
directory. That's 1.
So maybe there's a conflict with either the context path, which I don't
think so, since my build file has explicitly set the context path to
/DBTest:
property name=app.name value=DBTest/
property name=app.path value=/${app.name}/
property name=app.version value=/
property name=build.homevalue=${basedir}/build/
property name=catalina.home value=/Library/Tomcat/ !-- UPDATE
THIS! --
property name=dist.home value=${basedir}/dist/
property name=docs.home value=${basedir}/docs/
property name=manager.url value=http://localhost:8080/manager/
property name=src.home value=${basedir}/src/
property name=web.home value=${basedir}/web/
Or there's a conflict with the docbase, which I suspect... However I'm
not sure why and how to fix it
Because when I put the generated war file (when doing an ant -dist) in
the webapps directory the connection works! Although this works, it's
not very convenient, since it defeats the purpose of the automated
installing through ant...
Hope I made myself clear?
That's much better.
I recommend you use the deployer package instead. The instructions from
appdev are going to be updated or removed.
--
x
Rémy Maucherat
Senior Developer Consultant
JBoss Group (Europe) SàRL
x
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat, MySQL JNDI: java.sql.SQLException: Cannot load JDBC driver class 'null'
Ilja Hehenkamp wrote: Sorry, I don't really understand what you mean? Do you mean I shouldn't use the build file anymore? If so: that's too bad, since I like the way of automated updating the tomcat manager... I'm sure you do. You seem to be stuck on that particular page of the docs, however, which happens to be out of date, and doesn't actually mention what is important. Read the deployer page instead (http://jakarta.apache.org/tomcat/tomcat-5.0-doc/deployer-howto.html). But still: I don't know how to fix the problem: why doesn't the jndi datasource work with the through ant deployed application? Because I don't think your stuff in server.xml is used at all. -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 4.1 - 5.0 Web-app Porting
[EMAIL PROTECTED] wrote: I'm using Tomcat 5.0.11. I still don't understand how this works with Tomcat 4.1 and not 5.0. I thought 5.0 was backwards compatible. Besides, struts' tags are very popular (htmlbean etc.). If 5.0 were somehow not compatible with these tags, we would hear more complaints from this forum. I am tilting towards believing that I am, most probably, facing a configuration/settings problem. Any suggestions? The only way to get a NPE where you're getting it is if the tag pool is null. It will only happen if _jspInit is not properly called, basically (the code should be easy to read). So I doubt your JSP is a plain clean JSP ;-) BTW, I developed and tested a rather big Struts webapp using TC 5 without any problems. -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 4.1 - 5.0 Web-app Porting
[EMAIL PROTECTED] wrote: Here's my entire index.jsp. What would you change to make it work with Tomcat 5.0? It seems to works fine with 4.1. Yes, I'm sure it does work fine with 4.1. Coincidentally, it also works fine for me in 5.0. It works for me with both pooling enabled and disabled (you can verify using the Struts example webapp). -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[5.0.12] New alpha build
A new alpha test build has been released. The most important changes are fixes and improvements in the HTTP connector. Please test it. Downloads: http://jakarta.apache.org/site/binindex.cgi Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5 clustering
Filip Hanik wrote: for software, balance.sourceforge.net is excellent There are no docs at all, but I was wondering about that project. Does it do session affinity ? Can you give more details since you've been using it ? -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.9 appBase and docBase questions...
Richard Norman wrote: I have a question and I have looked all through the documentation and have not found the solution. Firstly I wanted to know if there is a source to go to about using Tomcat 5.0.9 with IIS on Windows. Particularly the JK2 connector and ISAPI connector? If not, then is there some sore of direction I can be given to test out this new version? Secondly, is there some parts of the configuration not working properly for Tomcat 5.0.9? I am able to set the appBase of a Host properly, however whenever I try to set a context with a different drive for the docBase, or try to have the admin.xml and manager.xml files configure their context, I get the following error... Again, here is my Host command in server.xml * Host name=localhost debug=4 appBase=e:/inetpub/wwwroot unpackWARs=true autoDeploy=true reloadable=true And my Admin.xml is as follows * Context path=/admin docBase=c:/Tomcat/Tomcat-5.0/server/webapps/admin debug=4 privileged=true Logger className=org.apache.catalina.logger.FileLogger prefix=localhost_admin_log. suffix=.txt timestamp=true/ /Context * The error I receive is this (long entry)... * Sep 8, 2003 5:01:48 PM org.apache.catalina.core.StandardHostDeployer install INFO: Processing Context configuration file URL file:C:\Tomcat\Tomcat-5.0\conf\Catalina\localhost\admin.xml Sep 8, 2003 5:01:48 PM org.apache.commons.digester.Digester startElement SEVERE: Begin event threw exception java.io.IOException: The filename, directory name, or volume label syntax is incorrect at java.io.WinNTFileSystem.canonicalize0(Native Method) at java.io.Win32FileSystem.canonicalize(Unknown Source) at java.io.File.getCanonicalPath(Unknown Source) at java.io.File.getCanonicalFile(Unknown Source) at org.apache.catalina.startup.SetDocBaseRule.begin(SetDocBaseRule.java:137) at org.apache.commons.digester.Rule.begin(Rule.java:200) at org.apache.commons.digester.Digester.startElement(Digester.java:1273) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.impl.dtd.XMLDTDValidator.startElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentScannerImpl$ContentDispatcher.scanRootElementHook(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.commons.digester.Digester.parse(Digester.java:1567) at org.apache.catalina.core.StandardHostDeployer.install(StandardHostDeployer.java:515) at org.apache.catalina.core.StandardHost.install(StandardHost.java:866) at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:529) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:474) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1008) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:399) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1135) at org.apache.catalina.core.StandardHost.start(StandardHost.java:792) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1127) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:502) at org.apache.catalina.core.StandardService.start(StandardService.java:519) at org.apache.catalina.core.StandardServer.start(StandardServer.java:2311) at org.apache.catalina.startup.Catalina.start(Catalina.java:578) 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:297) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:394) Sep 8, 2003 5:01:48 PM org.apache.catalina.startup.HostConfig deployDescriptors SEVERE: Error deploying configuration descriptor admin.xml java.io.IOException: java.io.IOException: The filename, directory name, or volume label syntax is incorrect at org.apache.catalina.core.StandardHostDeployer.install(StandardHostDeployer.java:521) at
Re: Tomcat 5.0.9 appBase and docBase questions...
Richard Norman wrote: Thanks for the timely response.. I've been scratching my head over this for the past day and a half thinking I am just not getting this right. Are there any other active gotcha's I need to watch out for? I am using this for testing and some getting my feet wet work in JSP 2.0. There are no known issues right now in 5.0.11. By the way, is there any further documentation on the JK2 interface for IIS? Not at the moment. The native connectors are released as a separate project, since they are so diverse, so there's separate documentation. I am curious to see if there have been any improvements in speed or manageability since Tomcat 4 was updated. The Catalina pipeline has been optimized, which benefits both JK and HTTP/1.1. The connectors themselves didn't need any additional optimization over 4.1.x. There have been additional performance optimizations in various places (optional thread local thread pools, static resource serving, request dispatcher). Monitoring features and runtime statistics have been added (see the manager webapp). -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5 clustering
Cendil wrote: I am trying to get clustering working with Tomcat 5.0.9 and am finding a few problems. I have uncommented the cluster section and the recommended valve to filter requests for static content, so the cluster section in the host section of server.xml looks like this: Cluster className=org.apache.catalina.cluster.tcp.SimpleTcpCluster name=TestCluster debug=10 serviceclass=org.apache.catalina.cluster.mcast.McastService mcastAddr=228.0.0.4 mcastPort=45564 mcastFrequency=500 mcastDropTime=3000 tcpThreadCount=2 tcpListenAddress=auto tcpListenPort=4001 tcpSelectorTimeout=100 printToScreen=false expireSessionsOnShutdown=false useDirtyFlag=true replicationMode=synchronous / And I have changed the listen port in the second member to be 4002. On start-up, the following INFOs appear in catalina.out: [InMemoryReplicationManager] Starting clustering manager...:/reptest [InMemoryReplicationManager] Starting... no cluster associated with this context:/reptest I am testing using the SessionExample servlet that ships with tomcat. Both members join the cluster and data is replicated. However, when data is received, the following WARNING is logged in the receiving cluster member and the session is not replicated properly: org.apache.catalina.cluster.tcp.SimpleTcpCluster messageDataReceived WARNING: Context manager doesn't exist:/reptest Any ideas on how to solve this? This is mostly a cosmetic issue. You should set distributable=true on your Context elements. This should be cleaner, and will be improved in future releases. BTW, that clustering support is brand new code, and hasn't been tested well. You can report bugs as usual (use the Catalina:Cluster category). -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5 clustering
Cendil wrote: Setting distributable=true on the Context element in server.xml didn't work, but I noticed I had missed out the distributable element in the web.xml. Added is, and all works fine. Sorry, the code had changed since last time I did anything for that feature (maybe 6 months ago). Anyway, it would be interesting to hear if this feature works well enough in the real world. -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5 clustering
Jan Agermose wrote: I'm not using version 5 but was looking for information on what clustering capabilities that where build into tomcat 5 - but I cannot find anything on the webpage... looking in the wrong places :-) Could you offer any links? Is it simply a distributed session implementation or?! I don't know much about it. Basically, it's a simple multicast based session replication implementation, written by Filip Hanik (you may remember his TC 4 clustering article). There are indeed no docs about that at the moment. adFor more complete clustering, there's JB, of course :)/ad -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[5.0.11] New alpha build
I have released a new alpha test build, with, among others, a fix for the commons-logging classloading issues that were present in previous 5.0.x releases. Please test it. Downloads: http://jakarta.apache.org/site/binindex.cgi I'll post a vote on the build tomorrow. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 4.1.24 Coyote Connector hangs
[EMAIL PROTECTED] wrote: Hi, Our Tomcat instances are configured to use two Coyote Connectors, one for requests from our SSL accelerator and the other for standard HTTP requests. We are experiencing problem where after a period of time, anything from 10 minutes to a few days, one of the Connectors stops working. The effected Connector continues to accept incoming requests for a short while but never responds to them. It occurs on both Connectors and, once one has stopped working, typically, the other Connector remains unaffected and continues working normally. The only way to recover from this is for us to restart Tomcat. We are using Tomcat 4.1.24 running on x86 based dual CPU machines using Red Hat Linux 9 (kernel 2.4.20-8smp) and using Java Runtime 1.4.1_03. We have experienced the problem even when the site is under very little load. Inspecting the log files does not show any occurrences of 'All threads are busy' messages. We have set the debug attribute of the Connector to 9 but this has not revealed anything of interest in the logs. We have generated numerous full thread dumps while the problem is occurring but cannot see anything obvious when examining these and we have used OptimizeIt to analyze our application and we cannot see anything obvious in our application. Our server.xml file and one of the thread dumps (when the server was under very little load) are at the end of this mail. Has anyone experienced something similar or perhaps have some comments/suggestions? Thanks for your attention. I'm scpetical. Well, there's not too much wrong with your dump. I'm only wondering about the thread ids which are a bit weird (the gaps are too big). Would you be willing to test TC 5.0.9 or 5.0.10 ? If you're having such stability issues with 4.1, it can't be really worse IMO. There's additional monitoring features (such as the status servlet), which can help investigate. If you didn't edit the thread dump, then the only explanation I can see so far is that there's a bug with the currentThreadCount variable (and I can see how that would happen). If you can add some traces on the internal ThreadPool variables, that could also help. The structure of the class is relatively simple. -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: $CATALINA_HOME/shared/lib is *STILL* Ignored....
Tony LaPaso wrote: Hi all, I posted a similar question a couple days ago but it seems the well-intended responses I received were incorrect. And let me first say that I have RTFMs -- more than once -- and this *SHOULD* work, at least according to TFMs. I'm using TC v5.0.9 on Linux with J2SE 1.4.2_01. Very simply, I have a Jar with some custom classes in $CATALINA_HOME/shared/lib/. These classes are not being found in my web application. Instead, I get a NoClassDefFoundError. If I move the Jar to $CATALINA_HOME/common/lib/, the classes are found with no problem. Somebody, please, just do what I described above and tell me if you can get classes to load from a jar in $CATALINA_HOME/shared/lib. According to the Tomcat docs, Jar files in $CATALINA_HOME/shared/lib/ *SHOULD BE AVAILABLE* to a web app. See the TC documentation at: http://jakarta.apache.org/tomcat/tomcat-5.0-doc/class-loader-howto.html I'm wondering if the TC docs are once again in error Please don't whine. As far as I am concerned, the feature works, and the documetation is right. However, the shared CL is very error prone because it is stuck in between the two main CL (the webapp CL and the main common CL) for class visibility problems. (ie, the JARs from common can't see JARs form the shared loader, and the JARs in shared can't see the JARs in the webapp CL) Inside your webapp code, you can do a Thread.currentThread().getContextClassLoader().toString() to get a view of the CL hierarchy and all the class repositories which are initialized on each level. -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache Tomcat Performance Handbook
John Turner wrote: The book was never published. The original publisher (Wrox) went out of business and liquidated assets. The rights to the performance handbook (and many other former Wrox titles including the security handbook) were picked up by Apress. The rights to the rest were picked up by Wiley. I think Wiley is running wrox.com right now. From the conversations I've had with Apress, the future of the performance book is undecided, though that could change at any moment. I for one think there is a need for such a book, but with Tomcat 5 coming out, it might need to be rewritten to address the new release. As the coauthor of the said handbook (which is now indeed relatively out of date), I am quite pissed at Wrox and APress (I still haven't been paid a dime despite recurrent claims from APress for the past 4 months that they'll be coming back to me within a week). So a big thank you to these folks for the nice support to OSS contributors :-D (ok, I'm sarcastic) -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem in tomcat-5.0-doc/setup.html
Damien wrote: Hi, I've downloaded tomcat (jakarta-tomcat-5.0.9.tar.gz) and I'm following the instructions found in this page : http://jakarta.apache.org/tomcat/tomcat-5.0-doc/setup.html There is a little error that might confuse beginners : cd $CATALINA_HOME/bin tar xvfz jsvc.tar.gz cd jsvc autoconf ./configure make cp jsvc .. cd .. [EMAIL PROTECTED] jsvc]# make [...] make[1]: Leaving directory `/usr/local/tomcat/bin/jsvc/native' [EMAIL PROTECTED] jsvc]# cp jsvc .. cp: ne peut écraser le répertoire `../jsvc' par un non-répertoire I think you should rename the folder after untar it : cd $CATALINA_HOME/bin tar xvfz jsvc.tar.gz mv jsvc jsvc-source cd jsvc-source autoconf ./configure make cp jsvc .. cd .. I'll fix that. I was using Cygwin when I tested this, and on that platform, the executable name is jsvc.exe, so there's no conflict. Dumb mistake ;-) -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: File upload Bug?
Tom Lyle wrote: I've just realised something. The machine thats running Tomcat 4.1.27 is serving the pages with IIS and isapi_redirector2.dll, when i connect directly to Tomcat via port 8080 it works fine. Right, i've just searched the archives and found 2 people posting (much more elequently) the same problem but no solution. Does anyone know how to fix this? A BZ entry on this problem already exists: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21616 -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Autodeploy to false, but still happening?
Jon Skeet wrote: I should state that I'm pretty new to Tomcat 4, but have used Tomcat 3 for quite a while. In order to prevent the examples web-app from loading (which required the invoker servlet, which I've commented out completely for the moment), I thought I could just set the Host autoDeploy attribute to false, and get rid of the examples Context entry from server.xml. However, it looks like even with autoDeploy false, subdirectories of webapps are automatically added. I'm sure I'm just missing something - anyone care to enlighten me? (Tomcat 4.1.27 if it matters.) There's liveDeploy too (periodic deployment), in addition to autoDeploy. The attributes have been changed in Tomcat 5, BTW (refer to the docs). -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem while installing
Damien wrote: Hi, I have a problem while installing tomcat. I'm following this instruction : http://jakarta.apache.org/tomcat/tomcat-5.0-doc/BUILDING.txt I have used the last versions of the packages mentionned in this page : j2sdk-1_4_2_01-linux-i586.bin apache-ant-1.5.4-bin.tar.bz2 xalan-j_2_5_1-bin.tar.gz and the installed script found in : http://jakarta.apache.org/builds/jakarta-tomcat/build-5/build.xml I don't understand why I always have an error after running ant (step 2.2) : -- [...] testexist: [echo] Testing for /usr/local/jakarta-struts-1.1/lib/struts.jar downloadgz: init: build-depends: build-servletapi: [echo] == Building: /usr/local/servlet-api-2.4/lib/servlet-api.jar BUILD FAILED file:/home/quetzalcoatl/downloads/tomcat-source/jakarta-tomcat-5/build.xml:157: Basedir /home/quetzalcoatl/downloads/tomcat-source/jakarta-servletapi-5/jsr154 does not exist Total time: 7 seconds -- Can somebody help me with this problem ? Thanks for your help, I'm longing to test the program I will review the error. Maybe the script is a bit out of date. Did the scrpt checkout the sources right ? If not (when you're behind a proxy, for example), you need to adjust a few properties. The directory the script tries to access is correct, and should exist if everything went well. There's also the easy way: go download 5.0.9 Beta, which works well enough according to testing. -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem switching to Struts 1.1
Marco Tedone wrote: Hi, I posted this issue to the struts-user list 3 times, but noone replied to me and frankly I'm beginning to be a little worried. In few words we have an application which was running fine until struts rc1 but when we switched to Struts 1.1 the following exceptions is thrown: !-- ENDOF EXCEPTION -- The problem seems to be the org.apache.commons.logging.impl.Log4jCategoryLog class which is not found in the classpath. Now, I had a look at the commons-logging file and actually there is a similar class called org.apache.commons.logging.impl.Log4JCategoryLog (please note the capital 'J'). What shall I do then? Yes, something looks very fishy regarding case sensitivity with the log4j support in commons-logging. You might want to file a bug against commons-logging and because class naming is inconsistent, and can cause user errors (for example, there's a o.a.c.l.impl.Log4jFactory class along with a o.a.c.l.impl.Log4JLogger class). That being said, I've only seen that error occur if the webapp is privileged (ie, there's a Context element with a privileged=true attribute). If you don't know what privileged does, and put it there because it sounds better, I suggest you remove it (and read the docs) :) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IllegalStateException - org.apache.coyote.tomcat4.CoyoteRequest.doGetSession()
[EMAIL PROTECTED] wrote: Hi all, We're running Tomcat 4.1.24 on Win2K sp4. After a few days of use (usually 4-5 days), Tomcat comes to a semi-halt mode and it refuses to process some of the pages. Even the thrown exceptions are not logged. It looks like it's a thread pool related problem because, apparently, the connector runs out of threads. I know that if an error occurs, the thread is supposed to be discarded from the pool to keep the consistency and the integrity however I don't understand why they aren't created again... Please have a look at the stack trace below. Any help/advice would be greatly appreciated! ;-) Thanks, Stack Trace follows: 2003-08-31 01:37:30 JspFactoryImpl: Exception initializing page context java.lang.IllegalStateException: Cannot create a session after the response has been committed Well, this is a valid error, and doesn't indicate a problem. As for TC running out of threads, you should do a thread dump to see what's going on (ctrl+break on Windows in the TC console; I don't know how to do it if TC is running as a service). If the issues persist, you could test TC 5.0.9 beta, which has scalability improvements. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem switching to Struts 1.1
Marco Tedone wrote: Thank you for your support. I must say that the privileged attribute for my application was set to false, but the problem still persists. Are you sure ? I did test it with TC 5 (maybe 5.0.5) / Struts 1.1 examples webapp / log4j 1.2.8, and it did work fine (I simply dropped the log4j JAR in the /WEB-INF/lib - and then added the properties file in /WEB-INF/classes). I'll try to test it again. Most likely the bug is with commons-logging however (the case issue really looks fishy). BTW, false is the default value. The context files for the admin and the manager are not very good examples, obviously, since they need the privileged flag to work. -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL X - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IllegalStateException - org.apache.coyote.tomcat4.CoyoteRequest.doGetSession()
[EMAIL PROTECTED] wrote: Thanks for your prompt answer. Please don't get me wrong, I don't want to sound arrogant or something, but how come an error may not indicate a problem. ;-) It indicates there's likely a bug in the app, not in TC (that's what I meant). You can't create a session if the response has already been committed (a flush or writing a relatively large amount of data would do that). We've already gotten the thread dump. I'll have a look into that as well. Any more ideas? Anybody else maybe? :-) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Tomcat 5.0.6 Alpha released
Tomcat 5.0.6 Alpha is now available for testing. Please refer to the changelog included in the release for the list of changes. Downloads: http://jakarta.apache.org/site/binindex.cgi Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Apache Tomcat 4.1.27 Stable released
The Tomcat Team announces the immediate availability of Apache Tomcat 4.1.27 Stable. Among other bugfixes and improvements, Tomcat 4.1.27 includes security fixes for: - Improper recycling of SSL client certificates with Coyote JK 2 - Improper handling of invalid content lengths in requests, causing HTTP processors to be left in an invalid state in Coyote HTTP/1.1, causing a DoS condition - URI normalization bug in Coyote - Improper handling of certain URLs in Coyote JK 2, causing a DoS condition Downloads: http://jakarta.apache.org/site/binindex.cgi Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Tomcat 5.0.5 Alpha released
Tomcat 5.0.5 Alpha is now available for testing. Please refer to the changelog included in the release for the list of changes. Downloads: http://jakarta.apache.org/builds/jakarta-tomcat/release/v5.0.5-alpha/ Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Tomcat 5.0.4 Alpha released
Tomcat 5.0.4 Alpha is now available for testing. Please refer to the changelog included in the release for the list of changes. Downloads: http://jakarta.apache.org/builds/jakarta-tomcat/release/v5.0.4-alpha/ Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Tomcat 5.0.3 Alpha released
Tomcat 5.0.3 Alpha is now available for testing. Please refer to the changelog included in the release for the list of changes. Downloads: http://jakarta.apache.org/builds/jakarta-tomcat/release/v5.0.3-alpha/ Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Apache Tomcat 4.1.24 Stable released
The Tomcat Team announces the immediate availability of Apache Tomcat 4.1.24 Stable. Tomcat 4.1.24 includes bugfixes and reliability improvements over Tomcat 4.1.18. Please see the release notes for a complete list of the changes. This release addresses the following security issues: - Denial of service affecting the use of SSL with the standalone HTTP/1.1 connector. - Thread safety flaw in the session recycling code, which could lead to two or more users sharing the same session, under rare circumstances. - JDBC session store thread safety fixes. Binary Downloads: http://jakarta.apache.org/site/binindex.cgi Source downloads: http://jakarta.apache.org/site/sourceindex.cgi Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Tomcat 4.1.24 Alpha released
Tomcat 4.1.24 Alpha is now available for testing. Changes over 4.1.23 include: - Fix for a security issue introduced in 4.1.23. - Robust handling of bad cookies. - Properly commit the response after a forward, sendError, and sendRedirect. - Properly set the context classloader when using JspC. The release notes include the full list of changes. Downloads: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.24-alpha/ Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Tomcat 4.1.23 Alpha released
Tomcat 4.1.23 Alpha is now available for testing. Changes over 4.1.22 include: - Updated releases of all dependencies. - Fix incorrect enumeration of sessions in JDBC store. - Reject decoded URIs which don't start with '/', returning a 400. - Auth request for an empty path (relative to the context root) will first redirect to '/', to avoid sharing auth information between contexts. The release notes include the full list of changes. Downloads: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.23-alpha/ Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Tomcat 4.1.22 Alpha released
Tomcat 4.1.22 Alpha is now available for testing. Changes over 4.1.21 include: - Fix for mangling with JSPC - Fix precompilation with tag libraries packaged in JARs - Fix JDBC store thread safety bug which was causing improper session access The release notes include the full list of changes. Downloads: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.22-alpha/ Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Tomcat 5.0.1 Alpha released
Tomcat 5.0.1 Alpha is now available for testing. This is actually the first real milestone of Tomcat 5, as Tomcat 5.0.0 did not include any new feature over 4.1.x other than the support for Servlet API 2.4 drafts and JSP 2.0 drafts. Tomcat 5.0.1 includes: - improved performance (with additional improvements planned) - complete montoring capabilities through JMX, with JSR 77 support - clustering capabilities (not included with that build as a binary) - JMX configuration capabilities - with a lot more to come in later milestones Downloads: http://jakarta.apache.org/builds/jakarta-tomcat/release/v5.0.1-alpha/ Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Apache Tomcat 4.1.21 Beta released
The Tomcat Team announces the immediate availability of Apache Tomcat 4.1.21 Beta. Tomcat 4.1.21 includes many bugfixes and performance tweaks over Tomcat 4.1.18. Please see the release notes for a complete list of the changes. Downloads (source and binaries): http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.21-beta/ Release notes: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.21-beta/RELEASE-NOTES Important note: When upgrading from another Tomcat 4.x release, the Tomcat work directory must be cleared. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Tomcat 4.1.21 Alpha released
Tomcat 4.1.21 Alpha is now available for testing. Changes over 4.1.20 include: - Fix for a nested tag regression in Jasper - Avoid logging client disconnects exception traces The release notes include the full list of changes. Downloads: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.21-alpha/ Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Tomcat 4.1.20 Alpha released
Tomcat 4.1.20 Alpha is now available for testing. Changes over Tomcat 4.1.19 include: - Fix classloading failures when using Tomcat in JNI mode with JK 2 - Upgrade to Xerces 2.3.0 - Admin webapp fixes (including fixes to saving to server.xml) - Disable recycling of sessions - Refactoring of session persistence - Disable socket linger in Coyote HTTP/1.1 (delay when closing a socket), and allow configuring it - Allow cross context from the root context - Documentation updates - Fix memory leak in Jasper when compiling JSP pages - Fix JspC, which may now be used again for complex webapps precompilation, such as Tomcat's own admin webapp - Fix isThreadSafe feature in Jasper - Fix JspWriter recycling after an exception was thrown in a tag's body content The release notes include the full list of changes. Downloads: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.20-alpha/ Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat 4.1.19 Alpha released
Tomcat 4.1.19 Alpha is now available for testing. Changes over Tomcat 4.1.18 include: - Refactored manager and deployer - Fix for a SSL related bug - Jasper will now launch javac in a separate JVM, in order to avoid problems such as memory leaks and file locking - New printer frindly documentation - Support for HTTP/1.1 compression in order to save bandwidth - Fix for HTTP/1.0 keep alive support (now compatible with ab which should generate more accurate benchmark results) - More robust server socket restart code in the event of a critical failure - Fix administration webapp commit changes The release notes include the full list of changes. Downloads: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.19-alpha/ Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: SSL hangs on Tomcat 4.1.18
Carl Zetterberg wrote: Xiaojian Wang of infowisesys.com writes: After starting Tomcat , open a navigator to visit any page,then press F5 to fresh.After a few minutes,a message accured: All threads are busy, waiting. Please increase maxThreads or check the servlet status75 75 75 is the maxProcess of my setting. It's a normal message that sugguest you to increst your mxProcessing setting. In normal mode,tomcat accept new connection after processed the pooled connection. But in SSL mode,it hang!!! And he suggests a solution: ... download the source code jakarta-tomcat-connectors-4.1.18-src on www. apache.org, change PoolTcpPoint.java at: Line 515:continue==break Line 528:continue==break Maybe you also have to change Line 434 from if(linger = 0 ) socket.setSoLinger( true, linger); to //if(linger = 0 ) //socket.setSoLinger( true, linger); because soLinger is OS sensitive.Tell me if you what does soLinger mean or how to set it :-( Recompile and replace the relate class in tomcat-uitl. I believe it work well. Going to try this when I get to work tomorrow. The report is valid (although a bit hard to understand). Only the change for line 515 is useful (as well as a change of the logging priority line 510 to debug to avoid abusive logging). The if block line 527-528 should be removed (it cannot happen). The soLinger doesn't seem harmful. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mysterious parse exception on startup
Joseph Shraibman wrote: If I put the latest xerces and xalan in tomcat/common/endorsed, I get the following error on startup. I don't get this with the xerces/xalan that comes with jdk 1.4.1. What is causing this? What *file* is this? Starting service Tomcat-Apache Apache Tomcat/4.1.18-LE-jdk14 Parse Fatal Error at line 551 column 44: The string -- is not permitted within comments. org.xml.sax.SAXParseException: The string -- is not permitted within comments. at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source) It's a know problem with recent versions of Xerces and Struts 1.0. It is a Xerces bug (which gies a confusing error message). To fix it, you can: - use the JDK 1.4 parser - use the Xerces release bundled with Tomcat 4.1.18 - upgrade to Struts 1.1 beta 3 (the XML is different, and doesn't trigger the Xerces bug) Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: reducing tomcat jasper memory footprint
Paul Yunusov wrote: On Monday 30 December 2002 02:37 pm, Julian Löffelhardt wrote: Hi, I'm using Apache 1.3.26 and 3 tomcat 4.0.4 instances with AJP13 loadbalancing . Our application is a CMS where all the published articles are generated offline as JSP-Files, one jsp per article. We had hige problems with the memory footprint. Due to the fact that every jsp is generated as a class and there are about 200 new artices per day the permanent segment of the JVM heap gets filled with all the classes, and I get an OutOfMemoryError. My workaround for now is setting -XX:PermSize and --XX:MapPermSize to higher values, but this just delays application hang-up. With 64 megs of permSize our Server had an approx. uptime of 1 day now it's about 3-4 days. Is there any way to unload jsp-Files (unload the class) ? llap, julian JAVAC leaks memory every time a JSP class is compiled. The more JSPs are compiled or the more often JSP classes are compiled, the more memory is leaked. You exacerbate this problem by generating a JSP per article often. IMHO, generating a JSP per article is misusing the technology. JSP is a templating solution whereas one JSP describes a layout of any number of end documents. I suggest you change your software to generate an HTML file per artcile rather than a JSP. Maybe it's abusing the technology, but it really should work fine. Workarounds for the problem include using jikes, or using javac out of process (I don't quite remember how it is configured; since Jasper 2 uses Ant javac task to compile, it should be in the Ant docs on the javac task). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: SSL hangs on Tomcat 4.1.18
mech wrote: I was just trying around with minProcessors=1 and maxProcessors=2 Although I get this warnings quite easily (just 2 or 3 browser windows are enough), after one request (really slow) is completed the next request is processed. So obviously the threads must have been reused. If I set acceptCount=1 the browser comes up with page not found if all threads are in use. Maybe play around with the acceptCount setting. Even If your load is low, some nervous user might keep clicking on https links, if the page is not loading quickly enough. I wonder not to see an connectionTimeout attribut? I set to 2 for http and https (default should be 6 according to documentation). Maybe that makes a difference, too? By the way I encountered the following exception, if I stress test too much: I don't know why you get that exception, but if you actually get it, then the root cause should be that something went bad during the socket accept. Standard socket processing is obviously better tested than SSL sockets, so I doubt this happens; could you debug this further, and give more details ? It would be a good idea to test stability with PureTLS or the newest JSSE (that might help if the problems come from JSSE from JDK 1.4). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat stability problem
Ben Glorie wrote: We're running Tomcat 4.1.12 on a dual-proc PIII with 512MB RAM. The application consists of 100,000+ HTML pages and approx. 100 jsp pages. We get approx. 60,000 page views per day. Performance is fine, but occasionally the system runs into the following problem: - when you request a jsp page in the browser, there is a delay of 5-10 seconds, then the page is loaded into the browser - even though the HTML code is complete and all images are visible, the browser still appears to be loading something (load bar is creeping) - then after approx. 30 seconds the loading stops (because of a page timeout?) - static HTML pages are not affected, they load as quickly as usual Before trying to look into this further, I would upgrade to Tomcat 4.1.18, and see if there are still problems. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: For anyone with unexplainable, unsolvable Tomcat problems (Win32)
kruger.stephen wrote: Just a quick mail which might help some of you experiencing similar problems. I just spent 3 days solid trying to debug a Servlet which incorporates Jini, into Tomcat 4.1. Not to bug you with the specifics of Jini, but suffice it to say there is some real hairy stuf with classloaders, codebase, rmiregistry etc etc.. I kept getting a ridiculously vague Socket exception : Client closed connection when trying to register a Jini listener. I finally solved my problem by re-installing Tomcat in a directory containing no spaces. Someone, somewhere, used the absolute directory path to contruct a URL, and I guess this came from CATALINA_HOME or CATALINA_BASE, and since it wasn't properly urlencoded, it fails. The failure gives NO hint whatsoever of where, why the problem occured, so my advice is, if yo're having unexplained problems,just TRY it. Beware, it's not only the Program Files with an offending space, some genius at Apache decided to use Tomcat 4.1 as well. At least the Unix package was created with a bit more sense. All problems were solved simply by re-installing to a directory path without any spaces. Hope this helps some of you. Others, if yo're interested, I can send you the old stack traces, but they're really vague. Unfortunately, this is a JDK limitation (the URLs are not properly encoded, so there are RMI problems with spaces in paths). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JAVA_HOME problem with 4.1.18
Ben Ricker wrote: I have this weird problem with setting the JAVA_HOME env variable in Tomcat 4.1.18 (I also had it in 4.1.17). Here is the lines from my startup.sh: CATALINA_HOME=/usr/local/tomcat1-new JAVA_HOME=/usr/local/j2re1.4.1_01 JAVA_OPTS=-ms32m -mx200m export CATALINA_HOME JAVA_HOME JAVA_OPTS This setup worked in 4.1.12 and 4.0.6. Now, when I start Tomcat using the startup.sh, I get this: [root@dev bin]# ./startup.sh The JAVA_HOME environment variable is not defined correctly This environment variable is needed to run this program What gives? You need to specify a path to a JDK now, instead of a JRE. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
