You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Denis Laroche <dl...@gmail.com> on 2011/02/17 17:15:01 UTC

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

Re: requests die with a stack overflow

Posted by Denis Laroche <dl...@gmail.com>.
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 <Ch...@unisys.com>

> > From: Denis Laroche [mailto:dlaroche7@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

RE: requests die with a stack overflow

Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Denis Laroche [mailto:dlaroche7@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: requests die with a stack overflow

Posted by Denis Laroche <dl...@gmail.com>.
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-name>action</servlet-name>
    <servlet-class>
      ca.pwc.tfc.piservice.PiServiceActionServlet
    </servlet-class>
    <init-param>
      <param-name>config</param-name>
      <param-value>/WEB-INF/struts-config.xml</param-value>
    </init-param>
    <init-param>
      <param-name>config-data</param-name>
      <param-value>/WEB-INF/config.xml</param-value>
    </init-param>
    <init-param>
      <param-name>validate</param-name>
      <param-value>true</param-value>
    </init-param>
    <init-param>
      <param-name>default-encoding</param-name>
      <param-value>utf-8</param-value>
    </init-param>
    <load-on-startup>2</load-on-startup>
  </servlet>

 <!-- Standard Action Servlet Mapping -->
  <servlet-mapping>
    <servlet-name>action</servlet-name>
    <url-pattern>*.do</url-pattern>
  </servlet-mapping>

  <session-config>
    <session-timeout>
      15
    </session-timeout>
  </session-config>

  <welcome-file-list>
   <welcome-file>pages/welcome.jsp</welcome-file>
  </welcome-file-list>
</web-app>


2011/2/17 Konstantin Kolinko <kn...@gmail.com>

> 2011/2/17 Denis Laroche <dl...@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

Re: requests die with a stack overflow

Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/2/17 Denis Laroche <dl...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org