1 Reply Latest reply on Feb 5, 2007 1:36 AM by flarosa

    Major problem using error-page element in web.xml

    flarosa

      Hi,

      I have a JBoss installation running on SUSE Linux which has been running without problems for many months.

      A few days ago, I added a simple <error-page> element to the web.xml file of one of my applications:

      <error-page>
       <error-code>404</error-code>
       <location>/default.jsp</location>
       </error-page>


      A few hours after adding this, my server stopped responding. I checked the logs and found a whole slew of "too many open files" errors. I did not think this was related to my error page at the time. I upped the open file limit on my server from 1024 to 32768, and restarted JBoss.

      Three days later, the same error has appeared. At the same time, I am also noticing thousands of these errors in my log:

      2007-02-04 00:04:27,892 WARN
      [org.apache.catalina.core.ContainerBase.[jboss.web].[june.zanne.com]] Exception Processing
      ErrorPage[errorCode=404, location=/default.jsp]
      ClientAbortException: java.net.SocketException: Connection reset
      at
      org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:327)
      at
      org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:293)
      at
      org.apache.catalina.connector.Response.flushBuffer(Response.java:534)
      at
      org.apache.catalina.core.StandardHostValve.status(StandardHostValve.java:285)
      at
      org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:136)
      at
      org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
      at
      org.apache.catalina.valves.FastCommonAccessLogValve.invoke(FastCommonAccessLogValve.java:481)
      at
      org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
      at
      org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
      at
      org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
      at
      org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
      at
      org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
      at
      org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
      at java.lang.Thread.run(Thread.java:619)

      I have never seen this kind of exception in my logs before.

      My suspicion is that the problems are related - that the Socket exception is leaking file handles, which eventually leads to all my file handles being exhaused.

      Has anyone seen this before?

      Thanks,
      Frank

        • 1. Re: Major problem using error-page element in web.xml
          flarosa

          Here's some more information about my issue -

          I've determined that the problem occurs when a request for a document in a non-existent directory is received, and replaced with /default.jsp.

          Default.jsp contains relative references to a CSS file and some image files. When the browser tries to get these, it tries to get them out of the non-existent directory specified in the original URL; this is when the exceptions occur in the log.

          I would guess that what is happening is this:
          (a) The browser tries to retrieve the image from the bad URL;
          (b) The server starts serving up the default.jsp page instead;
          (c) The browser sees that it's getting HTML instead of an image, and closes its socket;
          (d) The server gets an exception while trying to write to the socket, and in doing so, fails to release some resource.

          Changing the references in default.jsp to absolute references does prevent the problem from occuring regularly. Still, if this is really what is happening, it's very troubling. There are lots of other ways sockets can close early, not to mention the potential for someone to write a program specifically to exploit the problem.

          In fact, a check of my logs shows that I'm still getting the exception but in much smaller numbers. Probably because web pages unknown to me are linking to bad images (there was an old web site at the same domain name for many years, hence the need for the 404 redirect).

          Frank