requests die with a stack overflow
Hello all, I also posted this message to the Struts mailing list, because I'm not sure where the problem is. The version of Tomcat is 6.0.29, and the JVM is 1.6.0_17-b17 running on a Linux server, kernel version 2.6.18. The version of Struts is 1.3.10. Once in a while, the application starts behaving erratically with huge stack traces generated in the log file of the application. When the application starts behaving this way, all requests fail and they all generate those huge stack traces. The log file reaches 1 gigabyte in no time. I've attached one of those stack traces which I compressed with gzip. The trace is 3756 lines long! Any help would be greatly appreciated. -- D. Laroche Pratt Whitney Canada application.log.gz Description: GNU Zip compressed data - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: requests die with a stack overflow
I have no such thing as filters in my configuration. I reproduced the web descriptor file below. All the interactions between the browser and the server are done with Ajax requests that execute Struts actions. I'm using the Dojo toolkit for the JavaScript running in the browser. The application only has one JSP page, welcome.jsp, which just redirects to the one HTML page of the application. Everything else is built dynamically with Dojo dijits and Ajax requests to get data from the server. Thanks for your reply. web descriptor file ?xml version=1.0 encoding=ISO-8859-1? web-app xmlns=http://java.sun.com/xml/ns/j2ee; version=2.4 display-name PI web service /display-name description PI web service /description !-- Standard Action Servlet Configuration (with debugging) -- servlet servlet-nameaction/servlet-name servlet-class ca.pwc.tfc.piservice.PiServiceActionServlet /servlet-class init-param param-nameconfig/param-name param-value/WEB-INF/struts-config.xml/param-value /init-param init-param param-nameconfig-data/param-name param-value/WEB-INF/config.xml/param-value /init-param init-param param-namevalidate/param-name param-valuetrue/param-value /init-param init-param param-namedefault-encoding/param-name param-valueutf-8/param-value /init-param load-on-startup2/load-on-startup /servlet !-- Standard Action Servlet Mapping -- servlet-mapping servlet-nameaction/servlet-name url-pattern*.do/url-pattern /servlet-mapping session-config session-timeout 15 /session-timeout /session-config welcome-file-list welcome-filepages/welcome.jsp/welcome-file /welcome-file-list /web-app 2011/2/17 Konstantin Kolinko knst.koli...@gmail.com 2011/2/17 Denis Laroche dlaroc...@gmail.com: Hello all, I also posted this message to the Struts mailing list, because I'm not sure where the problem is. The version of Tomcat is 6.0.29, and the JVM is 1.6.0_17-b17 running on a Linux server, kernel version 2.6.18. The version of Struts is 1.3.10. Once in a while, the application starts behaving erratically with huge stack traces generated in the log file of the application. When the application starts behaving this way, all requests fail and they all generate those huge stack traces. The log file reaches 1 gigabyte in no time. I've attached one of those stack traces which I compressed with gzip. The trace is 3756 lines long! A filter performs a forward which is then intercepted by the same filter, and so on in a loop. Either fix the condition that triggers the loop, or map the filter to process only incoming requests (see how it mapped in your web.xml, what dispatcher is specified in your filter-mapping). I think that you can use request.setAttribute() and then check if the attribute is present to detect looping. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: requests die with a stack overflow
That forwarding to itself behavior has to be triggered under special circumstances because the application can work ok for long periods of time. But you're probably pointing me in the right direction because I have a base action class from which all other actions derive and in the base there is code to detect session timeouts (by comparing the requested session id with the current session id) and that code redirects to the home page action when a timeout is detected. That's probably when the looping is triggered somehow. I'll modify that base class and see what happens. Thanks for the reply. -- DL I have a base action class from which all other action classes derive. 2011/2/17 Caldarale, Charles R chuck.caldar...@unisys.com From: Denis Laroche [mailto:dlaroc...@gmail.com] Subject: Re: requests die with a stack overflow I have no such thing as filters in my configuration. No, but you have struts rules configured that are effectively the same thing. Something in your struts config keeps forwarding to itself. - 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: Struts application used as a web service (large number of sessions)
Ok thanks, your explanations were very useful. I'll do what you suggested, i.e. not create a session for the Struts actions matching the web service clients. -- DL André Warnier a...@ice-sa.com 2011-02-15 06:02 PM Please respond to Tomcat Users List users@tomcat.apache.org To Tomcat Users List users@tomcat.apache.org cc Subject Re: Struts application used as a web service (large number of sessions) denis.laro...@pwc.ca wrote: Hello everybody, I wrote a Struts application deployed on a Tomcat server that is used as a web service. What I see is that for every request sent by the client applications a new session is created; I guess this is because there's no JSESSIONID cookie sent with the request. Could someone tell me if it's terribly inefficient for the server to have to create a new session for every request? I could reduce the session timeout to the minimum, but the application is also used by interactive users so the session timeout needs to have a reasonable value. HttpSession (HttpRequest.)getSession() : Returns the current session associated with this request, or if the request does not have a session, creates one. HttpSession : http://tomcat.apache.org/tomcat-5.5-doc/servletapi/javax/servlet/http/HttpSession.html A session is created when there is a call to getSession(). No call to getSession(), no session. In the big scheme of things, from the above descriptions, I would tend to think that a session object is not something trivial, so creating one when you don't need it is probably indeed quite inefficient. (And then the session has to be stored somewhere, which will involve serialization, I/O etc..; and then some background task still has to periodically go clean up these useless sessions). From your description, it seems as if there are two types of usage of the same application : - a usage by real users, which does require a session - a usage as a web service, which does not require a session (because these are one-off calls, probably) I don't know Struts at all, but is it possible to distinguish the two types of usage, and bypass the getSession() call when the application is used as a web service ? Otherwise, would it be possible to set up two instances of your application ? Such as : /webapp1 : used by interactive users /webapp2 : used by web service clients and remove the getSession() call in the one used as a web service ? Now again, inefficiency is a relative concept. If your server is 50% idle anyway, you do not really want to spend a lot of time bringing it to 60% idle. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Struts application used as a web service (large number of sessions)
Hello everybody, I wrote a Struts application deployed on a Tomcat server that is used as a web service. What I see is that for every request sent by the client applications a new session is created; I guess this is because there's no JSESSIONID cookie sent with the request. Could someone tell me if it's terribly inefficient for the server to have to create a new session for every request? I could reduce the session timeout to the minimum, but the application is also used by interactive users so the session timeout needs to have a reasonable value. Thanks in advance. -- D. Laroche Pratt Whitney Canada --- Ce courriel contient des renseignements confidentiels de PWC et le fait de le recevoir ne constitue pas une autorisation d'en utiliser ou divulguer le contenu. This email contains confidential information of PWC and its receipt does not constitute an authorization to use or disclose its contents. ---
