Re: Tomcat 100% CPU usage after moving from Java 5 to 6
Christopher Schultz-2 wrote: Can you give us a timestamp for when the trouble started? Reading GC output is pretty tedious. I believe the trouble started around 15 - 20 minutes before the end of the gc log, so that would be from ~61h36m. Christopher Schultz-2 wrote: Also, what happens if you remove all your *GC* options (other than logging) from your JAVA_OPTS? I am quite hesitant to try this. This is a production environment, and all in all Tomcat is performing pretty good now, in comparison to what the situation was before. By all GC options, do you also mean the UseConcMarkSweepGC? Wouldn't the GC become serial then (with pauses which stop the whole webapp for a while)? And also the +DisableExplicitGC? Christopher Schultz-2 wrote: Is this reproducible? Well, as I said, Tomcat is working much more stable now than it did before. However, once in a few days it still becomes unresponsive, while CPU usage stays incredibly low. I have tried load tests using jMeter on our development environment, but it's working fine then. Must have something to do with the real (more diverse, less predictable/repetitive) traffic on the production environment, I guess.. -- View this message in context: http://old.nabble.com/Tomcat-100--CPU-usage-after-moving-from-Java-5-to-6-tp27305110p27416818.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 100% CPU usage after moving from Java 5 to 6
In the meantime, the environment has been much more stable than it was before the move to Java 6 and the new JVM options. However, a few minutes ago, Tomcat became completely unresponsive, while the CPU usage was very low (~3%). This was on our external server, with these options: -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory -Dcom.sun.management.jmxremote -XX:MaxPermSize=512m -Xloggc:D:\logs\gc\tomcat-gc.log -XX:+PrintGCDetails -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:+DisableExplicitGC -XX:NewSize=3072m -XX:+UseCompressedOops -Xms7168m -Xmx7168m The gc log is showing a lot of activity during the unresponsiveness (the gc log is attached to this message). Do you guys see any clues? Thanks in advance! The Tomcat GC log: http://old.nabble.com/file/p27402032/tomcat-gc.log tomcat-gc.log -- View this message in context: http://old.nabble.com/Tomcat-100--CPU-usage-after-moving-from-Java-5-to-6-tp27305110p27402032.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 100% CPU usage after moving from Java 5 to 6
I have now fixed the infinite loop, and again did the update from Java 5 to Java 6. This time all seems to be working like a charm! Along with fixing the infinite loop, I have dug a little deeper into the JVM arguments. I found the following article particularly useful: http://confluence.atlassian.com/display/DOC/Garbage+Collector+Performance+Issues Using that article plus common sense, my arguments are now: -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory -Dcom.sun.management.jmxremote -XX:MaxPermSize=512m -Xloggc:D:\logs\gc\tomcat-gc.log -X:+PrintGCDetails -XX:+UseConcMarkSweepGC -XX:+UseTLAB -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled -XX:+DisableExplicitGC -XX:NewSize=4096m -Xms10240m -Xmx10240m The NewSize parameter was new to me, and it's explanation on the aforementioned link made much sense. A few things I'm still not completely sure about: - I don't want any serial garbage collection to occur. I'm not sure whether my arguments take care of this now.. - Do I still need the -XX:+UseTLAB argument? - Do I still need the -XX:+CMSClassUnloadingEnabled flag? - Do I still need the -XX:+CMSPermGenSweepingEnabled flag? So, still some research to be done. In the meantime I am very pleased with the results. Tomcat's CPU usage seems significantly lower than before (it's average seems about 10% now - which was 30-40% before) - scary! -- View this message in context: http://old.nabble.com/Tomcat-100--CPU-usage-after-moving-from-Java-5-to-6-tp27305110p27319482.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 100% CPU usage after moving from Java 5 to 6
I also added the -XX:+UseCompressedOops JVM option (as suggested in the Confluence article I mentioned earlier). BTW, for those who want to know: this option is available since update 14 of JDK 6 (see also http://java.sun.com/javase/6/webnotes/6u14.html), you don't need the Performance branch as mentioned in the article. This option is said to give a performance gain of 25% as well as a reduction of used heap space (see also http://blog.juma.me.uk/2008/10/14/32-bit-or-64-bit-jvm-how-about-a-hybrid/). Furthermore, I discovered the -XX:+UseTLAB option is a default option in JDK 6: http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp I thought, I'd just let you all know! -- View this message in context: http://old.nabble.com/Tomcat-100--CPU-usage-after-moving-from-Java-5-to-6-tp27305110p27322864.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 100% CPU usage after moving from Java 5 to 6
Hi Chuck, thanks for your extensive comments about the JVM options.. n828cl wrote: -Xms10240m -Xmx10240m That's a very large heap; shouldn't hurt as long as you have enough RAM to support it all without paging. (But see below for use with compressed OOPs.) This shouldn't be a problem, the system has 16 GB RAM, almost all of it dedicated to Tomcat. n828cl wrote: Tomcat's CPU usage seems significantly lower than before (it's average seems about 10% now - which was 30-40% before) There are some improvements in the JDK/JRE 6 JIT and synchronization handling, but probably not enough to account for that large a difference. Well, I don't know where exactly it's coming from, but after a full day very closely monitoring the system, it turns out to be the truth. Which is not a bad thing, of course :) n828cl wrote: I also added the -XX:+UseCompressedOops JVM option Be careful with that; it can impact CPU usage, since the compressed OOPs have to be expanded into actual pointers every time they're used, and pointers compressed when stored in a field. Works best with heap sizes less than 4 GB, which avoids the decoding/encoding. For a real explanation of compressed OOPs, look here: http://wikis.sun.com/display/HotSpotInternals/CompressedOops I already found that article myself. Since CPU usage is as low as it is now, I have decided to give it a try. Anyway, thanks again! -- View this message in context: http://old.nabble.com/Tomcat-100--CPU-usage-after-moving-from-Java-5-to-6-tp27305110p27324793.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 100% CPU usage after moving from Java 5 to 6
Pid Ster wrote: Have you tested those memory and garbage collection settings with this version of Java? Well, actually I haven't touched the settings which I used using Java 5. But, I have tested the settings to some extent. My development environment worked perfectly fine using the same memory and garbage collection settings, also under heavy load (with jMeter). Are there any obvious mistakes? Pid Ster wrote: What does the garbage collection log indicate, normal or abnormal activity? Unfortunately I forgot to look at the gc.log (also I'm not sure how to interpret it correctly), and it's overwritten when Tomcat is restarted, so there's really nothing I can say about that. Do you suspect any problems there? -- View this message in context: http://old.nabble.com/Tomcat-100--CPU-usage-after-moving-from-Java-5-to-6-tp27305110p27305900.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 100% CPU usage after moving from Java 5 to 6
Leon Rosenberg-3 wrote: they are all seem to be either in an infinite loop: at java.util.AbstractList$Itr.hasNext(AbstractList.java:339) at nl.indicia.vip.framework.util.Workflow.performWorkflowAction(Workflow.java:166) at nl.indicia.vip.framework.util.DQWorkflow.performWorkflowAction(DQWorkflow.java:56) at org.apache.jsp.bamplaza.componenten.workflow.xmlworkflow_jsp._jspService(xmlworkflow_jsp.java:382) or iterating over a very huge list. This way or other they are consuming your cpu: ajp-8009-18 Id=187 in RUNNABLE cpu=236296 ms usr=236265 ms blocked 315 for -1 ms waited 256 for -1 ms ajp-8009-2 Id=171 in RUNNABLE cpu=221968 ms usr=218734 ms blocked 12822 for -1 ms waited 10071 for -1 ms ajp-8009-30 Id=199 in RUNNABLE cpu=371562 ms usr=368234 ms blocked 9527 for -1 ms waited 7543 for -1 ms ajp-8009-38 Id=210 in RUNNABLE cpu=518890 ms usr=515593 ms blocked 10352 for -1 ms waited 9035 for -1 ms http://old.nabble.com/file/p27305988/DQWorkflow.java DQWorkflow.java http://old.nabble.com/file/p27305988/Workflow.java Workflow.java So either its a bug (maybe a concurrency issue, since java 1.6. has improved a lot in terms of lock contention reduction) or, its a side effect of an out of memory problem, can you make a heap dump with jmap and check whether your Old Gen is 99.% full? Otherwise you should look into at nl.indicia.vip.framework.util.Workflow.performWorkflowAction(Workflow.java:166) which I never heard of, and don't have sources to check, what's happening there exactly. Those Workflow and DQWorkflow classes are from our company, written by the programmer who worked on this project before me. I have attached the two files for further examination. I have noticed the performWorkflowAction method in DQWorkflow is not synchronized and uses Vectors and Iterators. Could this be a possible problem? Even though this all has been working perfectly fine in Java 4 and 5? -- View this message in context: http://old.nabble.com/Tomcat-100--CPU-usage-after-moving-from-Java-5-to-6-tp27305110p27305988.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 100% CPU usage after moving from Java 5 to 6
Jesse Klaasse wrote: Those Workflow and DQWorkflow classes are from our company, written by the programmer who worked on this project before me. I have attached the two files for further examination. I have noticed the performWorkflowAction method in DQWorkflow is not synchronized and uses Vectors and Iterators. Could this be a possible problem? Even though this all has been working perfectly fine in Java 4 and 5? I forgot the attachments, sorry! http://old.nabble.com/file/p27306041/DQWorkflow.java DQWorkflow.java http://old.nabble.com/file/p27306041/Workflow.java Workflow.java -- View this message in context: http://old.nabble.com/Tomcat-100--CPU-usage-after-moving-from-Java-5-to-6-tp27305110p27306041.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 100% CPU usage after moving from Java 5 to 6
Hi Leon,
I don't know what you mean exactly by re-intrant, but your comment points
out I have created an endless while-loop! Apart from moving to Java 6, I had
commented out some lines to reduce logging, not noticing I had created an
endless loop by doing so. I only did this in a jar compiled for Java 6, so
everytime I tried rolling back to Java 5, I also used the old jar (which
didn't have the lines commented out), and the old jar didn't have the
infinite loop. Stupid!
I was completely sure the change from Java 5 to Java 6 was a far bigger one
than the commented-out-lines, but this turns out to be not true at all in
this case!
Best regards, and thanks again!
Jesse.
Leon Rosenberg-3 wrote:
Hello Jesse,
is the Workflow re-intrant? If yes:
this is odd:
you are iterating in a re-intrant action (i assume the action is
re-intrant) over a shared variable?
Vector vecOids = new Vector();
in the method:
Iterator oidIterator = vecOids.iterator();
while (oidIterator.hasNext())
{
//System.out.println(Workflow/doAction: oid= +
((ObjectId)oidIterator.next()).getKey());
}
and you are modifying this vector at multiple places in the same class.
You should probably unit-test this code for concurrency.
regards
Leon
--
View this message in context:
http://old.nabble.com/Tomcat-100--CPU-usage-after-moving-from-Java-5-to-6-tp27305110p27306543.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: IIS 6.0 / JK1.2.25 / Tomcat 5.5.20 - Service temporary unavailable
Hi Rainer, Thanks for jumping in again.. Rainer Jung-3 wrote: When using big heaps, you need to take extra effort to get your GC settings right. Do you have GC-Logs? What are the JVM options you use to start Tomcat? The JVM options: -Dcatalina.base=D:\tomcat -Dcatalina.home=D:\tomcat -Djava.endorsed.dirs=D:\tomcat\common\endorsed -Djava.io.tmpdir=D:\tomcat\temp -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory -Dcom.sun.management.jmxremote -XX:MaxPermSize=512m -Xloggc:D:\logs\gc\tomcat-gc.log -XX:+PrintGCDetails -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+UseTLAB -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled Today's GC log: http://www.nabble.com/file/p20951581/20081211_tomcat-gc.zip 20081211_tomcat-gc.zip Rainer Jung-3 wrote: The attached thread dumps do not belong to Tomcat. They are from the Gauss VIP Content Server. I know that. The whole system is based on the Livelink WCMS Content Management System (formerly Gauss VIP). These thread dumps were all I had, so that's why I included them. Rainer Jung-3 wrote: First of all I assume you are talking about the event starting at 07:09? The initial problems are Timeouts (Winsock 10060). So again we need to find out, why things took to long on the backend. Thread Dumps would be a good start ... Rainer Jung-3 wrote: - Check without APR This seems impossible to do, I had once removed the APR, and the system got REALLY unstable under a normal day's load. I'm quite hesitant to try this again, as you may understand. Regards, Jesse. -- View this message in context: http://www.nabble.com/IIS-6.0---JK1.2.25---Tomcat-5.5.20---%22Service-temporary-unavailable%22-tp18238896p20951581.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IIS 6.0 / JK1.2.25 / Tomcat 5.5.20 - Service temporary unavailable
After two months with a system running smoothly, we are currently experiencing the same problems again (albeit less often). A little update: - The system's memory has been upgraded to 16 GB, Tomcat's memory settings are Xms4096m and Xmx10240m now. - We are using commons-dbcp 1.2.2 instead of Tomcat's internal pooling mechanism, so with org.apache.commons.dbcp.BasicDataSourceFactory as data source factory - Java version is Sun JDK 1.5.0.15 now. We are still at IIS 6.0, JK 1.2.26, Tomcat 5.5.20 and APR 1.1.14. - We have no automatic Tomcat reboots - Currently this 503 hang happens about once or twice a week Attached you will find a part of the isapi_redirector.log of today (the whole morning 503 errors occurred). I also tried to create a thread dump using StackTrace while Tomcat was hanging, but it didn't really work. The other JVM's were able to produce a thread dump, and since all JVM's are part of the same group of services, I have included this thread dump. Any idea, anyone? http://www.nabble.com/file/p20930602/20081210_isapi_redirect.zip 20081210_isapi_redirect.zip http://www.nabble.com/file/p20930602/20081210_threaddump.txt 20081210_threaddump.txt Jesse Klaasse wrote: Last Wednesday, I decided to try to use commons-dbcp (1.2.2) instead of the included naming-factory-dbcp.jar. Besides that, I have removed the validationQuery attribute, after reading about some problems with that. Since then, no problems have arised, Tomcat behaved nicely. I hope this finally has solved my problems. Still have to wait a few weeks before I can really say the system is stable. I keep my fingers crossed. -- View this message in context: http://www.nabble.com/IIS-6.0---JK1.2.25---Tomcat-5.5.20---%22Service-temporary-unavailable%22-tp18238896p20930602.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Filter cuts response in Tomcat 5.5.20
For a few days, I have been breaking my head over this issue: My goal is to create a filter which detects Ajax calls (using jQuery for Ajax, which adds X-Requested-With: XMLHttpRequest to the request headers). If some jsp is requested by an Ajax call, I want to process the jsp's output with this filter (extract the body, correct some entities and stuff, but this is not really important to know for this issue, especially since I don't even get this far). I have implemented the filter structure as outlined here: http://download.oracle.com/docs/cd/B32110_01/web.1013/b28959/filters.htm With one adaptation: in the Filter I check for the X-Requested-With: XMLHttpRequest header, and when it is there, I do the pre-post thing mentioned in the article. If it's not, it just continues the chain. I left the rest of the files untouched. However, it isn't working as it should be. I actually see the PRE and POST lines in the Ajax output, however, most of the time there is nothing between them. And when I print the response length, it's 0 most of the time. This is all working fine using our old development platform (based on Resin 3.0.14), but it isn't working on the new one (based on Tomcat 5.5.20). When I request the same url via a browser, all is working fine. Also, when I disable the filter, all is working fine (however, without my desired changes). So it has to be in the filter's code. An idea, anyone? I have attached the relevant java code for the filter to this message in one tar file: http://www.nabble.com/file/p19265999/AjaxPreparationFilter.tar AjaxPreparationFilter.tar -- View this message in context: http://www.nabble.com/Filter-cuts-response-in-Tomcat-5.5.20-tp19265999p19265999.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IIS 6.0 / JK1.2.25 / Tomcat 5.5.20 - Service temporary unavailable
I will try to remove/increase socket_timeout to see what happens.. Unfortunately, Tomcat hung again today. It managed to work again without manually restarting, but again, the 503 message for a while.. I attached two thread dumps and an excerpt of today's isapi_redirect.log. BTW, this is APR 1.1.14 and JK 1.2.26. Regards, Jesse. Rainer Jung-3 wrote: To really study communication behaviour I would suggest installing a raw http client like curl and then do curl -v -D - http://myserver:myport/myuri Even with curl, the results were exactly as I described before. curl will not cache, follow redirects or any other of those nice user GUI features, that make understanding communication behaviour difficult. http://www.nabble.com/file/p18588484/20080722_isapi_redirect.log.gz 20080722_isapi_redirect.log.gz http://www.nabble.com/file/p18588484/20080722_threaddump1_locked.txt.gz 20080722_threaddump1_locked.txt.gz http://www.nabble.com/file/p18588484/20080722_threaddump2.txt.gz 20080722_threaddump2.txt.gz -- View this message in context: http://www.nabble.com/IIS-6.0---JK1.2.25---Tomcat-5.5.20---%22Service-temporary-unavailable%22-tp18238896p18588484.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IIS 6.0 / JK1.2.25 / Tomcat 5.5.20 - Service temporary unavailable
Last Wednesday, I decided to try to use commons-dbcp (1.2.2) instead of the included naming-factory-dbcp.jar. Besides that, I have removed the validationQuery attribute, after reading about some problems with that. Since then, no problems have arised, Tomcat behaved nicely. I hope this finally has solved my problems. Still have to wait a few weeks before I can really say the system is stable. I keep my fingers crossed. Only problem which I still can't explain: there seems to be a 20 second timeout somewhere between IIS and Tomcat. I have created a test JSP with does this: out.println(wait...); out.flush(); Thread.sleep(65000). out.println(finished!); out.flush(); Calling Tomcat directly by using http://localhost:8080/delay.jsp works as expected (it shows wait..., then waits for 65 seconds and then prints finished!). Calling the same page through IIS causes this: wait... appears on screen after 10 seconds, another wait... appears after another 10 seconds, a Service temporary unavailable message appears I suppose this has something to do with the connect_timeout, prepost_timeout and socket_timeout parameters (which are set to 1, 1 and 10 respectively). Should I set these values to a higher value? What I especially don't understand, is the reappearance of wait... after 10 seconds. Again, thanks for your help so far! Regards, Jesse. Rainer Jung-3 wrote: Jesse Klaasse schrieb: Hi Rainer, We are a week later now, with the changed settings, and while the environment first seemed to be a little more stable, in the end this unfortunately is not the case... We still reboot Tomcat every night automatically, and most of the time once a day manually because of the 503 error. For example, I restarted Tomcat and IIS 10 minutes ago, and in the last 10 minutes, isapi_redirect.log shows about 7 503 errors. Also a lot of 53, 54, 60 and 61 errors. Still looking into the dbcp issue.. I will try to put up a new post, but I'm not sure what the relevant info would be.. Do you have any clues left? Focus on the dbcp problem: Database Pool: all threads waiting in getConnection(). Check, if your bad nodes once again encountered this problem (using thread dumps). Then start a new discussion thread with an appropriate Subject. I'm sure webapp developers with db pool experience will try to help. If the tomcat users list doesn't find a solution, you could then move along to the dbcp list. Regards, Rainer - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/IIS-6.0---JK1.2.25---Tomcat-5.5.20---%22Service-temporary-unavailable%22-tp18238896p18570774.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IIS 6.0 / JK1.2.25 / Tomcat 5.5.20 - Service temporary unavailable
Hi Rainer, We are a week later now, with the changed settings, and while the environment first seemed to be a little more stable, in the end this unfortunately is not the case... We still reboot Tomcat every night automatically, and most of the time once a day manually because of the 503 error. For example, I restarted Tomcat and IIS 10 minutes ago, and in the last 10 minutes, isapi_redirect.log shows about 7 503 errors. Also a lot of 53, 54, 60 and 61 errors. Still looking into the dbcp issue.. I will try to put up a new post, but I'm not sure what the relevant info would be.. Do you have any clues left? Regards, Jesse. Rainer Jung-3 wrote: Hi Jesse, Jesse Klaasse wrote: Hello Rainer, Thanks again for your prompt and clear reply. You're helping me a lot! I have implemented the settings as you suggested (for the datasources of all 8 webapps on my Tomcat server). I need to wait for a restart of the application before the settings become active, however. For your information: currently (Tomcat is running fine now) a netstat command returns about 30 established connections to the database server. I have lowered the removeAbandonedTimeout setting to 30 seconds instead of 60. ... and the 30 seconds are already active (restart done) or also only after the next restart ... I still have a few questions left; Why are there no 'AbandonedObjectPool' messages at all when Tomcat is running fine? I would expect a slowly growing number of locked threads because of the AbandonedObjectPool. But this not happening. Does this maybe mean that once it goes wrong, it skyrockets up to the total of 400 locked threads? And why would that be? By message we mean methods in the thread stacks contained in a thread dump? Usually getConnection() is a very fast method. So it will be hard to find a thread in there unless the getConnection() triggers a new connection establishment to the database (which again might only take a handful of milliseconds), or the pool is exhausted and getConnection() goes into the maxWait. So yes, I would expect, that if one getConnection() hangs seriously, i.e. needs to wait long for actually getting a connection, then very soon a lot of threads will get into this state. Depending on your load, it's possible that e.g. you are calling getConnection() 100 times per second. So if the pool is full for a couple of seconds, you can quickly see the threads accumulating in this state. What we don't know: - why is the pool getting full? - why is this situation persistent, i.e. it seems no more connections are freed. The seconds point is the important one. I don't have a good explanation here, and checking with the commons mailing lists might be a good idea. Of course a lot of dbcp users hang around on this list here. To get some feedback from them, maybe start a new thread with a more specific Subject. In the STDOUT logs of the past few days, there are no messages at all saying something like 'DBCP object created'. Shouldn't there be such messages already? Yes, if you had logAbandoned=true during that time, and dbcp detected any connections, which were not freed. Again: I have no convincing hypothesis what's happening, apart from the fact, that the solution lies in the subsytems webapp/DBCP/database. And finally, would you advise me to install the 1.2.26 version of the isapi_redirector connector again? As well as the 1.1.12 (or 1.1.13, but I can't find it for Win64) version of the APR? 1.2.26: first solve your db pool problem, at least until the situation gets stable. Updating to 1.2.26 is optimization and not critical. Concentrate on the pool first. The same for tcnative 1.1.13 or the forthcoming 1.1.14 (I guess that will be announced soon). Thanks. Jesse. Regards, Rainer Rainer Jung-3 wrote: So maybe start with something like initialSize=10 maxActive=50 maxIdle10 minIdle=0 maxWait=5000 and check via netstat, how many connections you actually use during peak load. Make sure, your database is correctly configured to handle the maxActive connections. -- kippdata informationstechnologie GmbH Tel: 0228 98549 -0 Bornheimer Str. 33aFax: 0228 98549 -50 53111 Bonn www.kippdata.de HRB 8018 Amtsgericht Bonn / USt.-IdNr. DE 196 457 417 Geschäftsführer: Dr. Thomas Höfer, Rainer Jung, Sven Maurmann === kippdata informationstechnologie GmbH Tel: +49 228 98549 -0 Bornheimer Str. 33aFax: +49 228 98549 -50 D-53111 Bonn www.kippdata.de HRB 8018 Amtsgericht Bonn / USt.-IdNr. DE 196 457 417 Geschäftsführer: Dr. Thomas Höfer, Rainer Jung, Sven Maurmann - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL
Re: IIS 6.0 / JK1.2.25 / Tomcat 5.5.20 - Service temporary unavailable
Hello Rainer, First of all, thank you for your extensive answer and the time you have taken to write the answer, this really gives me hope. Rainer Jung-3 wrote: Double check: The worker is a member of a load balancer. the member is *not* in state STOP (because that is a configuration state) but in ERROR (which is a runtime detected state). You are right, the worker is (the only) member of a load balancer. It is in OK state until Tomcat hangs. Then it changes into ERROR. Rainer Jung-3 wrote: First: you don't use a reply_timeout? At this stage you shouldn't, just want to make sure. I haven't configured a reply_timeout. Rainer Jung-3 wrote: How to do thread dumps: if Tomcat is running from a DOS box, you can use CTRL-Break on the keyboard (and the dumps go directly to the DOS box), if it is running as a service, there is an entry in the context menue of the tomcat monitor icon (system tray), and the dumps go to the service log file. Tomcat was hanging a few minutes ago, and I have created some thread dumps, which are available in the uploaded ZIP file. Rainer Jung-3 wrote: Use netstat -an on the IIS system and the Tomcat system (if they are not the same) to produce a list of TCP connections and their state. For your information: Tomcat and IIS are on the same system. I have also included a few netstat logs from the moment hanging. They can also be found in the attached zip file. Rainer Jung-3 wrote: If possible use wireshark to produce a full packet dump of the communications between the two for a minute or so, namely long enough, that the cited log message occur a few times. I have downloaded and installed Wireshark. I have included a few minutes of Wireshark captured data in the zip file too. Rainer Jung-3 wrote: - remove the socket_timeout and - remove the APR connector (tcnative) If this solves the problem, check, if removing only of of them suffices. If this quick test indicates APR connector as problematic, upgrade to 1.1.13 (or the soon to appear 1.1.14). I have already tried to remove the APR connector, but this was really not a good idea. Without APR, Tomcat hung after only one hour of normal use. With APR, it lasts for about half a day. During the last hang, I downgraded APR to 1.1.10, which we were using before 1.1.12, and which seems to be a little more stable. I haven't been able to find 1.1.13 for Windows x64. Is it available? I tried the http://tomcat.heanet.ie/native/ link. Should I really try to remove the socket_timeout? Should I try this before setting the reply_timeout to 60 seconds, as you state later in your mail? Rainer Jung-3 wrote: The log information in 1.2.26 should be more precise though. At least for me ;) When we used 1.2.26, logging was more precise indeed. But it seemed to be less stable, although I'm not sure if this has anything to do with the connector version, since I also changed the tcnative version. Rainer Jung-3 wrote: Here I guess: since there was no reply_timeout set, the socket_timeout fires after 10 seconds, aborts the wait and resets the connection. If you can log response times with IIS, you could check, if they are above 10 seconds. You can also log response times with an appropriate JkRequestLogFormat. How should I set the JkRequestLogFormat? Isn't that an Apache (webserver) directive? I am (and have to be - company policies) using IIS. Rainer Jung-3 wrote: You could set a reply timeout to a huge value, like eg. 60 seconds, if you think that even under load *all* requests should return in less than 60 seconds. We can optimize this setting later (with max_reply_timeouts in 1.2.26). I will try this, but not yet. Not all at the same time :) Rainer Jung-3 wrote: You could try TCP tuning like in http://support.microsoft.com/kb/191143 but I doubt, that this will resolve the root consequence. This sounds unlikely to me too, so this will be a last resort maybe.. Rainer Jung-3 wrote: Aha, if this is really coming before the error 60, then you should aso look at: http://support.microsoft.com/kb/931319/ Sounds like it could be helping. I have installed the hotfix. But, the system needs to be restarted in order to active the hotfix (argh!), something I can't just do when when the traffic is high. Maybe I'll reboot the server tonight. Rainer Jung-3 wrote: Maybe too many suggestions and not a straight solution, but if you are able to collect more information, we should be able to sort this out. I hope the logs/dumps will help you.. I will look into them myself also. Rainer Jung-3 wrote: Do others have the same issue on Windows? Did they find a solution? I have searched all over the web, and there is a lot of information about this whole setup, but it's very fragmented and the opinions are pretty wide spread. Again, thank you very much for your help and time so far. I hope we will be able to resolve this problem!
Re: IIS 6.0 / JK1.2.25 / Tomcat 5.5.20 - Service temporary unavailable
Hi Rainer. Thank you very much for this preliminary information. I had already noticed the AbandonedObjectPool messages myself. My resource configuration: name=bam/jdbc/vip8db auth=Container type=javax.sql.DataSource username=***REMOVED*** password=***REMOVED*** driverClassName=com.microsoft.jdbc.sqlserver.SQLServerDriver url=jdbc:microsoft:sqlserver://***REMOVED***;databasename=***REMOVED*** removeAbandoned=true removeAbandonedTimeout=60 logAbandoned=true validationQuery = SELECT Bedrijfscode FROM entBedrijf I have already checked the Java code of the first 4 or 5 waiting threads, but all connections/statement/resultsets are correctly closed. So the problem seems to be in the dbcp, as you already say. But I'm not sure yet. Would there be some kind of quick fix for now? To prevent Tomcat from hanging? Although of course I'd prefer a real solution.. Thank you very very much for your work so far. I hope we will get to the solution! Jesse. Rainer Jung-3 wrote: The root problem lies within the database connection pool. All 400 Tomcat threads are waiting in getConnection() to get a free DB connection from the common-dbcp pool. There are some bugs around dbcp, but I need a little time to check, if they apply to your version. This is just a short note, that yes, there is some hope ;) In the meantime: could you post your DataSource configuration (omit the password). -- View this message in context: http://www.nabble.com/IIS-6.0---JK1.2.25---Tomcat-5.5.20---%22Service-temporary-unavailable%22-tp18238896p18256392.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IIS 6.0 / JK1.2.25 / Tomcat 5.5.20 - Service temporary unavailable
Hello Rainer, Thanks again for your prompt and clear reply. You're helping me a lot! I have implemented the settings as you suggested (for the datasources of all 8 webapps on my Tomcat server). I need to wait for a restart of the application before the settings become active, however. For your information: currently (Tomcat is running fine now) a netstat command returns about 30 established connections to the database server. I have lowered the removeAbandonedTimeout setting to 30 seconds instead of 60. I still have a few questions left; Why are there no 'AbandonedObjectPool' messages at all when Tomcat is running fine? I would expect a slowly growing number of locked threads because of the AbandonedObjectPool. But this not happening. Does this maybe mean that once it goes wrong, it skyrockets up to the total of 400 locked threads? And why would that be? In the STDOUT logs of the past few days, there are no messages at all saying something like 'DBCP object created'. Shouldn't there be such messages already? And finally, would you advise me to install the 1.2.26 version of the isapi_redirector connector again? As well as the 1.1.12 (or 1.1.13, but I can't find it for Win64) version of the APR? Thanks. Jesse. Rainer Jung-3 wrote: So maybe start with something like initialSize=10 maxActive=50 maxIdle10 minIdle=0 maxWait=5000 and check via netstat, how many connections you actually use during peak load. Make sure, your database is correctly configured to handle the maxActive connections. -- View this message in context: http://www.nabble.com/IIS-6.0---JK1.2.25---Tomcat-5.5.20---%22Service-temporary-unavailable%22-tp18238896p18257860.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
IIS 6.0 / JK1.2.25 / Tomcat 5.5.20 - Service temporary unavailable
I have migrated a customer's server system to the following configuration: MS IIS 6.0 (port 80) Unlimited connections Connection timeout: 120s keep-alive JK 1.2.25 AJP/1.3 Connector isapi_redirect.properties: uri_select=parsed workers.properties: connect_timeout=1 prepost_timeout=1 socket_timeout=10 connection_pool_timeout=60 connection_pool_size=350 Apache Tomcat 5.5.20 (ports 8080 / 8009) Apache Portable Runtime tcnative-1.dll 1.1.12 installed Java options: -XX:MaxPermSize=512m -Xloggc:D:\logs\gc\tomcat-gc.log -XX:+PrintGCDetails -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+UseTLAB -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled -Xms4096m -Xmx5120m server.xml connector 8009: acceptCount=100 maxThreads=400 minSpareThreads=25 maxSpareThreads=75 connectionTimeout=6 This is a dual-core Xeon machine running Windows Server 2003 x64 with 6 GB RAM and Sun Java JDK 1.5. I have to reboot Tomcat every night, and even then I have to restart Tomcat manually almost every day because of a Service temporary unavailable message. When Tomcat is hanging, JK Status Manager shows a Bad/Stopped worker. A reset of the worker doesn't fix the problem, neither does a restart of IIS. Only restarting Tomcat fixes the problem. The isapi_redirect log contains a lot of these lines: [Wed Jul 02 16:19:16.908 2008] [11604:13424] [info] ajp_send_request::jk_ajp_common.c (1265): (ajp13w) all endpoints are disconnected [Wed Jul 02 16:19:16.908 2008] [11604:13424] [info] ajp_service::jk_ajp_common.c (2085): (ajp13w) sending request to tomcat failed, recoverable operation attempt=1 I have also tried the 1.2.26 connector. It seemed like it needed a restart even sooner with that one. These lines were in isapi_redirect.log a lot of times with the 1.2.26 version: [Wed Jul 02 15:44:51.040 2008] [11604:12396] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (966): (ajp13w) can't receive the response message from tomcat, network problems or tomcat (127.0.0.1:8009) is down (errno=60) [Wed Jul 02 15:44:51.040 2008] [11604:12396] [error] ajp_get_reply::jk_ajp_common.c (1658): (ajp13w) Tomcat is down or refused connection. No response has been sent to the client (yet) [Wed Jul 02 15:44:51.040 2008] [11604:12396] [info] ajp_service::jk_ajp_common.c (2046): (ajp13w) receiving from tomcat failed, recoverable operation attempt=0 [Wed Jul 02 15:44:51.040 2008] [11604:12396] [info] ajp_service::jk_ajp_common.c (2085): (ajp13w) sending request to tomcat failed, recoverable operation attempt=1 [Wed Jul 02 15:44:51.946 2008] [11604:13156] [error] ajp_service::jk_ajp_common.c (2097): (ajp13w) Connecting to tomcat failed. Tomcat is probably not started or is listening on the wrong port [Wed Jul 02 15:44:51.962 2008] [11604:13156] [info] service::jk_lb_worker.c (1128): service failed, worker ajp13w is in error state [Wed Jul 02 15:44:51.962 2008] [11604:13156] [info] service::jk_lb_worker.c (1191): All tomcat instances are busy or in error state [Wed Jul 02 15:44:51.962 2008] [11604:13156] [error] HttpExtensionProc::jk_isapi_plugin.c (1537): service() failed with http error 503 Nothing important seems to be in the stdout logs right before the problems occur. Only when I was using 1.2.26 of the connector, lots of these messages show up in the stdout: Jul 2, 2008 1:14:17 PM org.apache.jk.common.ChannelSocket processConnection WARNING: processCallbacks status 2 Jul 2, 2008 1:14:17 PM org.apache.jk.core.MsgContext action WARNING: Error sending end packet java.net.SocketException: Software caused connection abort: socket write error at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:531) at org.apache.jk.common.JkInputStream.endMessage(JkInputStream.java:112) at org.apache.jk.core.MsgContext.action(MsgContext.java:293) at org.apache.coyote.Response.action(Response.java:182) at org.apache.coyote.Response.finish(Response.java:304) at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:281) at org.apache.catalina.connector.Response.finishResponse(Response.java:476) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:1 51) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:199) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:282) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java: 697) at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket. java:889) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool .java:684) at java.lang.Thread.run(Thread.java:595) I'm starting to be
Re: IIS 6.0 / JK1.2.25 / Tomcat 5.5.20 - Service temporary unavailable
Additional information: When using version 1.2.26 of the connector, these messages appear in isapi_redirect.log before the messages I quoted in my previous mail: [Wed Jul 02 15:39:34.690 2008] [11800:10604] [info] service::jk_lb_worker.c (1221): Forcing recovery once for 1 workers [Wed Jul 02 15:39:34.690 2008] [11800:10604] [error] ajp_connection_tcp_send_message::jk_ajp_common.c (965): sendfull returned -53 (errno=53) [Wed Jul 02 15:39:34.690 2008] [11800:10604] [info] ajp_handle_cping_cpong::jk_ajp_common.c (803): can't send cping query [Wed Jul 02 15:39:34.690 2008] [11800:10604] [error] ajp_connect_to_endpoint::jk_ajp_common.c (904): (ajp13w) cping/cpong after connecting to the backend server failed (errno=53) [Wed Jul 02 15:39:34.690 2008] [11800:10604] [error] ajp_send_request::jk_ajp_common.c (1359): (ajp13w) connecting to backend failed. Tomcat is probably not started or is listening on the wrong port (errno=53) [Wed Jul 02 15:39:34.690 2008] [11800:10604] [info] ajp_service::jk_ajp_common.c (2186): (ajp13w) sending request to tomcat failed (recoverable), because of error during request sending (attempt=1) [Wed Jul 02 15:39:34.690 2008] [11800:10604] [error] ajp_connection_tcp_send_message::jk_ajp_common.c (965): sendfull returned -53 (errno=53) [Wed Jul 02 15:39:34.690 2008] [11800:10604] [info] ajp_handle_cping_cpong::jk_ajp_common.c (803): can't send cping query [Wed Jul 02 15:39:34.690 2008] [11800:10604] [error] ajp_connect_to_endpoint::jk_ajp_common.c (904): (ajp13w) cping/cpong after connecting to the backend server failed (errno=53) [Wed Jul 02 15:39:34.690 2008] [11800:10604] [error] ajp_send_request::jk_ajp_common.c (1359): (ajp13w) connecting to backend failed. Tomcat is probably not started or is listening on the wrong port (errno=53) [Wed Jul 02 15:39:34.690 2008] [11800:10604] [info] ajp_service::jk_ajp_common.c (2186): (ajp13w) sending request to tomcat failed (recoverable), because of error during request sending (attempt=2) [Wed Jul 02 15:39:34.690 2008] [11800:10604] [error] ajp_service::jk_ajp_common.c (2204): (ajp13w) Connecting to tomcat failed. Tomcat is probably not started or is listening on the wrong port [Wed Jul 02 15:39:34.690 2008] [11800:10604] [info] service::jk_lb_worker.c (1168): service failed, worker ajp13w is in error state [Wed Jul 02 15:39:34.690 2008] [11800:10604] [info] service::jk_lb_worker.c (1245): All tomcat instances are busy or in error state [Wed Jul 02 15:39:34.690 2008] [11800:10604] [error] HttpExtensionProc::jk_isapi_plugin.c (1527): service() failed with http error 503 Jesse Klaasse wrote: I have also tried the 1.2.26 connector. It seemed like it needed a restart even sooner with that one. These lines were in isapi_redirect.log a lot of times with the 1.2.26 version: [Wed Jul 02 15:44:51.040 2008] [11604:12396] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (966): (ajp13w) can't receive the response message from tomcat, network problems or tomcat (127.0.0.1:8009) is down (errno=60) [Wed Jul 02 15:44:51.040 2008] [11604:12396] [error] ajp_get_reply::jk_ajp_common.c (1658): (ajp13w) Tomcat is down or refused connection. No response has been sent to the client (yet) [Wed Jul 02 15:44:51.040 2008] [11604:12396] [info] ajp_service::jk_ajp_common.c (2046): (ajp13w) receiving from tomcat failed, recoverable operation attempt=0 [Wed Jul 02 15:44:51.040 2008] [11604:12396] [info] ajp_service::jk_ajp_common.c (2085): (ajp13w) sending request to tomcat failed, recoverable operation attempt=1 [Wed Jul 02 15:44:51.946 2008] [11604:13156] [error] ajp_service::jk_ajp_common.c (2097): (ajp13w) Connecting to tomcat failed. Tomcat is probably not started or is listening on the wrong port [Wed Jul 02 15:44:51.962 2008] [11604:13156] [info] service::jk_lb_worker.c (1128): service failed, worker ajp13w is in error state [Wed Jul 02 15:44:51.962 2008] [11604:13156] [info] service::jk_lb_worker.c (1191): All tomcat instances are busy or in error state [Wed Jul 02 15:44:51.962 2008] [11604:13156] [error] HttpExtensionProc::jk_isapi_plugin.c (1537): service() failed with http error 503 -- View this message in context: http://www.nabble.com/IIS-6.0---JK1.2.25---Tomcat-5.5.20---%22Service-temporary-unavailable%22-tp18238896p18239267.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: URL encoding problem IIS6 / JK1.2.25 / Tomcat 5.5.20
André Warnier wrote: It would appear (from the logs), that there is some double-encoding of the URI going on. [snip] But, if somewhere along the line, a piece of code was receiving the encoded URI http://.../test%5Bbrackets%5D.jsp;, and decided to re-encode it again using the % hex hex method, then you would get this URI : http://.../test%255Bbrackets%255D.jsp; (where %25 is the encoded version of %). Then the next step would decode this URI back into http://.../test%5Bbrackets%5D.jsp;, and that is what the server would try to access, what would be logged, and also what you seem to experience. So, which is the culprit which re-encodes something it should not ? And is there not some parameter somewhere which forces it to do so ? Thanks for your excellent answer. I have fixed the problem now. There is a setting for the isapi_redirecor called uri_select. This parameter controls the URI's which are passed to Tomcat from IIS. It defaults to value proxy, which leads to some re-encoding. I have changed the parameter's value to unparsed now, which has solved the problem. For those who want to know more, the parameter is explained here: http://tomcat.apache.org/connectors-doc/reference/iis.html Jesse. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: URL encoding problem IIS6 / JK1.2.25 / Tomcat 5.5.20
André Warnier wrote: [...] Now, I should add that using [ and ] in URL's is not really something I would recommend, if only for legibility reasons. It will always make people wonder if what they're seeing in the logfile is normal, or if it's some programming syntax which escaped there. And I would bet that naming your servlet that way is also going to bring you trouble if you ever have to reference it in a Javascript line for instance. I completely agree with you when you're saying [ and ] are not recommended in URL's. However, I don't really have a say in that, something to do with politics and legacy stuff.. Thanks again for your help! Jesse. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
URL encoding problem IIS6 / JK1.2.25 / Tomcat 5.5.20
I have recently migrated a production server from IIS5 / Resin 3.0.14 to IIS6 / JK1.2.25 / Tomcat 5.5.20. Now, there seems to be a problem with the URL translation from IIS to Tomcat. I have this file in a webapp, called test[brackets].jsp. When I try http://localhost:8080/webapp/test[brackets].jsp, everything is working fine. So Tomcat understands the square brackets (appearing in the Tomcat access log as test[brackets].jsp). I have also a plain HTML file, called test[brackets].html. When I try http://localhost/test[brackets].html, it's also working. IIS by itself understands the square brackets, too. Now, we try the whole link through the JK connector: http://localhost/webapp/test[brackets].jsp This doesn't work, and results in a 404 error (appearing in both IIS and Tomcat's log as test%5Bbrackets%5D.jsp, Tomcat with a 404, IIS with a 200). So, there seems to be SOMETHING wrong with the connector (or the connector configuration) in combination with special characters. When I try the same with a file called test.jsp, everything is working fine. The Connector tag in server.xml doesn't have any of the encoding attributes specified, so default encoding is used. Furthermore, the uri_select key hasn't been set for the Isapi Redirector, so I guess default mode (proxy) is used. Anyone? Thanks in advance! Kind regards, Jesse Klaasse. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5 caseSensitive=false and work dir problem
I have implemented the all lowercase filter solution, which does the job nicely. However, there is still one issue.. jsp:forwards don't go through the filter chain, so when the forward page contains uppercase characters, a file is created in the work dir with the uppercase character(s) in it. Then, when a normal request via the browser is done to the same forward page, Tomcat throws a NoClassDefFound exception because of a wrong name of the temp file. As an example, we have two jsp's: - pageA.jsp (with a jsp:forward to pageB.jsp) - pageB.jsp Now, when we do this: - request pageA.jsp in the browser (two temp files are created in the work dir, pagea_jsp.class (lowercase 'a' because of the filter) and pageB_jsp.class) - request pageB.jsp in the browser - NoClassDefFound exception because Tomcat is looking for pageb_jsp.class I think Leon's suggested mapper solution would solve this problem for the most part, but a mapper which is actually a complete file system tree seems rather disk/cpu intensive to me. Can anyone think of another solution for the jsp:forward problem in this case? Leon Rosenberg-3 wrote: On Mon, May 26, 2008 at 3:59 PM, Jesse Klaasse [EMAIL PROTECTED] wrote: Only thing I can think of now is to write a servlet filter which converts all request URLs to lowercase.. But I am kind of hoping for a more elegant solution. Personally I find your solution elegant :-) It would be maybe even more 'elegant' if you map your lowercase url via some mapping to the real name of the jsp internally, like: request EcHoSesSion - Filter = echosession - Mapper = EchoSession.jsp Of course the mapper has to be configured (or browse the file system) to determine the jsps real name. Alternatively you could rename all your jsps to lowercase and forget about the mapper. The advantage of the mapper (or the internal case-sensitivity) is that you webapp remains working on non-windows platforms... just in case, remember: write once, run anywhere :-) -- View this message in context: http://www.nabble.com/Tomcat-5.5-caseSensitive%3Dfalse-and-work-dir-problem-tp17472465p17816552.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
