Re: Webapp reloading issue and intermittent 404 errors
Caldarale, Charles R said on 8.7.2010 3:31: From: Caldarale, Charles R Subject: RE: Webapp reloading issue and intermittent 404 errors Given the test on lines 129-130, it is impossible to have a -1 at line 131 - unless there's a JVM bug. 6u21 was just released tonight, so you might give that a shot and see if the problem has been addressed. Included in 6u21 are fixes for the problems described here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6875866 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6935535 Both seem to have a lot in common with the issue under discussion. There's another String-related fix in the bug list, but the details are not retrievable at the moment: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6948602 Just to let you know, installing 6u21 seems to solve problem completely (hasn't manifested after upgrade at all). -- Tomy t.petro...@inet.hr - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Webapp reloading issue and intermittent 404 errors
Tomislav Petrović said on 30.6.2010 16:27: Forgot to say: Tomcat service is started with following parameters: JVM: have to check whether server or client, not sure at the moment. Server, one would hope. Did you find out the exact version? Yup JVM path for tomcat is ..\jdk1.6.0_18\jre\bin\server\jvm.dll, so Java 6 update 18 server. Although initial excpetion and stacktrace (related to webapp reloading, actually checking that it should or should not be reloaded) went away with reloadable=false workaround I now have similar problem. Please help since now machine is in (or near) production :(. New stacktrace in catalina logs looks like (and produces 404 errors): Jul 5, 2010 7:13:47 AM org.apache.catalina.connector.CoyoteAdapter service SEVERE: An exception or error occurred in the container during the request processing java.lang.StringIndexOutOfBoundsException: String index out of range: 115 at java.lang.String.substring(String.java:1934) at org.apache.catalina.util.RequestUtil.normalize(RequestUtil.java:131) at org.apache.naming.resources.FileDirContext.normalize(FileDirContext.java:771) at org.apache.naming.resources.FileDirContext.file(FileDirContext.java:811) at org.apache.naming.resources.FileDirContext.getAttributes(FileDirContext.java:429) at org.apache.naming.resources.BaseDirContext.getAttributes(BaseDirContext.java:747) at org.apache.naming.resources.ProxyDirContext.revalidate(ProxyDirContext.java:1501) at org.apache.naming.resources.ProxyDirContext.cacheLookup(ProxyDirContext.java:1457) at org.apache.naming.resources.ProxyDirContext.lookup(ProxyDirContext.java:288) at org.apache.tomcat.util.http.mapper.Mapper.internalMapWrapper(Mapper.java:823) at org.apache.tomcat.util.http.mapper.Mapper.internalMap(Mapper.java:667) at org.apache.tomcat.util.http.mapper.Mapper.map(Mapper.java:557) at org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:462) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:296) at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:859) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:579) at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1555) at java.lang.Thread.run(Thread.java:619) Everything else is same as I posted before (config file, JVM versions, etc) Any advice is appreciated -- Tomy t.petro...@inet.hr - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Webapp reloading issue and intermittent 404 errors
On 07/07/2010 11:07, Tomislav Petrović wrote: Tomislav Petrović said on 30.6.2010 16:27: Forgot to say: Tomcat service is started with following parameters: JVM: have to check whether server or client, not sure at the moment. Server, one would hope. Did you find out the exact version? Yup JVM path for tomcat is ..\jdk1.6.0_18\jre\bin\server\jvm.dll, so Java 6 update 18 server. Although initial excpetion and stacktrace (related to webapp reloading, actually checking that it should or should not be reloaded) went away with reloadable=false workaround I now have similar problem. Please help since now machine is in (or near) production :(. New stacktrace in catalina logs looks like (and produces 404 errors): Jul 5, 2010 7:13:47 AM org.apache.catalina.connector.CoyoteAdapter service SEVERE: An exception or error occurred in the container during the request processing java.lang.StringIndexOutOfBoundsException: String index out of range: 115 at java.lang.String.substring(String.java:1934) at org.apache.catalina.util.RequestUtil.normalize(RequestUtil.java:131) at org.apache.naming.resources.FileDirContext.normalize(FileDirContext.java:771) at org.apache.naming.resources.FileDirContext.file(FileDirContext.java:811) at org.apache.naming.resources.FileDirContext.getAttributes(FileDirContext.java:429) at org.apache.naming.resources.BaseDirContext.getAttributes(BaseDirContext.java:747) at org.apache.naming.resources.ProxyDirContext.revalidate(ProxyDirContext.java:1501) at org.apache.naming.resources.ProxyDirContext.cacheLookup(ProxyDirContext.java:1457) at org.apache.naming.resources.ProxyDirContext.lookup(ProxyDirContext.java:288) at org.apache.tomcat.util.http.mapper.Mapper.internalMapWrapper(Mapper.java:823) at org.apache.tomcat.util.http.mapper.Mapper.internalMap(Mapper.java:667) at org.apache.tomcat.util.http.mapper.Mapper.map(Mapper.java:557) at org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:462) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:296) at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:859) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:579) at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1555) at java.lang.Thread.run(Thread.java:619) Everything else is same as I posted before (config file, JVM versions, etc) Any advice is appreciated I think the general feeling is that it's a JVM bug - but no-one can work out what it is. I can't even work out how to get 115 characters out of a normal file path. Can you move the installation from: D:\Program Files\Apache Software Foundation\Tomcat 6.0 To: D:\Tomcat60 ? p -- Tomy t.petro...@inet.hr - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org signature.asc Description: OpenPGP digital signature
Re: Webapp reloading issue and intermittent 404 errors
Pid said on 7.7.2010 12:26: On 07/07/2010 11:07, Tomislav Petrović wrote: Tomislav Petrović said on 30.6.2010 16:27: Forgot to say: Tomcat service is started with following parameters: JVM: have to check whether server or client, not sure at the moment. Server, one would hope. Did you find out the exact version? Yup JVM path for tomcat is ..\jdk1.6.0_18\jre\bin\server\jvm.dll, so Java 6 update 18 server. Although initial excpetion and stacktrace (related to webapp reloading, actually checking that it should or should not be reloaded) went away with reloadable=false workaround I now have similar problem. Please help since now machine is in (or near) production :(. New stacktrace in catalina logs looks like (and produces 404 errors): Jul 5, 2010 7:13:47 AM org.apache.catalina.connector.CoyoteAdapter service SEVERE: An exception or error occurred in the container during the request processing java.lang.StringIndexOutOfBoundsException: String index out of range: 115 at java.lang.String.substring(String.java:1934) at org.apache.catalina.util.RequestUtil.normalize(RequestUtil.java:131) at org.apache.naming.resources.FileDirContext.normalize(FileDirContext.java:771) at org.apache.naming.resources.FileDirContext.file(FileDirContext.java:811) at org.apache.naming.resources.FileDirContext.getAttributes(FileDirContext.java:429) at org.apache.naming.resources.BaseDirContext.getAttributes(BaseDirContext.java:747) at org.apache.naming.resources.ProxyDirContext.revalidate(ProxyDirContext.java:1501) at org.apache.naming.resources.ProxyDirContext.cacheLookup(ProxyDirContext.java:1457) at org.apache.naming.resources.ProxyDirContext.lookup(ProxyDirContext.java:288) at org.apache.tomcat.util.http.mapper.Mapper.internalMapWrapper(Mapper.java:823) at org.apache.tomcat.util.http.mapper.Mapper.internalMap(Mapper.java:667) at org.apache.tomcat.util.http.mapper.Mapper.map(Mapper.java:557) at org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:462) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:296) at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:859) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:579) at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1555) at java.lang.Thread.run(Thread.java:619) Everything else is same as I posted before (config file, JVM versions, etc) Any advice is appreciated I think the general feeling is that it's a JVM bug - but no-one can work out what it is. I can't even work out how to get 115 characters out of a normal file path. Can you move the installation from: D:\Program Files\Apache Software Foundation\Tomcat 6.0 To: D:\Tomcat60 Don't know have to check with customer, but actual index varies in each occurrence of stack trace, sometimes it is even -1. In two days we had: 2x java.lang.StringIndexOutOfBoundsException: String index out of range: 131 1x java.lang.StringIndexOutOfBoundsException: String index out of range: 118 1x java.lang.StringIndexOutOfBoundsException: String index out of range: 106 4x java.lang.StringIndexOutOfBoundsException: String index out of range: -1 3x java.lang.StringIndexOutOfBoundsException: String index out of range: 127 2x java.lang.StringIndexOutOfBoundsException: String index out of range: 126 1x java.lang.StringIndexOutOfBoundsException: String index out of range: 123 Rest of stacktrace is identical in all occurences. In addition -- Tomy t.petro...@inet.hr - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Webapp reloading issue and intermittent 404 errors
On 07/07/2010 11:35, Tomislav Petrović wrote: Pid said on 7.7.2010 12:26: On 07/07/2010 11:07, Tomislav Petrović wrote: Tomislav Petrović said on 30.6.2010 16:27: Forgot to say: Tomcat service is started with following parameters: JVM: have to check whether server or client, not sure at the moment. Server, one would hope. Did you find out the exact version? Yup JVM path for tomcat is ..\jdk1.6.0_18\jre\bin\server\jvm.dll, so Java 6 update 18 server. Although initial excpetion and stacktrace (related to webapp reloading, actually checking that it should or should not be reloaded) went away with reloadable=false workaround I now have similar problem. Please help since now machine is in (or near) production :(. New stacktrace in catalina logs looks like (and produces 404 errors): Jul 5, 2010 7:13:47 AM org.apache.catalina.connector.CoyoteAdapter service SEVERE: An exception or error occurred in the container during the request processing java.lang.StringIndexOutOfBoundsException: String index out of range: 115 at java.lang.String.substring(String.java:1934) at org.apache.catalina.util.RequestUtil.normalize(RequestUtil.java:131) at org.apache.naming.resources.FileDirContext.normalize(FileDirContext.java:771) at org.apache.naming.resources.FileDirContext.file(FileDirContext.java:811) at org.apache.naming.resources.FileDirContext.getAttributes(FileDirContext.java:429) at org.apache.naming.resources.BaseDirContext.getAttributes(BaseDirContext.java:747) at org.apache.naming.resources.ProxyDirContext.revalidate(ProxyDirContext.java:1501) at org.apache.naming.resources.ProxyDirContext.cacheLookup(ProxyDirContext.java:1457) at org.apache.naming.resources.ProxyDirContext.lookup(ProxyDirContext.java:288) at org.apache.tomcat.util.http.mapper.Mapper.internalMapWrapper(Mapper.java:823) at org.apache.tomcat.util.http.mapper.Mapper.internalMap(Mapper.java:667) at org.apache.tomcat.util.http.mapper.Mapper.map(Mapper.java:557) at org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:462) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:296) at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:859) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:579) at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1555) at java.lang.Thread.run(Thread.java:619) Everything else is same as I posted before (config file, JVM versions, etc) Any advice is appreciated I think the general feeling is that it's a JVM bug - but no-one can work out what it is. I can't even work out how to get 115 characters out of a normal file path. Can you move the installation from: D:\Program Files\Apache Software Foundation\Tomcat 6.0 To: D:\Tomcat60 Don't know have to check with customer, but actual index varies in each occurrence of stack trace, sometimes it is even -1. In two days we had: 2x java.lang.StringIndexOutOfBoundsException: String index out of range: 131 1x java.lang.StringIndexOutOfBoundsException: String index out of range: 118 1x java.lang.StringIndexOutOfBoundsException: String index out of range: 106 4x java.lang.StringIndexOutOfBoundsException: String index out of range: -1 3x java.lang.StringIndexOutOfBoundsException: String index out of range: 127 2x java.lang.StringIndexOutOfBoundsException: String index out of range: 126 1x java.lang.StringIndexOutOfBoundsException: String index out of range: 123 Rest of stacktrace is identical in all occurences. I wondered if it doesn't like spaces in File paths. p In addition -- Tomy t.petro...@inet.hr - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org signature.asc Description: OpenPGP digital signature
Re: Webapp reloading issue and intermittent 404 errors
Pid wrote: .. I wondered if it doesn't like spaces in File paths. I did not want to ask that question. Good that someone did. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Webapp reloading issue and intermittent 404 errors
From: Tomislav Petrović [mailto:t.petro...@inet.hr]
Subject: Re: Webapp reloading issue and intermittent 404 errors
Don't know have to check with customer, but actual index varies in each
occurrence of stack trace, sometimes it is even -1.
Here's the code of interest:
127 while (true) {
128 int index = normalized.indexOf(//);
129 if (index 0)
130 break;
131 normalized = normalized.substring(0, index) +
132 normalized.substring(index + 1);
133 }
Given the test on lines 129-130, it is impossible to have a -1 at line 131 -
unless there's a JVM bug.
You could try running with a -client option instead of -server (if it's
available on your platform), or create a .hotspot_compiler file in the Tomcat
current directory containing this line:
exclude org.apache.catalina.util.RequestUtil normalize
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Webapp reloading issue and intermittent 404 errors
2010/6/30 Tomislav Petrović t.petro...@inet.hr: Pid said on 30.6.2010 13:06: On 30/06/2010 11:59, Tomislav Petrović wrote: Context path=/some_webapp docBase=/some_webapp debug=0 reloadable=true crossContext=true ResourceLink global=jdbc/SomeDB name=jdbc/SomeDB type=javax.sql.DataSource / ResourceLink global=jdbc/SomeDB2 name=jdbc/SomeDB2 type=javax.sql.DataSource / If these are the actual values then it's a miracle it's working at all. Only app name/paths and jdbs names have been changed to dummy values. Instead of defining it there, remove the debug, path and docBase attributes and put it in some_webapp/META-INF/context.xml Tomcat will work out the rest automatically. (...) And do you really think this would solve my initial problem, or? As I mentioned in https://issues.apache.org/bugzilla/show_bug.cgi?id=49488#c2 having double slash in a path is unusual. Context path=/some_webapp docBase=/some_webapp probably should be Context path=/some_webapp docBase=some_webapp but it would be much better to place this context definition in a separate file, as was already mentioned. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Webapp reloading issue and intermittent 404 errors
From: Caldarale, Charles R Subject: RE: Webapp reloading issue and intermittent 404 errors Given the test on lines 129-130, it is impossible to have a -1 at line 131 - unless there's a JVM bug. 6u21 was just released tonight, so you might give that a shot and see if the problem has been addressed. Included in 6u21 are fixes for the problems described here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6875866 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6935535 Both seem to have a lot in common with the issue under discussion. There's another String-related fix in the bug list, but the details are not retrievable at the moment: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6948602 - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Webapp reloading issue and intermittent 404 errors
2010/7/8 Caldarale, Charles R chuck.caldar...@unisys.com: From: Caldarale, Charles R Subject: RE: Webapp reloading issue and intermittent 404 errors Given the test on lines 129-130, it is impossible to have a -1 at line 131 - unless there's a JVM bug. 6u21 was just released tonight, so you might give that a shot and see if the problem has been addressed. Included in 6u21 are fixes for the problems described here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6875866 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6935535 Both seem to have a lot in common with the issue under discussion. There's another String-related fix in the bug list, but the details are not retrievable at the moment: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6948602 Oh. It matches this case. The issue names mention SSE 4.2, so it supposedly happens only on certain families of Intel CPUs. http://en.wikipedia.org/wiki/SSE4 Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Webapp reloading issue and intermittent 404 errors
From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Subject: Re: Webapp reloading issue and intermittent 404 errors Oh. It matches this case. All three seem to. The issue names mention SSE 4.2, so it supposedly happens only on certain families of Intel CPUs. Right - just Nehalem chips (i7). The OP didn't say what the hardware was; even if it's not an i7, the fixes might address the problem, since Sun often doesn't give complete descriptions of fixes. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Webapp reloading issue and intermittent 404 errors
Pid said on 29.6.2010 23:20: On 29/06/2010 19:29, Konstantin Kolinko wrote: 2010/6/29 Caldarale, Charles Rchuck.caldar...@unisys.com: From: Tomislav Petrović [mailto:t.petro...@inet.hr] Subject: Re: Webapp reloading issue and intermittent 404 errors org.apache.catalina.util.RequestUtil.normalize(RequestUtil.java:131) IIRC, you are not the first person to report an exception at this spot in the code. (Unfortunately, I can't locate the other thread at the moment, but it was fairly recent.) That was https://issues.apache.org/bugzilla/show_bug.cgi?id=49488 The code in question has been run through many test cases, inside and outside of Tomcat, and does not appear to contain any errors (although it could be slightly more efficient). Weird. I couldn't find that in bugzilla. Anyhow, it's Windows this time too. Tomislav: where is the Tomcat installation on the filing system, and where are the webapps being deployed from, if not tomcat/webapps? What type of filing system is it? Also, did you manage to get hold of the config files yet? Good news is when I put reloadable=false on context problem (both of them, intermittent 404 too) went away, so I have workaround. Bad news is server is going into production so no messing with it no more. Yes, this is same bug as one in bugzilla, don't know if what triggered is same. Here is detailed info (my first suspect is Resources in server.xml but this is only my guess. Tomcat is Apache Tomcat/6.0.24, running without tcnative-1.dll Java version is: 1.6 update 18 Windows version: 2003 SP2 (32 bit) NTFS file system is used, Tomcat is installed in D:\Program Files\Apache Software Foundation\Tomcat 6.0 folder, webapp is in D:\Program Files\Apache Software Foundation\Tomcat 6.0\webapps\some_name folder. This is content of server.xml, I believe that all other conf files are at their default values (except for pwd in users file), feel free to ask for any other conf file. ?xml version='1.0' encoding='utf-8'? Server port=8005 shutdown=SHUTDOWN Listener className=org.apache.catalina.core.AprLifecycleListener SSLEngine=on / Listener className=org.apache.catalina.core.JasperListener / Listener className=org.apache.catalina.core.JreMemoryLeakPreventionListener / Listener className=org.apache.catalina.mbeans.ServerLifecycleListener / Listener className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener / GlobalNamingResources Resource name=UserDatabase auth=Container type=org.apache.catalina.UserDatabase description=User database that can be updated and saved factory=org.apache.catalina.users.MemoryUserDatabaseFactory pathname=conf/tomcat-users.xml / Resource name=jdbc/SomeDB auth=Container type=javax.sql.DataSource maxActive=48 maxIdle=10 maxWait=1 driverClassName=com.microsoft.sqlserver.jdbc.SQLServerDriver username=auser password=* url=jdbc:sqlserver://**.***.*.**:1433;databaseName=SomeName;loginTimeout=5 removeAbandoned=true removeAbandonedTimeout=60 logAbandoned=true validationQuery=SELECT 1/ Resource name=jdbc/SomeDB2 auth=Container type=javax.sql.DataSource maxActive=48 maxIdle=10 maxWait=1 driverClassName=com.microsoft.sqlserver.jdbc.SQLServerDriver username=auser2 password=** url=jdbc:sqlserver://**.***.*.**:1433;databaseName=SomeName2 removeAbandoned=true removeAbandonedTimeout=60 logAbandoned=true validationQuery=SELECT 1/ /GlobalNamingResources Service name=Catalina Connector port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / Connector port=8009 protocol=AJP/1.3 redirectPort=8443 / Engine name=Catalina defaultHost=localhost Realm className=org.apache.catalina.realm.UserDatabaseRealm resourceName=UserDatabase/ Host name=localhost appBase=webapps unpackWARs=true autoDeploy=true xmlValidation=false xmlNamespaceAware=false Valve className=org.apache.catalina.valves.AccessLogValve directory=logs prefix=localhost_access_log. suffix=.txt pattern=common resolveHosts=false/ Context path=/some_webapp docBase=/some_webapp debug=0 reloadable=true crossContext=true ResourceLink global=jdbc/SomeDB name=jdbc/SomeDB type=javax.sql.DataSource / ResourceLink global=jdbc/SomeDB2 name=jdbc/SomeDB2 type=javax.sql.DataSource / /Context /Host /Engine /Service /Server Let me know if I can provide any more info or update
Re: Webapp reloading issue and intermittent 404 errors
Tomislav Petrović said on 30.6.2010 12:59: Pid said on 29.6.2010 23:20: On 29/06/2010 19:29, Konstantin Kolinko wrote: 2010/6/29 Caldarale, Charles Rchuck.caldar...@unisys.com: From: Tomislav Petrović [mailto:t.petro...@inet.hr] Subject: Re: Webapp reloading issue and intermittent 404 errors org.apache.catalina.util.RequestUtil.normalize(RequestUtil.java:131) IIRC, you are not the first person to report an exception at this spot in the code. (Unfortunately, I can't locate the other thread at the moment, but it was fairly recent.) That was https://issues.apache.org/bugzilla/show_bug.cgi?id=49488 The code in question has been run through many test cases, inside and outside of Tomcat, and does not appear to contain any errors (although it could be slightly more efficient). Weird. I couldn't find that in bugzilla. Anyhow, it's Windows this time too. Tomislav: where is the Tomcat installation on the filing system, and where are the webapps being deployed from, if not tomcat/webapps? What type of filing system is it? Also, did you manage to get hold of the config files yet? Good news is when I put reloadable=false on context problem (both of them, intermittent 404 too) went away, so I have workaround. Bad news is server is going into production so no messing with it no more. Yes, this is same bug as one in bugzilla, don't know if what triggered is same. Here is detailed info (my first suspect isResources in server.xml but this is only my guess. Tomcat is Apache Tomcat/6.0.24, running without tcnative-1.dll Java version is: 1.6 update 18 Windows version: 2003 SP2 (32 bit) NTFS file system is used, Tomcat is installed in D:\Program Files\Apache Software Foundation\Tomcat 6.0 folder, webapp is in D:\Program Files\Apache Software Foundation\Tomcat 6.0\webapps\some_name folder. This is content of server.xml, I believe that all other conf files are at their default values (except for pwd in users file), feel free to ask for any other conf file. ?xml version='1.0' encoding='utf-8'? Server port=8005 shutdown=SHUTDOWN Listener className=org.apache.catalina.core.AprLifecycleListener SSLEngine=on / Listener className=org.apache.catalina.core.JasperListener / Listener className=org.apache.catalina.core.JreMemoryLeakPreventionListener / Listener className=org.apache.catalina.mbeans.ServerLifecycleListener / Listener className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener / GlobalNamingResources Resource name=UserDatabase auth=Container type=org.apache.catalina.UserDatabase description=User database that can be updated and saved factory=org.apache.catalina.users.MemoryUserDatabaseFactory pathname=conf/tomcat-users.xml / Resource name=jdbc/SomeDB auth=Container type=javax.sql.DataSource maxActive=48 maxIdle=10 maxWait=1 driverClassName=com.microsoft.sqlserver.jdbc.SQLServerDriver username=auser password=* url=jdbc:sqlserver://**.***.*.**:1433;databaseName=SomeName;loginTimeout=5 removeAbandoned=true removeAbandonedTimeout=60 logAbandoned=true validationQuery=SELECT 1/ Resource name=jdbc/SomeDB2 auth=Container type=javax.sql.DataSource maxActive=48 maxIdle=10 maxWait=1 driverClassName=com.microsoft.sqlserver.jdbc.SQLServerDriver username=auser2 password=** url=jdbc:sqlserver://**.***.*.**:1433;databaseName=SomeName2 removeAbandoned=true removeAbandonedTimeout=60 logAbandoned=true validationQuery=SELECT 1/ /GlobalNamingResources Service name=Catalina Connector port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / Connector port=8009 protocol=AJP/1.3 redirectPort=8443 / Engine name=Catalina defaultHost=localhost Realm className=org.apache.catalina.realm.UserDatabaseRealm resourceName=UserDatabase/ Host name=localhost appBase=webapps unpackWARs=true autoDeploy=true xmlValidation=false xmlNamespaceAware=false Valve className=org.apache.catalina.valves.AccessLogValve directory=logs prefix=localhost_access_log. suffix=.txt pattern=common resolveHosts=false/ Context path=/some_webapp docBase=/some_webapp debug=0 reloadable=true crossContext=true ResourceLink global=jdbc/SomeDB name=jdbc/SomeDB type=javax.sql.DataSource / ResourceLink global=jdbc/SomeDB2 name=jdbc/SomeDB2 type=javax.sql.DataSource / /Context /Host /Engine /Service /Server Let me know if I
Re: Webapp reloading issue and intermittent 404 errors
On 30/06/2010 11:59, Tomislav Petrović wrote: Context path=/some_webapp docBase=/some_webapp debug=0 reloadable=true crossContext=true ResourceLink global=jdbc/SomeDB name=jdbc/SomeDB type=javax.sql.DataSource / ResourceLink global=jdbc/SomeDB2 name=jdbc/SomeDB2 type=javax.sql.DataSource / If these are the actual values then it's a miracle it's working at all. Instead of defining it there, remove the debug, path and docBase attributes and put it in some_webapp/META-INF/context.xml Tomcat will work out the rest automatically. p signature.asc Description: OpenPGP digital signature
Re: Webapp reloading issue and intermittent 404 errors
On 30/06/2010 12:04, Tomislav Petrović wrote: Tomislav Petrović said on 30.6.2010 12:59: Pid said on 29.6.2010 23:20: On 29/06/2010 19:29, Konstantin Kolinko wrote: 2010/6/29 Caldarale, Charles Rchuck.caldar...@unisys.com: From: Tomislav Petrović [mailto:t.petro...@inet.hr] Subject: Re: Webapp reloading issue and intermittent 404 errors org.apache.catalina.util.RequestUtil.normalize(RequestUtil.java:131) IIRC, you are not the first person to report an exception at this spot in the code. (Unfortunately, I can't locate the other thread at the moment, but it was fairly recent.) That was https://issues.apache.org/bugzilla/show_bug.cgi?id=49488 The code in question has been run through many test cases, inside and outside of Tomcat, and does not appear to contain any errors (although it could be slightly more efficient). Weird. I couldn't find that in bugzilla. Anyhow, it's Windows this time too. Tomislav: where is the Tomcat installation on the filing system, and where are the webapps being deployed from, if not tomcat/webapps? What type of filing system is it? Also, did you manage to get hold of the config files yet? Good news is when I put reloadable=false on context problem (both of them, intermittent 404 too) went away, so I have workaround. Bad news is server is going into production so no messing with it no more. Yes, this is same bug as one in bugzilla, don't know if what triggered is same. Here is detailed info (my first suspect isResources in server.xml but this is only my guess. Tomcat is Apache Tomcat/6.0.24, running without tcnative-1.dll Java version is: 1.6 update 18 Windows version: 2003 SP2 (32 bit) NTFS file system is used, Tomcat is installed in D:\Program Files\Apache Software Foundation\Tomcat 6.0 folder, webapp is in D:\Program Files\Apache Software Foundation\Tomcat 6.0\webapps\some_name folder. This is content of server.xml, I believe that all other conf files are at their default values (except for pwd in users file), feel free to ask for any other conf file. ?xml version='1.0' encoding='utf-8'? Server port=8005 shutdown=SHUTDOWN Listener className=org.apache.catalina.core.AprLifecycleListener SSLEngine=on / Listener className=org.apache.catalina.core.JasperListener / Listener className=org.apache.catalina.core.JreMemoryLeakPreventionListener / Listener className=org.apache.catalina.mbeans.ServerLifecycleListener / Listener className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener / GlobalNamingResources Resource name=UserDatabase auth=Container type=org.apache.catalina.UserDatabase description=User database that can be updated and saved factory=org.apache.catalina.users.MemoryUserDatabaseFactory pathname=conf/tomcat-users.xml / Resource name=jdbc/SomeDB auth=Container type=javax.sql.DataSource maxActive=48 maxIdle=10 maxWait=1 driverClassName=com.microsoft.sqlserver.jdbc.SQLServerDriver username=auser password=* url=jdbc:sqlserver://**.***.*.**:1433;databaseName=SomeName;loginTimeout=5 removeAbandoned=true removeAbandonedTimeout=60 logAbandoned=true validationQuery=SELECT 1/ Resource name=jdbc/SomeDB2 auth=Container type=javax.sql.DataSource maxActive=48 maxIdle=10 maxWait=1 driverClassName=com.microsoft.sqlserver.jdbc.SQLServerDriver username=auser2 password=** url=jdbc:sqlserver://**.***.*.**:1433;databaseName=SomeName2 removeAbandoned=true removeAbandonedTimeout=60 logAbandoned=true validationQuery=SELECT 1/ /GlobalNamingResources Service name=Catalina Connector port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / Connector port=8009 protocol=AJP/1.3 redirectPort=8443 / Engine name=Catalina defaultHost=localhost Realm className=org.apache.catalina.realm.UserDatabaseRealm resourceName=UserDatabase/ Host name=localhost appBase=webapps unpackWARs=true autoDeploy=true xmlValidation=false xmlNamespaceAware=false Valve className=org.apache.catalina.valves.AccessLogValve directory=logs prefix=localhost_access_log. suffix=.txt pattern=common resolveHosts=false/ Context path=/some_webapp docBase=/some_webapp debug=0 reloadable=true crossContext=true ResourceLink global=jdbc/SomeDB name=jdbc/SomeDB type=javax.sql.DataSource / ResourceLink global=jdbc/SomeDB2 name=jdbc/SomeDB2 type=javax.sql.DataSource / /Context /Host /Engine /Service /Server Let me know if I can provide any more info or update bugzilla (don't have acc
Re: Webapp reloading issue and intermittent 404 errors
Pid said on 30.6.2010 13:12: On 30/06/2010 12:04, Tomislav Petrović wrote: Tomislav Petrović said on 30.6.2010 12:59: Pid said on 29.6.2010 23:20: On 29/06/2010 19:29, Konstantin Kolinko wrote: 2010/6/29 Caldarale, Charles Rchuck.caldar...@unisys.com: From: Tomislav Petrović [mailto:t.petro...@inet.hr] Subject: Re: Webapp reloading issue and intermittent 404 errors org.apache.catalina.util.RequestUtil.normalize(RequestUtil.java:131) IIRC, you are not the first person to report an exception at this spot in the code. (Unfortunately, I can't locate the other thread at the moment, but it was fairly recent.) That was https://issues.apache.org/bugzilla/show_bug.cgi?id=49488 The code in question has been run through many test cases, inside and outside of Tomcat, and does not appear to contain any errors (although it could be slightly more efficient). Weird. I couldn't find that in bugzilla. Anyhow, it's Windows this time too. Tomislav: where is the Tomcat installation on the filing system, and where are the webapps being deployed from, if not tomcat/webapps? What type of filing system is it? Also, did you manage to get hold of the config files yet? Good news is when I put reloadable=false on context problem (both of them, intermittent 404 too) went away, so I have workaround. Bad news is server is going into production so no messing with it no more. Yes, this is same bug as one in bugzilla, don't know if what triggered is same. Here is detailed info (my first suspect isResources in server.xml but this is only my guess. Tomcat is Apache Tomcat/6.0.24, running without tcnative-1.dll Java version is: 1.6 update 18 Windows version: 2003 SP2 (32 bit) NTFS file system is used, Tomcat is installed in D:\Program Files\Apache Software Foundation\Tomcat 6.0 folder, webapp is in D:\Program Files\Apache Software Foundation\Tomcat 6.0\webapps\some_name folder. This is content of server.xml, I believe that all other conf files are at their default values (except for pwd in users file), feel free to ask for any other conf file. ?xml version='1.0' encoding='utf-8'? Server port=8005 shutdown=SHUTDOWN Listener className=org.apache.catalina.core.AprLifecycleListener SSLEngine=on / Listener className=org.apache.catalina.core.JasperListener / Listener className=org.apache.catalina.core.JreMemoryLeakPreventionListener / Listener className=org.apache.catalina.mbeans.ServerLifecycleListener / Listener className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener / GlobalNamingResources Resource name=UserDatabase auth=Container type=org.apache.catalina.UserDatabase description=User database that can be updated and saved factory=org.apache.catalina.users.MemoryUserDatabaseFactory pathname=conf/tomcat-users.xml / Resource name=jdbc/SomeDB auth=Container type=javax.sql.DataSource maxActive=48 maxIdle=10 maxWait=1 driverClassName=com.microsoft.sqlserver.jdbc.SQLServerDriver username=auser password=* url=jdbc:sqlserver://**.***.*.**:1433;databaseName=SomeName;loginTimeout=5 removeAbandoned=true removeAbandonedTimeout=60 logAbandoned=true validationQuery=SELECT 1/ Resource name=jdbc/SomeDB2 auth=Container type=javax.sql.DataSource maxActive=48 maxIdle=10 maxWait=1 driverClassName=com.microsoft.sqlserver.jdbc.SQLServerDriver username=auser2 password=** url=jdbc:sqlserver://**.***.*.**:1433;databaseName=SomeName2 removeAbandoned=true removeAbandonedTimeout=60 logAbandoned=true validationQuery=SELECT 1/ /GlobalNamingResources Service name=Catalina Connector port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / Connector port=8009 protocol=AJP/1.3 redirectPort=8443 / Engine name=Catalina defaultHost=localhost Realm className=org.apache.catalina.realm.UserDatabaseRealm resourceName=UserDatabase/ Host name=localhost appBase=webapps unpackWARs=true autoDeploy=true xmlValidation=false xmlNamespaceAware=false Valve className=org.apache.catalina.valves.AccessLogValve directory=logs prefix=localhost_access_log. suffix=.txt pattern=common resolveHosts=false/ Context path=/some_webapp docBase=/some_webapp debug=0 reloadable=true crossContext=true ResourceLink global=jdbc/SomeDB name=jdbc/SomeDB type=javax.sql.DataSource / ResourceLink global=jdbc/SomeDB2 name=jdbc/SomeDB2 type=javax.sql.DataSource / /Context /Host /Engine /Service /Server Let me know if I can provide any more info or update bugzilla (don't have acc but can open). Thanks to all for your
Re: Webapp reloading issue and intermittent 404 errors
Pid said on 30.6.2010 13:06: On 30/06/2010 11:59, Tomislav Petrović wrote: Context path=/some_webapp docBase=/some_webapp debug=0 reloadable=true crossContext=true ResourceLink global=jdbc/SomeDB name=jdbc/SomeDB type=javax.sql.DataSource / ResourceLink global=jdbc/SomeDB2 name=jdbc/SomeDB2 type=javax.sql.DataSource / If these are the actual values then it's a miracle it's working at all. Only app name/paths and jdbs names have been changed to dummy values. Instead of defining it there, remove the debug, path and docBase attributes and put it in some_webapp/META-INF/context.xml Tomcat will work out the rest automatically. Sorry for newbie question. Can you post me how my new server.xml should look and how some_webapp/META-INF/context.xml should look. Also would apprecite link to right documentation why it should be that way, thanks. And do you really think this would solve my initial problem, or? -- Tomy t.petro...@inet.hr - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Webapp reloading issue and intermittent 404 errors
From: Pid [mailto:p...@pidster.com] Subject: Re: Webapp reloading issue and intermittent 404 errors JVM: have to check whether server or client, not sure at the moment. Server, one would hope. Probably not - it's a 32-bit Windows, and you have to build your own JVM if you want a server version for that. Did you find out the exact version? He stated 6u18. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Webapp reloading issue and intermittent 404 errors
On 30/06/2010 13:38, Caldarale, Charles R wrote: From: Pid [mailto:p...@pidster.com] Subject: Re: Webapp reloading issue and intermittent 404 errors JVM: have to check whether server or client, not sure at the moment. Server, one would hope. Probably not - it's a 32-bit Windows, and you have to build your own JVM if you want a server version for that. Really?! I thought later versions had the server JVM too (for some reason I now can't put my finger on). Did you find out the exact version? He stated 6u18. I spotted it after I sent. Doh. p - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org signature.asc Description: OpenPGP digital signature
Re: Webapp reloading issue and intermittent 404 errors
On 6/30/2010 8:41 AM, Pid wrote: On 30/06/2010 13:38, Caldarale, Charles R wrote: From: Pid [mailto:p...@pidster.com] Subject: Re: Webapp reloading issue and intermittent 404 errors JVM: have to check whether server or client, not sure at the moment. Server, one would hope. Probably not - it's a 32-bit Windows, and you have to build your own JVM if you want a server version for that. Really?! I thought later versions had the server JVM too (for some reason I now can't put my finger on). They do; I've been using the server version for quite a while on32-bit windows (the performance jumps were huge for some of my apps), and have never built a JVM myself. D - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Webapp reloading issue and intermittent 404 errors
From: Pid [mailto:p...@pidster.com] Subject: Re: Webapp reloading issue and intermittent 404 errors Probably not - it's a 32-bit Windows, and you have to build your own JVM if you want a server version for that. Really?! I thought later versions had the server JVM too (for some reason I now can't put my finger on). You're right - I stand corrected; there are both server and client DLLs in the 32-bit download. The 64-bit one continues to have only the server version. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Webapp reloading issue and intermittent 404 errors
On 6/30/2010 8:38 AM, Caldarale, Charles R wrote: From: Pid [mailto:p...@pidster.com] Subject: Re: Webapp reloading issue and intermittent 404 errors JVM: have to check whether server or client, not sure at the moment. Server, one would hope. Probably not - it's a 32-bit Windows, and you have to build your own JVM if you want a server version for that. I think you've made your first mistake here, Chuck (at least the first one that I know enough about to catch!!). If you download the jdk from Sun, you can get a server version of the jvm for Win32. I've been using one for months for the performance gain in one of my apps. D - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Webapp reloading issue and intermittent 404 errors
From: Tomislav Petrović [mailto:t.petro...@inet.hr] Subject: Re: Webapp reloading issue and intermittent 404 errors Do you actually have an 'endorsed' directory in your Tomcat installation? What's in it if you do? No I don't, this folder doesn't exist, will have to investigate who put it in here. Tomcat did, during the service installation. Perfectly normal, but rarely useful. -XX:NewSize=16m -XX:MaxNewSize=16m I would definitely remove both NewSize settings. Not associated with the problem at hand, but probably detrimental to performance. The JVM does a decent job of adjusting the NewSize value as needed for the current workload. Can you please point me in some doc documentation why it isn't ok cause we had better experience with incgc than default one on our load tests. -Xincgc used to utilize the train GC model - which was a real dog and not capable of using multiple threads. For current JVMs, -Xincgc triggers the concurrent (low pause) collector. This will generally result in slightly less throughput, but much less stoppage time and somewhat less variation in response times. If you're happy with it, leave it. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Webapp reloading issue and intermittent 404 errors
On 30/06/2010 12:45, Tomislav Petrović wrote: Pid said on 30.6.2010 13:12: On 30/06/2010 12:04, Tomislav Petrović wrote: Tomislav Petrović said on 30.6.2010 12:59: Pid said on 29.6.2010 23:20: On 29/06/2010 19:29, Konstantin Kolinko wrote: 2010/6/29 Caldarale, Charles Rchuck.caldar...@unisys.com: From: Tomislav Petrović [mailto:t.petro...@inet.hr] Subject: Re: Webapp reloading issue and intermittent 404 errors org.apache.catalina.util.RequestUtil.normalize(RequestUtil.java:131) IIRC, you are not the first person to report an exception at this spot in the code. (Unfortunately, I can't locate the other thread at the moment, but it was fairly recent.) That was https://issues.apache.org/bugzilla/show_bug.cgi?id=49488 The code in question has been run through many test cases, inside and outside of Tomcat, and does not appear to contain any errors (although it could be slightly more efficient). Weird. I couldn't find that in bugzilla. Anyhow, it's Windows this time too. Tomislav: where is the Tomcat installation on the filing system, and where are the webapps being deployed from, if not tomcat/webapps? What type of filing system is it? Also, did you manage to get hold of the config files yet? Good news is when I put reloadable=false on context problem (both of them, intermittent 404 too) went away, so I have workaround. Bad news is server is going into production so no messing with it no more. Yes, this is same bug as one in bugzilla, don't know if what triggered is same. Here is detailed info (my first suspect isResources in server.xml but this is only my guess. Tomcat is Apache Tomcat/6.0.24, running without tcnative-1.dll Java version is: 1.6 update 18 Windows version: 2003 SP2 (32 bit) NTFS file system is used, Tomcat is installed in D:\Program Files\Apache Software Foundation\Tomcat 6.0 folder, webapp is in D:\Program Files\Apache Software Foundation\Tomcat 6.0\webapps\some_name folder. This is content of server.xml, I believe that all other conf files are at their default values (except for pwd in users file), feel free to ask for any other conf file. ?xml version='1.0' encoding='utf-8'? Server port=8005 shutdown=SHUTDOWN Listener className=org.apache.catalina.core.AprLifecycleListener SSLEngine=on / Listener className=org.apache.catalina.core.JasperListener / Listener className=org.apache.catalina.core.JreMemoryLeakPreventionListener / Listener className=org.apache.catalina.mbeans.ServerLifecycleListener / Listener className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener / GlobalNamingResources Resource name=UserDatabase auth=Container type=org.apache.catalina.UserDatabase description=User database that can be updated and saved factory=org.apache.catalina.users.MemoryUserDatabaseFactory pathname=conf/tomcat-users.xml / Resource name=jdbc/SomeDB auth=Container type=javax.sql.DataSource maxActive=48 maxIdle=10 maxWait=1 driverClassName=com.microsoft.sqlserver.jdbc.SQLServerDriver username=auser password=* url=jdbc:sqlserver://**.***.*.**:1433;databaseName=SomeName;loginTimeout=5 removeAbandoned=true removeAbandonedTimeout=60 logAbandoned=true validationQuery=SELECT 1/ Resource name=jdbc/SomeDB2 auth=Container type=javax.sql.DataSource maxActive=48 maxIdle=10 maxWait=1 driverClassName=com.microsoft.sqlserver.jdbc.SQLServerDriver username=auser2 password=** url=jdbc:sqlserver://**.***.*.**:1433;databaseName=SomeName2 removeAbandoned=true removeAbandonedTimeout=60 logAbandoned=true validationQuery=SELECT 1/ /GlobalNamingResources Service name=Catalina Connector port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / Connector port=8009 protocol=AJP/1.3 redirectPort=8443 / Engine name=Catalina defaultHost=localhost Realm className=org.apache.catalina.realm.UserDatabaseRealm resourceName=UserDatabase/ Host name=localhost appBase=webapps unpackWARs=true autoDeploy=true xmlValidation=false xmlNamespaceAware=false Valve className=org.apache.catalina.valves.AccessLogValve directory=logs prefix=localhost_access_log. suffix=.txt pattern=common resolveHosts=false/ Context path=/some_webapp docBase=/some_webapp debug=0 reloadable=true crossContext=true ResourceLink global=jdbc/SomeDB name=jdbc/SomeDB type=javax.sql.DataSource / ResourceLink global=jdbc/SomeDB2 name=jdbc/SomeDB2 type=javax.sql.DataSource / /Context /Host
RE: Webapp reloading issue and intermittent 404 errors
From: Tomislav Petrović [mailto:t.petro...@inet.hr] Subject: Re: Webapp reloading issue and intermittent 404 errors Can you post me how my new server.xml should look and how some_webapp/META-INF/context.xml should look. Just remove all Context elements from server.xml - it's bad practice to have them there, since it violates the principle of self-contained webapps, and making any changes require restarting Tomcat, not just the webapp. Context reloadable=true crossContext=true ResourceLink global=jdbc/SomeDB name=jdbc/SomeDB type=javax.sql.DataSource / ResourceLink global=jdbc/SomeDB2 name=jdbc/SomeDB2 type=javax.sql.DataSource / /Context Also would apprecite link to right documentation why it should be that way, thanks. http://tomcat.apache.org/tomcat-6.0-doc/config/context.html And do you really think this would solve my initial problem, or? Nope. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Webapp reloading issue and intermittent 404 errors
On 30/06/2010 13:07, Tomislav Petrović wrote: Pid said on 30.6.2010 13:06: On 30/06/2010 11:59, Tomislav Petrović wrote: Context path=/some_webapp docBase=/some_webapp debug=0 reloadable=true crossContext=true ResourceLink global=jdbc/SomeDB name=jdbc/SomeDB type=javax.sql.DataSource / ResourceLink global=jdbc/SomeDB2 name=jdbc/SomeDB2 type=javax.sql.DataSource / If these are the actual values then it's a miracle it's working at all. Only app name/paths and jdbs names have been changed to dummy values. Instead of defining it there, remove the debug, path and docBase attributes and put it in some_webapp/META-INF/context.xml Tomcat will work out the rest automatically. Sorry for newbie question. Can you post me how my new server.xml should look and how some_webapp/META-INF/context.xml should look. Nope. Just do the following, it's not complicated: 0. Stop Tomcat. 1. Create a file (in each app) myappname/META-INF/context.xml. 2. Copy the entire Context definition it's sub-elements into the file 3. Remove the 3 attributes I named (debug is deprecated, path docBase aren't used here) 4. Completely delete the Context definitions from server.xml. 5. Start Tomcat. Also would apprecite link to right documentation why it should be that way, thanks. It's in the same place as the rest of the documentation: http://tomcat.apache.org/tomcat-6.0-doc/config/context.html And do you really think this would solve my initial problem, or? Maybe, maybe not, but if we eliminate all the possible problems, we'll know it's not one of those. p signature.asc Description: OpenPGP digital signature
Re: Webapp reloading issue and intermittent 404 errors
Pid said on 30.6.2010 15:05: On 30/06/2010 13:07, Tomislav Petrović wrote: Pid said on 30.6.2010 13:06: On 30/06/2010 11:59, Tomislav Petrović wrote: Context path=/some_webapp docBase=/some_webapp debug=0 reloadable=true crossContext=true ResourceLink global=jdbc/SomeDB name=jdbc/SomeDB type=javax.sql.DataSource / ResourceLink global=jdbc/SomeDB2 name=jdbc/SomeDB2 type=javax.sql.DataSource / If these are the actual values then it's a miracle it's working at all. Only app name/paths and jdbs names have been changed to dummy values. Instead of defining it there, remove the debug, path and docBase attributes and put it in some_webapp/META-INF/context.xml Tomcat will work out the rest automatically. Sorry for newbie question. Can you post me how my new server.xml should look and how some_webapp/META-INF/context.xml should look. Nope. Just do the following, it's not complicated: 0. Stop Tomcat. 1. Create a file (in each app) myappname/META-INF/context.xml. 2. Copy the entire Context definition it's sub-elements into the file 3. Remove the 3 attributes I named (debug is deprecated, path docBase aren't used here) 4. Completely delete the Context definitions from server.xml. 5. Start Tomcat. Also would apprecite link to right documentation why it should be that way, thanks. It's in the same place as the rest of the documentation: http://tomcat.apache.org/tomcat-6.0-doc/config/context.html And do you really think this would solve my initial problem, or? Maybe, maybe not, but if we eliminate all the possible problems, we'll know it's not one of those. All advise them to do so in future installations but can't change that on this particular server anymore. Since workaround works server is going into production and hence freezed for all changes :(. -- Tomy t.petro...@inet.hr - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Webapp reloading issue and intermittent 404 errors
Caldarale, Charles R said on 30.6.2010 15:03: From: Tomislav Petrović [mailto:t.petro...@inet.hr] Subject: Re: Webapp reloading issue and intermittent 404 errors Can you post me how my new server.xml should look and how some_webapp/META-INF/context.xml should look. Just remove allContext elements from server.xml - it's bad practice to have them there, since it violates the principle of self-contained webapps, and making any changes require restarting Tomcat, not just the webapp. Context reloadable=true crossContext=true ResourceLink global=jdbc/SomeDB name=jdbc/SomeDB type=javax.sql.DataSource / ResourceLink global=jdbc/SomeDB2 name=jdbc/SomeDB2 type=javax.sql.DataSource / /Context Also would apprecite link to right documentation why it should be that way, thanks. http://tomcat.apache.org/tomcat-6.0-doc/config/context.html And do you really think this would solve my initial problem, or? Nope. Thanks for info, but any idea what caused original problem? And if I can provide any additional info to help resolve it. Unfortunately can't test it anymore since server where it happened (doesn't anymore with reloadable=false) is going into production. -- Tomy t.petro...@inet.hr - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Webapp reloading issue and intermittent 404 errors
From: Tomislav Petrović [mailto:t.petro...@inet.hr] Subject: Re: Webapp reloading issue and intermittent 404 errors any idea what caused original problem? And if I can provide any additional info to help resolve it. Again, we believe this to be a JVM bug, not specific to Tomcat. Since it's so infrequent, it's hard to pin down. Unfortunately, Sun/Oracle's changelog probably won't be explicit enough to tell us if the problem has been addressed in a later JVM. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Webapp reloading issue and intermittent 404 errors
Forgot to say: Tomcat service is started with following parameters: JVM: have to check whether server or client, not sure at the moment. Server, one would hope. Did you find out the exact version? Yup JVM path for tomcat is ..\jdk1.6.0_18\jre\bin\server\jvm.dll, so Java 6 update 18 server. -- Tomy t.petro...@inet.hr - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Webapp reloading issue and intermittent 404 errors
Tomislav Petrović said on 28.6.2010 15:46:
Caldarale, Charles R said on 28.6.2010 15:32:
Seems to me it is related to web app reloading but this
is my blind guess.
What makes you suspicious that reloading is going on?
Just my VERY BIG AND BLIND guess based on classes involved in stack trace.
This is my dissection of problematic stacktrace using my limited Java
knowledge and Tomcat sources.
Stacktrace written in reverse way to follow code flow more easily.
at java.lang.Thread.run(Thread.java:619)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1590)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1610)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1610)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1601)
Background thread which periodically calls backgroundProcess on container and
its children, I believe it is
used to determine wether app needs to be reloaded (make sense to me that
something periodically needs to check
wether app needs to be reloaded).
at
org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1309)
at
org.apache.catalina.loader.WebappLoader.backgroundProcess(WebappLoader.java:398)
at
org.apache.catalina.loader.WebappLoader.modified(WebappLoader.java:477)
at
org.apache.catalina.loader.WebappClassLoader.modified(WebappClassLoader.java:822)
modified is called in order to find if one or more classes or resources been
modified so that a reload is appropriate?,
at least that is what the JavaDoc comment says.
at
org.apache.naming.resources.ProxyDirContext.getAttributes(ProxyDirContext.java:840)
at
org.apache.naming.resources.BaseDirContext.getAttributes(BaseDirContext.java:747)
at
org.apache.naming.resources.FileDirContext.getAttributes(FileDirContext.java:429)
Just forwards call to more appropriate classes up to here.
at
org.apache.naming.resources.FileDirContext.file(FileDirContext.java:811)
Here a File object of Return a File object representing the specified
normalized
context-relative path if it exists and is readable is created, however name
given to it
chokes up normalize, it seems.
at
org.apache.naming.resources.FileDirContext.normalize(FileDirContext.java:771)
at org.apache.catalina.util.RequestUtil.normalize(RequestUtil.java:131)
This is problematic code (part of normalize method):
// Resolve occurrences of // in the normalized path
while (true) {
int index = normalized.indexOf(//);
if (index 0)
break;
normalized = normalized.substring(0, index) +
normalized.substring(index + 1);
}
Seems to me code assumes that if it founds // in a string then this // is
not at the
end of the string (has to have something behind it). In general case this
sounds like a
bug to me (however I am not expert here and don't know from where filename
comes and how
it should be written).
So if anyone can tell me form where a name (filename) given to normalize comes
(I assume
it is something in classpath, configuration, path, or?). So I can find it
and remove
(probably extra // or \) to solve my problem.
And after I know what caused this, should this be reported as bug into Bugzilla?
I'll give you server.xml and other conf as soon as I get them today.
Thanks everyone,
--
Tomy t.petro...@inet.hr
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Webapp reloading issue and intermittent 404 errors
On 29/06/2010 11:51, Tomislav Petrović wrote:
Tomislav Petrović said on 28.6.2010 15:46:
Caldarale, Charles R said on 28.6.2010 15:32:
Seems to me it is related to web app reloading but this
is my blind guess.
What makes you suspicious that reloading is going on?
Just my VERY BIG AND BLIND guess based on classes involved in stack trace.
This is my dissection of problematic stacktrace using my limited Java
knowledge and Tomcat sources.
Stacktrace written in reverse way to follow code flow more easily.
at java.lang.Thread.run(Thread.java:619)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1590)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1610)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1610)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1601)
Background thread which periodically calls backgroundProcess on container
and its children, I believe it is
used to determine wether app needs to be reloaded (make sense to me that
something periodically needs to check
wether app needs to be reloaded).
at
org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1309)
at
org.apache.catalina.loader.WebappLoader.backgroundProcess(WebappLoader.java:398)
at
org.apache.catalina.loader.WebappLoader.modified(WebappLoader.java:477)
at
org.apache.catalina.loader.WebappClassLoader.modified(WebappClassLoader.java:822)
modified is called in order to find if one or more classes or resources
been modified so that a reload is appropriate?,
at least that is what the JavaDoc comment says.
at
org.apache.naming.resources.ProxyDirContext.getAttributes(ProxyDirContext.java:840)
at
org.apache.naming.resources.BaseDirContext.getAttributes(BaseDirContext.java:747)
at
org.apache.naming.resources.FileDirContext.getAttributes(FileDirContext.java:429)
Just forwards call to more appropriate classes up to here.
at
org.apache.naming.resources.FileDirContext.file(FileDirContext.java:811)
Here a File object of Return a File object representing the specified
normalized
context-relative path if it exists and is readable is created, however name
given to it
chokes up normalize, it seems.
at
org.apache.naming.resources.FileDirContext.normalize(FileDirContext.java:771)
at org.apache.catalina.util.RequestUtil.normalize(RequestUtil.java:131)
This is problematic code (part of normalize method):
// Resolve occurrences of // in the normalized path
while (true) {
int index = normalized.indexOf(//);
if (index 0)
break;
normalized = normalized.substring(0, index) +
normalized.substring(index + 1);
}
Seems to me code assumes that if it founds // in a string then this // is
not at the
end of the string (has to have something behind it). In general case this
sounds like a
bug to me (however I am not expert here and don't know from where filename
comes and how
it should be written).
So if anyone can tell me form where a name (filename) given to normalize
comes (I assume
it is something in classpath, configuration, path, or?). So I can find it
and remove
(probably extra // or \) to solve my problem.
And after I know what caused this, should this be reported as bug into
Bugzilla?
Not unless someone here says so. We haven't eliminated the possibility
of errors in the config files yet.
p
I'll give you server.xml and other conf as soon as I get them today.
Thanks everyone,
--
Tomy t.petro...@inet.hr
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
signature.asc
Description: OpenPGP digital signature
Re: Webapp reloading issue and intermittent 404 errors
Pid said on 29.6.2010 13:36:
On 29/06/2010 11:51, Tomislav Petrović wrote:
Tomislav Petrović said on 28.6.2010 15:46:
Caldarale, Charles R said on 28.6.2010 15:32:
Seems to me it is related to web app reloading but this
is my blind guess.
What makes you suspicious that reloading is going on?
Just my VERY BIG AND BLIND guess based on classes involved in stack trace.
This is my dissection of problematic stacktrace using my limited Java
knowledge and Tomcat sources.
Stacktrace written in reverse way to follow code flow more easily.
at java.lang.Thread.run(Thread.java:619)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1590)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1610)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1610)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1601)
Background thread which periodically calls backgroundProcess on container and
its children, I believe it is
used to determine wether app needs to be reloaded (make sense to me that
something periodically needs to check
wether app needs to be reloaded).
at
org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1309)
at
org.apache.catalina.loader.WebappLoader.backgroundProcess(WebappLoader.java:398)
at
org.apache.catalina.loader.WebappLoader.modified(WebappLoader.java:477)
at
org.apache.catalina.loader.WebappClassLoader.modified(WebappClassLoader.java:822)
modified is called in order to find if one or more classes or resources been
modified so that a reload is appropriate?,
at least that is what the JavaDoc comment says.
at
org.apache.naming.resources.ProxyDirContext.getAttributes(ProxyDirContext.java:840)
at
org.apache.naming.resources.BaseDirContext.getAttributes(BaseDirContext.java:747)
at
org.apache.naming.resources.FileDirContext.getAttributes(FileDirContext.java:429)
Just forwards call to more appropriate classes up to here.
at
org.apache.naming.resources.FileDirContext.file(FileDirContext.java:811)
Here a File object of Return a File object representing the specified
normalized
context-relative path if it exists and is readable is created, however name
given to it
chokes up normalize, it seems.
at
org.apache.naming.resources.FileDirContext.normalize(FileDirContext.java:771)
at org.apache.catalina.util.RequestUtil.normalize(RequestUtil.java:131)
This is problematic code (part of normalize method):
// Resolve occurrences of // in the normalized path
while (true) {
int index = normalized.indexOf(//);
if (index 0)
break;
normalized = normalized.substring(0, index) +
normalized.substring(index + 1);
}
Seems to me code assumes that if it founds // in a string then this // is
not at the
end of the string (has to have something behind it). In general case this
sounds like a
bug to me (however I am not expert here and don't know from where filename
comes and how
it should be written).
So if anyone can tell me form where a name (filename) given to normalize comes
(I assume
it is something in classpath, configuration, path, or?). So I can find it
and remove
(probably extra // or \) to solve my problem.
And after I know what caused this, should this be reported as bug into Bugzilla?
Not unless someone here says so. We haven't eliminated the possibility
of errors in the config files yet.
OK, which configuration (classpath, windows path, what?) is in question
here and has, possible extra, // at the end of string? Which parameter
should I hunt for?
--
Tomy t.petro...@inet.hr
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Webapp reloading issue and intermittent 404 errors
On 29/06/2010 12:51, Tomislav Petrović wrote:
This is problematic code (part of normalize method):
// Resolve occurrences of // in the normalized path
while (true) {
int index = normalized.indexOf(//);
if (index 0)
break;
normalized = normalized.substring(0, index) +
normalized.substring(index + 1);
}
Seems to me code assumes that if it founds // in a string then this // is
not at the
end of the string (has to have something behind it). In general case this
sounds like a
bug to me (however I am not expert here and don't know from where filename
comes and how
it should be written).
So if anyone can tell me form where a name (filename) given to normalize comes
(I assume
it is something in classpath, configuration, path, or?). So I can find it
and remove
(probably extra // or \) to solve my problem.
Nope. That code will run quite happily if // is at the end of the
string. That is what is so odd about this error.
Also note it is perfectly valid for the path to end with /.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Webapp reloading issue and intermittent 404 errors
From: Tomislav Petrović [mailto:t.petro...@inet.hr] Subject: Re: Webapp reloading issue and intermittent 404 errors org.apache.catalina.util.RequestUtil.normalize(RequestUtil.java:131) IIRC, you are not the first person to report an exception at this spot in the code. (Unfortunately, I can't locate the other thread at the moment, but it was fairly recent.) The code in question has been run through many test cases, inside and outside of Tomcat, and does not appear to contain any errors (although it could be slightly more efficient). This is looking like a possible JVM bug, so details about the exact JVM level and what mode you're running it in (32- or 64-bit, client or server) would help. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
Re: Webapp reloading issue and intermittent 404 errors
2010/6/29 Caldarale, Charles R chuck.caldar...@unisys.com: From: Tomislav Petrović [mailto:t.petro...@inet.hr] Subject: Re: Webapp reloading issue and intermittent 404 errors org.apache.catalina.util.RequestUtil.normalize(RequestUtil.java:131) IIRC, you are not the first person to report an exception at this spot in the code. (Unfortunately, I can't locate the other thread at the moment, but it was fairly recent.) That was https://issues.apache.org/bugzilla/show_bug.cgi?id=49488 The code in question has been run through many test cases, inside and outside of Tomcat, and does not appear to contain any errors (although it could be slightly more efficient). Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Webapp reloading issue and intermittent 404 errors
On 29/06/2010 19:29, Konstantin Kolinko wrote: 2010/6/29 Caldarale, Charles R chuck.caldar...@unisys.com: From: Tomislav Petrović [mailto:t.petro...@inet.hr] Subject: Re: Webapp reloading issue and intermittent 404 errors org.apache.catalina.util.RequestUtil.normalize(RequestUtil.java:131) IIRC, you are not the first person to report an exception at this spot in the code. (Unfortunately, I can't locate the other thread at the moment, but it was fairly recent.) That was https://issues.apache.org/bugzilla/show_bug.cgi?id=49488 The code in question has been run through many test cases, inside and outside of Tomcat, and does not appear to contain any errors (although it could be slightly more efficient). Weird. I couldn't find that in bugzilla. Anyhow, it's Windows this time too. Tomislav: where is the Tomcat installation on the filing system, and where are the webapps being deployed from, if not tomcat/webapps? What type of filing system is it? Also, did you manage to get hold of the config files yet? p signature.asc Description: OpenPGP digital signature
Re: Webapp reloading issue and intermittent 404 errors
On 28/06/2010 14:25, Tomislav Petrović wrote: I have two problems with a fairly complex webapp. I don't know if they are related or not. Webapp has been deployed on several dozens of customers without problem and tested in our lab on several configurations without problem. However one customer has following two issues. Tomcat is: Apache Tomcat/6.0.24, Java is 6 don't know update number exactly but can find out if necessary. First... In catalina*.log log files we get exceptions with following stacktrace (on a load test we get a lot of them, on normal run we get something like one/two per hour): Jun 21, 2010 1:17:21 PM org.apache.catalina.core.ContainerBase backgroundProcess WARNING: Exception processing loader WebappLoader[/hidden_name] background process java.lang.StringIndexOutOfBoundsException: String index out of range: 110 at java.lang.String.substring(String.java:1934) at org.apache.catalina.util.RequestUtil.normalize(RequestUtil.java:131) at org.apache.naming.resources.FileDirContext.normalize(FileDirContext.java:771) at org.apache.naming.resources.FileDirContext.file(FileDirContext.java:811) at org.apache.naming.resources.FileDirContext.getAttributes(FileDirContext.java:429) at org.apache.naming.resources.BaseDirContext.getAttributes(BaseDirContext.java:747) at org.apache.naming.resources.ProxyDirContext.getAttributes(ProxyDirContext.java:840) at org.apache.catalina.loader.WebappClassLoader.modified(WebappClassLoader.java:822) at org.apache.catalina.loader.WebappLoader.modified(WebappLoader.java:477) at org.apache.catalina.loader.WebappLoader.backgroundProcess(WebappLoader.java:398) at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1309) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1601) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1610) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1610) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1590) at java.lang.Thread.run(Thread.java:619) Actual index in String index out of range: varies with every occurrence. What could be causing this? Seems to me it is related to web app reloading but this is my blind guess. What I know is that app should not be automatically reloaded (nothing changes in WEB-INF/* folders) nor is told to reload via Tomcat manager. So please help! :) Second one... Don't know if it is related to first one or separate issue. From time to time on a load test we get intermittent 404 errors on our jsp pages. Intermittent meaning page gives 404 error on a request and randomly and next request to a same page goes ok (few miliseconds later). What I know is that: 1. JSP page exists for certain (it is not moved or deleted or anything) works ok before it happens, works ok afterwards 2. All JSPs are written in a way that they don't throw any exceptions to the outside (surrounded in try/catch everything). If/when code invoked inside throws unhandled exception page will produce some custom error message inside enclosing catch. What could be causing this? Is it related to first problem, or a completely new one? Thanks for any info you can provide me, Please start an entirely new email, don't just edit a reply to an existing thread (you don't remove the mail thread id header by just editing the subject/body, so your message appears in the middle of someone elses thread). This is called 'thread-hijacking'. p signature.asc Description: OpenPGP digital signature
RE: Webapp reloading issue and intermittent 404 errors
From: Tomislav Petrović [mailto:t.petro...@inet.hr] Subject: Webapp reloading issue and intermittent 404 errors Tomcat is: Apache Tomcat/6.0.24, Java is 6 don't know update number exactly but can find out if necessary. Try moving to 6.0.26, or 6.0.27 when it comes out in a few days. The exact JVM version may be useful. Seems to me it is related to web app reloading but this is my blind guess. What makes you suspicious that reloading is going on? Have you checked the timestamps of the .war file against the system clock? Times in the future have been known to trigger reload loops and other errors (perhaps your 404). - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
Re: Webapp reloading issue and intermittent 404 errors
Caldarale, Charles R said on 28.6.2010 15:32: From: Tomislav Petrović [mailto:t.petro...@inet.hr] Subject: Webapp reloading issue and intermittent 404 errors Tomcat is: Apache Tomcat/6.0.24, Java is 6 don't know update number exactly but can find out if necessary. Try moving to 6.0.26, or 6.0.27 when it comes out in a few days. The exact JVM version may be useful. I'll try to find out. Seems to me it is related to web app reloading but this is my blind guess. What makes you suspicious that reloading is going on? Just my VERY BIG AND BLIND guess based on classes involved in stack trace. Have you checked the timestamps of the .war file against the system clock? Times in the future have been known to trigger reload loops and other errors (perhaps your 404). Have checked all files related to this webapp and none seems to change. Will check again more thoroughly if future timestamps exist. Thanks for suggestions, any other ideas? -- Tomy t.petro...@inet.hr - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Webapp reloading issue and intermittent 404 errors
On 28/06/2010 14:46, Tomislav Petrović wrote: Caldarale, Charles R said on 28.6.2010 15:32: From: Tomislav Petrović [mailto:t.petro...@inet.hr] Subject: Webapp reloading issue and intermittent 404 errors Tomcat is: Apache Tomcat/6.0.24, Java is 6 don't know update number exactly but can find out if necessary. Try moving to 6.0.26, or 6.0.27 when it comes out in a few days. The exact JVM version may be useful. I'll try to find out. Seems to me it is related to web app reloading but this is my blind guess. What makes you suspicious that reloading is going on? Just my VERY BIG AND BLIND guess based on classes involved in stack trace. Have you checked the timestamps of the .war file against the system clock? Times in the future have been known to trigger reload loops and other errors (perhaps your 404). Have checked all files related to this webapp and none seems to change. Will check again more thoroughly if future timestamps exist. Thanks for suggestions, any other ideas? Which OS are you seeing this on? Something about this rings a bell, I'm sure I've seen something like this on the list recently. p signature.asc Description: OpenPGP digital signature
Re: Webapp reloading issue and intermittent 404 errors
Pid said on 28.6.2010 15:49: On 28/06/2010 14:46, Tomislav Petrović wrote: Caldarale, Charles R said on 28.6.2010 15:32: From: Tomislav Petrović [mailto:t.petro...@inet.hr] Subject: Webapp reloading issue and intermittent 404 errors Tomcat is: Apache Tomcat/6.0.24, Java is 6 don't know update number exactly but can find out if necessary. Try moving to 6.0.26, or 6.0.27 when it comes out in a few days. The exact JVM version may be useful. I'll try to find out. Seems to me it is related to web app reloading but this is my blind guess. What makes you suspicious that reloading is going on? Just my VERY BIG AND BLIND guess based on classes involved in stack trace. Have you checked the timestamps of the .war file against the system clock? Times in the future have been known to trigger reload loops and other errors (perhaps your 404). Have checked all files related to this webapp and none seems to change. Will check again more thoroughly if future timestamps exist. Thanks for suggestions, any other ideas? Which OS are you seeing this on? Something about this rings a bell, I'm sure I've seen something like this on the list recently. It's Windows (sorry should have included this in initial mail :(). I've searched but haven't been able to find it myself. Would appreciate if pointed in right direction. -- Tomy t.petro...@inet.hr - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Webapp reloading issue and intermittent 404 errors
On 28/06/2010 14:51, Tomislav Petrović wrote: Pid said on 28.6.2010 15:49: On 28/06/2010 14:46, Tomislav Petrović wrote: Caldarale, Charles R said on 28.6.2010 15:32: From: Tomislav Petrović [mailto:t.petro...@inet.hr] Subject: Webapp reloading issue and intermittent 404 errors Tomcat is: Apache Tomcat/6.0.24, Java is 6 don't know update number exactly but can find out if necessary. Try moving to 6.0.26, or 6.0.27 when it comes out in a few days. The exact JVM version may be useful. I'll try to find out. Seems to me it is related to web app reloading but this is my blind guess. What makes you suspicious that reloading is going on? Just my VERY BIG AND BLIND guess based on classes involved in stack trace. Have you checked the timestamps of the .war file against the system clock? Times in the future have been known to trigger reload loops and other errors (perhaps your 404). Have checked all files related to this webapp and none seems to change. Will check again more thoroughly if future timestamps exist. Thanks for suggestions, any other ideas? Which OS are you seeing this on? Something about this rings a bell, I'm sure I've seen something like this on the list recently. It's Windows (sorry should have included this in initial mail :(). I've searched but haven't been able to find it myself. Would appreciate if pointed in right direction. Hmm. I can't find anything in the archives. Anyway: if the background process is finding a changed item on the filesystem it might kick off the app reloading process. Please post the Context definition for your application, and the server.xml with comments passwords removed. p signature.asc Description: OpenPGP digital signature
