RE: Web development forum
The servlet-interest mailing list still appears to be alive at javasoft/sun. I think you can subscribe via http://archives.javasoft.com/. But I don't want to discourage you from starting your own. I too have some general thoughts I would like to discuss on web app architecture (eg. do we need model-2 anymore?). Cheers Drew -Original Message- From: Michael Teter [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 22, 2002 8:33 AM To: tomcat-user Subject: Web development forum Howdy again. Thanks for the good responses to my web development/methodology question post. New Question: Does there exist an active forum for discussion of (generally Tomcat-related) web development? Ideally such a forum would focus on experiences with different web development technologies or methodologies. Also useful would be tales of production experiences. If no such forum exists, I'm inclined to start one. From responses I got about my earlier post, there is interest in this. Comments? Thanks, Michael __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
URGENT - Tomcat 4.0.3 thread pool allocation out-of-control bug (bugzilla 5735)
We're having a killer problem on our production server, where tomcat 4.0.3 goes crazy allocating threads in its thread pool, until it either runs out of threads or heap (for us it's heap). Searching the list I found a reference to a (closed, not reproducible) bug that looks the same: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5735 We are using tomcat standalone, with the https connector. I have re-opened the bug, as it looks very much like what is happening to us. I'd really like to know from people is what further specific information we can contribute to help diagnose this problem. Failing that we are looking at an emergency fallback to Tomcat 3, where we didn't see this problem. Thanks Drew -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
RE: URGENT - Tomcat 4.0.3 thread pool allocation out-of-control bug (bugzilla 5735)
Thanks for the info Remy. I was not familiar with Coyote, but from the release notes for 4.0.4-b2: Coyote: This release include a completely new HTTP/1.1 connector and connector API, called Coyote. This connector provides much improved performance and robustness over the default HTTP/1.1 connector. This connector is disabled in the default configuration, but can be enabled by uncommenting an element in the server.xml configuration file. So it seems that this new architecture would be worth trying, if only to rule out the possibility of the thread pool bug. We are watching the active session count fairly closely, it does get up there during the day, but not at the times we have this problem. Still, can't rule it out, but there is a very good chronological match between the leap in heap usage and tomcat creating 70 new threads in 3 minutes. Thanks Drew -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 17, 2002 2:11 PM To: Tomcat Users List Subject: Re: URGENT - Tomcat 4.0.3 thread pool allocation out-of-control bug (bugzilla 5735) We're having a killer problem on our production server, where tomcat 4.0.3 goes crazy allocating threads in its thread pool, until it either runs out of threads or heap (for us it's heap). Searching the list I found a reference to a (closed, not reproducible) bug that looks the same: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5735 We are using tomcat standalone, with the https connector. I have re-opened the bug, as it looks very much like what is happening to us. I'd really like to know from people is what further specific information we can contribute to help diagnose this problem. Failing that we are looking at an emergency fallback to Tomcat 3, where we didn't see this problem. There are a few possibilities: - it happens because of GC (see the analysis posted by Glenn a while ago) - it happens because of some bug in the thread pool; maybe, but I doubt it; the most recent Tomcat 4 connector (Coyote b7 and up) uses the Tomcat 3 thread pool, so it would be relatively easy to solve your problem in that case - it happens because of some memory leak (I mentioned the possibility of having too many active sessions, but it could be something else) Remy -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
That old tomcat 4.0.2 - xerces.jar file problem one more time...please
I'm sorry guys. I've searched the archives, really. I have seen a bunch of seemingly relevant posts and tried some of their recommendations. But I can't get this to work. Here's the deal. Our webapp includes xerces.jar in the web.inf/lib directory. This works fine on Tomcat 3.1 (our prod version) and 3.3a (our new prod version if I can't get this sorted). On 4.0.2 I get the following error in the tomcat logs, apparently when trying to compile a JSP: - Root Cause - java.lang.NoClassDefFoundError: org/w3c/dom/range/Range at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:120) at org.apache.xerces.parsers.DOMParser.setDocumentClassName(DOMParser.java:489) at org.apache.xerces.parsers.DOMParser.init(DOMParser.java:221) at org.apache.xerces.jaxp.DocumentBuilderImpl.init(DocumentBuilderImpl.java:9 8) at org.apache.xerces.jaxp.DocumentBuilderFactoryImpl.newDocumentBuilder(Documen tBuilderFactoryImpl.java:87) at org.apache.jasper.parser.ParserUtils.parseXMLDocument(ParserUtils.java:197) at org.apache.jasper.compiler.TldLocationsCache.processWebDotXml(TldLocationsCa che.java:165) at org.apache.jasper.compiler.TldLocationsCache.init(TldLocationsCache.java:1 38) at org.apache.jasper.EmbededServletOptions.init(EmbededServletOptions.java:34 5) at org.apache.jasper.servlet.JspServlet.init(JspServlet.java:266) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:91 6) at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:653) From reading the previous posts and tomcat docs, it appears there are some classloader/version conflicts with the xerces.jar in the CATALINA_HOME/common/lib directory. I have tried moving the catalina xerces.jar around into all of the other libs in tomcat to no avail. If I remove our webapp's xerces.jar, things work fine. This is a reasonable workaround, but what if I really needed different versions of the library available to different apps? I'm sure there is a simple way to make this work, please help the terminally bewildered to get this working. Thanks Drew -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Tomcat 4.0.2 - HttpUtils.getRequestURL gives incorrect URL with web.xml redirected error pages
We have a Invalid URL error page that is forwarded to using the error-code and exception-type elements of the web.xml. On that page we use the HttpUtils.getRequestURL (req) call to get the (invalid) requested URL for display. Under Tomcat 3.3a this works fine, under tomcat 4.0.2 this give the URL of the error page itself. I understand the entire HttpUtils class is deprecated under the Servlet 2.3 spec. And the replacement call HttpServletRequest.getRequestURL() appears to work fine on 4.0.2. But it would be great for our migration strategy is the deprecated call functioned the same. Anyone else out there had experience with this? Thanks Drew -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
RE: error-page tag in web.xml
Hey Ricky, Struggling with similar issues to you, but might be able to help here. Your exception-typeCompileException/exception-type should contain a fully qualified class name. I have the redirection working in Tomcat 4.0.2 with this. I would also suggest checking the %CATALINA_HOME%/logs/severname_logdate.txt log file, it usually has more info if the redirection is failing. Cheers Drew -Original Message- From: Ricky Leung [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 19, 2002 2:30 PM To: Tomcat Users List Subject: error-page tag in web.xml I have the following in my web.xml and if I bring up a non-existent page, Tomcat4 correctly parses and presents the er404.jsp page, however, I have not been able to get the 500 and the exception ones working. I always get the Tomcat Error report with the dreaded 500 - Internal Server Error. Any ideas? servlet-mapping servlet-nameStoreServlet/servlet-name url-pattern/store/url-pattern /servlet-mapping error-page exception-typeCompileException/exception-type location/error/er500.jsp/location /error-page error-page error-code404/error-code location/error/er404.jsp/location /error-page error-page error-code500/error-code location/error/er500.jsp/location /error-page Thanks, Ricky -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Problems accessing exception implicit object in error JSPs - Tomcat 4.0.2
My apologies if this issue has been done to death, but I've done some searching on the archives but has not seen a definitive answer. We are using the error-page exception-type entries in the web.xml to direct all our web application exceptions to various error JSPs. This is working. These JSPs have the %@ page isErrorPage =true % directive set. In Tomcat 3.3a these pages have access to the exception implicit object. For the same webapp deployed in Tomcat 4.0.2 this variable is declared, but null. Is this a bug? In the interim we are getting access to the exception from the javax.servlet.error.exception request attribute. I also notice in the JSP 1.2 API that a javax.servlet.jsp.jspException request attribute may also be available. Which should I be using? Our apps are a collection of JSPs and servlets, roughly conforming to the model-2 architecture (if its still called that). Cheers Drew Cox -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
RE: Problems accessing exception implicit object in error JSPs -Tomcat 4.0.2
Thanks for the incredibly quick response Craig, this clears it up for me. We are trying to settle on 3.3a or 4.0.2 are a replacement for 3.1 for our next release, this issue was forcing us down the 3.3a path. Now, if only we could sort out the issue with the use of multiple xerces.jars(another day). rant I must say, choosing the right error handling strategy is a little confusing just reading the Servlet and JSP APIs. Surely the spec's could align a little better and *always* slave the exception implicit object to the javax.servlet.error.exception request attribute if the isErrorPage attribute is set? They just drop the javax.servlet.jsp.jspException attribute altogether and we'd be golden. /rant Cheers Drew -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 19, 2002 5:03 PM To: Tomcat Users List Subject: Re: Problems accessing exception implicit object in error JSPs -Tomcat 4.0.2 On Tue, 19 Feb 2002, Drew Cox wrote: Date: Tue, 19 Feb 2002 16:49:00 -0800 From: Drew Cox [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Problems accessing exception implicit object in error JSPs - Tomcat 4.0.2 My apologies if this issue has been done to death, but I've done some searching on the archives but has not seen a definitive answer. We are using the error-page exception-type entries in the web.xml to direct all our web application exceptions to various error JSPs. This is working. These JSPs have the %@ page isErrorPage =true % directive set. In Tomcat 3.3a these pages have access to the exception implicit object. For the same webapp deployed in Tomcat 4.0.2 this variable is declared, but null. Is this a bug? It's not a bug in 4.0.2 -- at best you could say that 3.3 is going above and beyond what the spec requires. In the interim we are getting access to the exception from the javax.servlet.error.exception request attribute. I also notice in the JSP 1.2 API that a javax.servlet.jsp.jspException request attribute may also be available. Which should I be using? Our apps are a collection of JSPs and servlets, roughly conforming to the model-2 architecture (if its still called that). The spec requirements are like this: * Exceptions in a JSP page that declares an errorPage attribute are exposed -- to that error page -- as an implicit named exception * Exceptions in a servlet (or a JSP page that does not declare an errorPage directive) are handled via the standard error-page declaration in your web.xml file, which exposes the actual exception as request attribute javax.servlet.error.exception (Servlet 2.3, Section 9.9.2). Note that this attribute was new in 2.3, so isn't necessarily implemented by Tomcat 3.3. Personally, I never use the JSP errorPage attribute -- I prefer to use the error-page mechanism to handle all application exceptions, no matter where they were caused. The only practical difference is that you can't declare different error page handlers for different source JSP pages, but that has not been an issue for me. Cheers Drew Cox Craig McClanahan -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
