Tomcat 6.0.35, PersistentManager with FileStore - Session file size increases endlessly
Hi, I have a problem that on one of our servers we use the PersistentManager with Filestore and it happened that one session file increased endlessly to a size of 235GB before we removed that session. First, some information to our setup: Server version: Apache Tomcat/6.0.35 Server built: Jan 31 2012 04:27:38 Server number: 6.0.35.0 OS Name:Linux (Debian Squeeze) OS Version: 2.6.32-5-amd64 Architecture: amd64 JVM Version:1.6.0_26-b03 JVM Vendor: Sun Microsystems Inc. Xmx: 12GB Tomcat is running behind an Apache web server. Now, more details to this incident: We have recognized an unusually high number of disk operations on one of our servers and investigated the origin. We found out that there was one tomcat session file that grew already to 235GB and was increasing quickly (all other sessions on our server are less than 10KB). We then removed that session file, but it was recreated (starting from 0 bytes) and was again growing quickly. We then did a backup of that file and removed it again. After the second removal the session file didn't appear again. The server returned to normal operation. I've investigated the session file and the file contained 3 lines. I was able to recognize the data of the first two lines (the default session parameters like lastAccessedTime as well as some POJOs we have added to that session). But the third line was endlessly repeating the following string: q~q~#q~'q~( And now my questions: Does anyone know what this string means? How is it possible that a session can increase to this size (larger than the heap size of tomcat)? Is it a known tomcat bug? Is it a known type of attack? How can you prevent this problem? Thanks in advance. Nicolas Peters
Re: Tomcat 7.0.34 JspC issue?
No, unfortunately I have no small test case. Our JSPs are the opposite of standalone test cases and I've not had time to try to find a trigger within them -- and quite likely won't have such time. Out of our 1000's of JSP pages I saw a dozen or so JSP precompilation failures that weren't present prior to stopping the precompilation early -- hence I don't know how many failures I would have had. I tested this with Java 6 and Java 7 against 2 different versions of our application (compiled with Java 6 and Java 7, respectively) where Tomcat 7.0.33 worked fine. Tomcat 7.0.34 failed in both cases -- until I reverted to the old ecj.jar. There *may* be a relationship to how my pre-compilation runs. Even if that's the case I'll be sticking with the old ecj.jar as it clearly works. The pre-compilation script that I was running does the following: 1. Try to compile everything en masse excluding known failures (mostly legacy JSP fragments that were improperly named .jspf rather than .jsp) 2. Catch (via ant-contrib) any failure and re-try to compile everything en masse excluding known failure * The first attempt has been consistently failing for quite a number of Tomcat releases for no apparent reason on a tag file or some such as I recall (too many nested dependencies?) where the second would succeed. 3. Catch any failure one again * If there was a failure try to recompile each JSP individually so as to generate an accurate list of failures. 4. If there was no failure on the second attempt, then try to compile every JSP in the known failure list so as to verify that the entire known failure list is still failing. The need to re-try the en-masse JspC has been bothersome for quite some time -- and doesn't seem to be addressed by simple things like giving the script more memory. That said, this issue has been there for quite some time. The new issue shows up when trying to compile one of the failing JSPs all by itself and results in a stack trace into the bowels of ECJ, so this really looks like an issue in ECJ. -- Jess Holle On 12/13/2012 1:07 AM, Mark Thomas wrote: Jess Holle je...@ptc.com wrote: I moved to Tomcat 7.0.34 -- apparently with inadequate testing / too much trust. Some JSPs that precompiled just fine with 7.0.33 and many previous Tomcat versions now produce the error shown below Moving back to the ecj jar from Tomcat 7.0.33 resolves the issue. I'm assuming buggy JDT compiler until proven otherwise. It certainly sounds like a bug in ecj.jar Do you have a sample JSP you can share that demonstrates the issue? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Does maxPostSize has an effect on file upload?
I see the following behaviour on Tomcat 6.0.24: The maxPostSize is not set, so uses the default of 2MB. I can upload files bigger than 2MB (5MB for example). I use commons-fileupload to read the file. Does a file upload as multipart/form-data not count to the size of the POST? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat7-maven-plugin
On Wed, Dec 12, 2012 at 6:05 PM, Olivier Lamy ol...@apache.org wrote: Good detailed description :-). Hey even I get it right once in a while... ;) I just wonder about the cli you are using ? cli as in command line interface? - Win 7, CentOS, and Ubuntu terminals, and yes I get my fair share of flack for not letting Eclipse just do it. Of course I'm a control freak when it comes to my code... 2012/12/12 Josh Gooding josh.good...@gmail.com: I didn't want to come here to ask as I always hate to bother anyone, but maybe I should have come here first. I'm coming up short on answers and ideas. I'm having an issue with using maven and the tomcat7 plugin. Maven version -3.0.4 Tomcat version - 7.0.29 .jdk version - 1.6 tomcat7-maven-plugin version - 2.0 Hey group, I am having an issue here with using the tomcat7-maven-plugin in conjunction with the tomcat 7 manager. here's what I have so far. tomcat-users.xml - tomcat-users role rolename=manager-gui/ role rolename=manager-script/ role rolename=admin/ user username=localTomcatAdmin password=password roles=manager-gui,manager-script,admin/ /tomcat-users in my M2_HOME/conf/settings.xml: (note not in my .m2/ directory) (I'll get to this definition in a minute) pluginGroups pluginGrouporg.apache.tomcat.maven/pluginGroup /pluginGroups servers server idLocalTomcatServer/id usernamelocalTomcatAdmin/username passwordpassword/password /server /servers now for the last piece, in my pom-deploy.xml (parent) I have this: plugin groupIdorg.apache.tomcat.maven/groupId artifactIdtomcat7-maven-plugin/artifactId version2.0/version configuration serverLocalTomcatServer/server path/TripTixRX/path port8080/port /configuration /plugin I have verified that the manager works with the applied credentials, I can login and supply the credentials to my local /manager/html. The problem is that when I deploy through maven as mvn tomcat7:deploy and returns me the dreaded 401 - Unauthorized page with the same credentials. It's almost like maven is not parsing the configuration for the plugin maybe? At this point I don't know what to do. I've turned on verbose output in maven and it shows what appears that the plugin is attempting to upload the war file twice and returns the 401 page. I also have a question as to getting this to work initially. I added the pluginGrouporg.apache.tomcat.maven/pluginGroup to my conf/settings.xml to get the tomcat7 plugin to download and work, is this normal or should I not have to define it here? I mean having to change and version maven settings.xml files seems a bit counter intuitive for preserving maximum portability right, or am I looking at this from the wrong angle? Any information anyone can provide as to where to look or what could be causing this issue, I would be greatly appreciated. Warmest regards, - Josh -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat7-maven-plugin
2012/12/13 Josh Gooding josh.good...@gmail.com: On Wed, Dec 12, 2012 at 6:05 PM, Olivier Lamy ol...@apache.org wrote: Good detailed description :-). Hey even I get it right once in a while... ;) I just wonder about the cli you are using ? cli as in command line interface? - Win 7, CentOS, and Ubuntu terminals, and yes I get my fair share of flack for not letting Eclipse just do it. Of course I'm a control freak when it comes to my code... :-) I mean mvn tomcat7:deploy or something else ? or you bind deploy to a lifecycle phase ? 2012/12/12 Josh Gooding josh.good...@gmail.com: I didn't want to come here to ask as I always hate to bother anyone, but maybe I should have come here first. I'm coming up short on answers and ideas. I'm having an issue with using maven and the tomcat7 plugin. Maven version -3.0.4 Tomcat version - 7.0.29 .jdk version - 1.6 tomcat7-maven-plugin version - 2.0 Hey group, I am having an issue here with using the tomcat7-maven-plugin in conjunction with the tomcat 7 manager. here's what I have so far. tomcat-users.xml - tomcat-users role rolename=manager-gui/ role rolename=manager-script/ role rolename=admin/ user username=localTomcatAdmin password=password roles=manager-gui,manager-script,admin/ /tomcat-users in my M2_HOME/conf/settings.xml: (note not in my .m2/ directory) (I'll get to this definition in a minute) pluginGroups pluginGrouporg.apache.tomcat.maven/pluginGroup /pluginGroups servers server idLocalTomcatServer/id usernamelocalTomcatAdmin/username passwordpassword/password /server /servers now for the last piece, in my pom-deploy.xml (parent) I have this: plugin groupIdorg.apache.tomcat.maven/groupId artifactIdtomcat7-maven-plugin/artifactId version2.0/version configuration serverLocalTomcatServer/server path/TripTixRX/path port8080/port /configuration /plugin I have verified that the manager works with the applied credentials, I can login and supply the credentials to my local /manager/html. The problem is that when I deploy through maven as mvn tomcat7:deploy and returns me the dreaded 401 - Unauthorized page with the same credentials. It's almost like maven is not parsing the configuration for the plugin maybe? At this point I don't know what to do. I've turned on verbose output in maven and it shows what appears that the plugin is attempting to upload the war file twice and returns the 401 page. I also have a question as to getting this to work initially. I added the pluginGrouporg.apache.tomcat.maven/pluginGroup to my conf/settings.xml to get the tomcat7 plugin to download and work, is this normal or should I not have to define it here? I mean having to change and version maven settings.xml files seems a bit counter intuitive for preserving maximum portability right, or am I looking at this from the wrong angle? Any information anyone can provide as to where to look or what could be causing this issue, I would be greatly appreciated. Warmest regards, - Josh -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat7-maven-plugin
On Thu, Dec 13, 2012 at 9:36 AM, Olivier Lamy ol...@apache.org wrote: 2012/12/13 Josh Gooding josh.good...@gmail.com: On Wed, Dec 12, 2012 at 6:05 PM, Olivier Lamy ol...@apache.org wrote: Good detailed description :-). Hey even I get it right once in a while... ;) I just wonder about the cli you are using ? cli as in command line interface? - Win 7, CentOS, and Ubuntu terminals, and yes I get my fair share of flack for not letting Eclipse just do it. Of course I'm a control freak when it comes to my code... :-) I mean mvn tomcat7:deploy or something else ? or you bind deploy to a lifecycle phase ? Oh I gotcha. tomcat7:deploy I didn't bind the deploy to the life-cycle phase yet. I want to get it working first. 2012/12/12 Josh Gooding josh.good...@gmail.com: I didn't want to come here to ask as I always hate to bother anyone, but maybe I should have come here first. I'm coming up short on answers and ideas. I'm having an issue with using maven and the tomcat7 plugin. Maven version -3.0.4 Tomcat version - 7.0.29 .jdk version - 1.6 tomcat7-maven-plugin version - 2.0 Hey group, I am having an issue here with using the tomcat7-maven-plugin in conjunction with the tomcat 7 manager. here's what I have so far. tomcat-users.xml - tomcat-users role rolename=manager-gui/ role rolename=manager-script/ role rolename=admin/ user username=localTomcatAdmin password=password roles=manager-gui,manager-script,admin/ /tomcat-users in my M2_HOME/conf/settings.xml: (note not in my .m2/ directory) (I'll get to this definition in a minute) pluginGroups pluginGrouporg.apache.tomcat.maven/pluginGroup /pluginGroups servers server idLocalTomcatServer/id usernamelocalTomcatAdmin/username passwordpassword/password /server /servers now for the last piece, in my pom-deploy.xml (parent) I have this: plugin groupIdorg.apache.tomcat.maven/groupId artifactIdtomcat7-maven-plugin/artifactId version2.0/version configuration serverLocalTomcatServer/server path/TripTixRX/path port8080/port /configuration /plugin I have verified that the manager works with the applied credentials, I can login and supply the credentials to my local /manager/html. The problem is that when I deploy through maven as mvn tomcat7:deploy and returns me the dreaded 401 - Unauthorized page with the same credentials. It's almost like maven is not parsing the configuration for the plugin maybe? At this point I don't know what to do. I've turned on verbose output in maven and it shows what appears that the plugin is attempting to upload the war file twice and returns the 401 page. I also have a question as to getting this to work initially. I added the pluginGrouporg.apache.tomcat.maven/pluginGroup to my conf/settings.xml to get the tomcat7 plugin to download and work, is this normal or should I not have to define it here? I mean having to change and version maven settings.xml files seems a bit counter intuitive for preserving maximum portability right, or am I looking at this from the wrong angle? Any information anyone can provide as to where to look or what could be causing this issue, I would be greatly appreciated. Warmest regards, - Josh -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
org.apache.catalina.valves.RemoteAddrValve on Tomcat 7.0.27 x64 Windows 2008 R2
Hi Info: Tomcat 7.0.27 x64 running on Windows 2008 R2 Tomcat 6 allowed me to restrict access to Tomcat for more than one IP address, but it does not seem to work on Tomcat 7.0.27. Usually this worked: Valve className=org.apache.catalina.valves.RemoteAddrValve allow=127\.0\.0\.1\, 192\.168\.12\.22, 192\.168\.12\.23/ Now I can only make to following work Valve className=org.apache.catalina.valves.RemoteAddrValve allow=127\.0\.0\.1/ Please help Thanks Br. Michael Trabjerg
Re: org.apache.catalina.valves.RemoteAddrValve on Tomcat 7.0.27 x64 Windows 2008 R2
Michael Trabjerg wrote: Hi Info: Tomcat 7.0.27 x64 running on Windows 2008 R2 Tomcat 6 allowed me to restrict access to Tomcat for more than one IP address, but it does not seem to work on Tomcat 7.0.27. Usually this worked: Valve className=org.apache.catalina.valves.RemoteAddrValve allow=127\.0\.0\.1\, 192\.168\.12\.22, 192\.168\.12\.23/ Now I can only make to following work Valve className=org.apache.catalina.valves.RemoteAddrValve allow=127\.0\.0\.1/ I believe you need to re-read the on-line docs. It is probably indicated there that this should be a regexp, not a list of regexpes. So try something like (127\.0\.0\.1\|192\.168\.12\.22|192\.168\.12\.23) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: org.apache.catalina.valves.RemoteAddrValve on Tomcat 7.0.27 x64 Windows 2008 R2
Hi André This worked Valve className=org.apache.catalina.valves.RemoteAddrValve allow=(127\.0\.0\.1|192\.168\.12\.22|192\.168\.12\.23)/ The other used to work for Tomcat 6. Thanks a lot. Br Michael Trabjerg -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: 13. december 2012 16:10 To: Tomcat Users List Subject: Re: org.apache.catalina.valves.RemoteAddrValve on Tomcat 7.0.27 x64 Windows 2008 R2 Michael Trabjerg wrote: Hi Info: Tomcat 7.0.27 x64 running on Windows 2008 R2 Tomcat 6 allowed me to restrict access to Tomcat for more than one IP address, but it does not seem to work on Tomcat 7.0.27. Usually this worked: Valve className=org.apache.catalina.valves.RemoteAddrValve allow=127\.0\.0\.1\, 192\.168\.12\.22, 192\.168\.12\.23/ Now I can only make to following work Valve className=org.apache.catalina.valves.RemoteAddrValve allow=127\.0\.0\.1/ I believe you need to re-read the on-line docs. It is probably indicated there that this should be a regexp, not a list of regexpes. So try something like (127\.0\.0\.1\|192\.168\.12\.22|192\.168\.12\.23) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.0.34 JspC issue?
Jess Holle je...@ptc.com wrote: No, unfortunately I have no small test case. Our JSPs are the opposite of standalone test cases and I've not had time to try to find a trigger within them -- and quite likely won't have such time. Fair enough. If you do find time, that would be great. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: About tomcat 8.0.0 dev documentation
Ram Laxman ram.laxman241...@yahoo.com wrote: Hi there, I want to know how to access the tomcat dev 8.0.0 documentation which having actual URL http://ci.apache.org/projects/tomcat/tomcat8/docs/index.html but unable to access it. When I try to access it from Google cached copy, the screen I have attached here. Thanks!! As you have already been told, that is the output of the continuous integration system. There are no Tomcat 8 docs anywhere else because there has not been a release of Tomcat 8. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Does maxPostSize has an effect on file upload?
Kai Weber kai.we...@glorybox.de wrote: I see the following behaviour on Tomcat 6.0.24: The maxPostSize is not set, so uses the default of 2MB. I can upload files bigger than 2MB (5MB for example). I use commons-fileupload to read the file. As expected. Does a file upload as multipart/form-data not count to the size of the POST? No, as the doc make clear. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: org.apache.catalina.valves.RemoteAddrValve on Tomcat 7.0.27 x64 Windows 2008 R2
Michael Trabjerg wrote: Hi André This worked Valve className=org.apache.catalina.valves.RemoteAddrValve allow=(127\.0\.0\.1|192\.168\.12\.22|192\.168\.12\.23)/ The other used to work for Tomcat 6. Yes, but as I remember it was changed because it was ambiguous : a comma can be part of a regular expression, so it was not clear how a comma-separated list should be interpreted. There is probably a more complete/correct explanation in the changes documentation for Tomcat 7.x. The same change may apply to other elements where comma-separated lists used to be allowed, so you may want to check these too. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat uses only a single Core
Hi, I have an application running on Tomcat 7 on a 8-Core Linux 64 bit System. Unfortunately it uses only a single core. I have googled alot about this fact but did not found a solution, even not a clear reason for it. What can be the problem here? Thank you - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat uses only a single Core
On 13/12/2012 19:44, spr...@gmx.eu wrote: Hi, I have an application running on Tomcat 7 on a 8-Core Linux 64 bit System. Unfortunately it uses only a single core. I have googled alot about this fact but did not found a solution, even not a clear reason for it. What can be the problem here? Your app is single threaded? p Thank you - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- [key:62590808] signature.asc Description: OpenPGP digital signature
Re: Data sources definitions are lost in memory
Hi, Today the problem happened again, but this time we were monitoring the logs: 13/12/2012 15:49:46 org.apache.catalina.core.ApplicationContext log GRAVE: java.sql.SQLException java.lang.RuntimeException: java.sql.SQLException at com.sun.data.provider.impl.CachedRowSetDataProvider.setCursorRow(CachedRowSetDataProvider.java:416) at com.sun.data.provider.impl.CachedRowSetDataProvider.setCursorIndex(CachedRowSetDataProvider.java:373) at com.sun.data.provider.impl.CachedRowSetDataProvider.getRowCount(CachedRowSetDataProvider.java:713) at com.sun.webui.jsf.faces.DataProviderELResolver$SelectItemsData.getSelectItems(DataProviderELResolver.java:702) at com.sun.webui.jsf.faces.DataProviderELResolver.getValue(DataProviderELResolver.java:166) at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:54) at com.sun.faces.el.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:64) at org.apache.el.parser.AstValue.getValue(AstValue.java:123) at org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186) at org.apache.jasper.el.JspValueExpression.getValue(JspValueExpression.java:101) at com.sun.webui.jsf.component.Selector.getItems(Selector.java:577) at com.sun.webui.jsf.component.ListSelector.getOptions(ListSelector.java:212) at com.sun.webui.jsf.component.ListSelector.getListItems(ListSelector.java:140) at com.sun.webui.jsf.renderkit.widget.ListRendererBase.getListProperties(ListRendererBase.java:269) at com.sun.webui.jsf.renderkit.widget.ListRendererBase.getProperties(ListRendererBase.java:220) at com.sun.webui.jsf.renderkit.widget.DropDownRenderer.getProperties(DropDownRenderer.java:74) at com.sun.webui.jsf.renderkit.widget.RendererBase.encodeChildren(RendererBase.java:134) at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:812) at javax.faces.component.UIComponent.encodeAll(UIComponent.java:886) at javax.faces.component.UIComponent.encodeAll(UIComponent.java:892) at javax.faces.component.UIComponent.encodeAll(UIComponent.java:892) at javax.faces.component.UIComponent.encodeAll(UIComponent.java:892) at javax.faces.component.UIComponent.encodeAll(UIComponent.java:892) at javax.faces.component.UIComponent.encodeAll(UIComponent.java:892) at com.sun.faces.application.ViewHandlerImpl.doRenderView(ViewHandlerImpl.java:245) at com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:176) at com.sun.rave.web.ui.appbase.faces.ViewHandlerImpl.renderView(ViewHandlerImpl.java:320) at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:106) at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:251) at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:144) at com.sun.faces.extensions.avatar.lifecycle.PartialTraversalLifecycle.render(PartialTraversalLifecycle.java:106) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:245) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:267) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at com.googlecode.psiprobe.Tomcat60AgentValve.invoke(Tomcat60AgentValve.java:30) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) at org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:429) at org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(AjpAprProtocol.java:384) at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1665) at java.lang.Thread.run(Thread.java:662) Caused by: java.sql.SQLException at com.sun.sql.rowset.internal.CachedRowSetXReader.connect(CachedRowSetXReader.java:381) at com.sun.sql.rowset.internal.CachedRowSetXReader.readData(CachedRowSetXReader.java:160) at com.sun.sql.rowset.CachedRowSetXImpl5.execute(CachedRowSetXImpl5.java:865) at com.sun.sql.rowset.CachedRowSetXImpl5.execute(CachedRowSetXImpl5.java:1325)
