[jira] Commented: (TAPESTRY-276) NullPointerException in AbstractEngine under high load

["Michael Echerer (JIRA)" <ta...@jakarta.apache.org>]

     [ http://issues.apache.org/jira/browse/TAPESTRY-276?page=comments#action_60291 ]
     
Michael Echerer commented on TAPESTRY-276:
------------------------------------------

May close this issue. It's a "no bug", sorry.

An overriden createCycle method of a custom engine threw an exception. A cycle==null was the result. Unfortunately the underlying Tapestry classes swallowed all exceptions in such a way that we first had no clue that any of our own classes were involved (nothing in the stack trace)... Probably one could improve the way such fatal exceptions are re-thrown...


> NullPointerException in AbstractEngine under high load
> ------------------------------------------------------
>
>          Key: TAPESTRY-276
>          URL: http://issues.apache.org/jira/browse/TAPESTRY-276
>      Project: Tapestry
>         Type: Bug
>   Components: Framework
>     Versions: 3.0.1
>  Environment: J2SDK 1.4.2_06, Tomcat 5.0.28, Solaris 2.8, Tapestry 3.0.1
> Web application using many assets for images and css files.
>     Reporter: Michael Echerer
>     Priority: Critical

>
> While load testing our application we detected that the AbstractEngine threw NullPointerExceptions wrapped in ServletExceptions. Our load testing software shows that those errors pop up when loading CSS or image files randomly which use the AssetService (/app?service=asset...). The visual effect or missing images, resp. CSS styles because HTTP 500 internal server errors occur as we can reproduce it less frequently with a browser, too.
> javax.servlet.ServletException
>  
> java.lang.NullPointerException
> org.apache.tapestry.engine.AbstractEngine.activateExceptionPage(AbstractEngine.java:453)
> org.apache.tapestry.engine.AbstractEngine.service(AbstractEngine.java:914)
> org.apache.tapestry.ApplicationServlet.doService(ApplicationServlet.java:197)
> org.apache.tapestry.ApplicationServlet.doGet(ApplicationServlet.java:158)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
> We think the bug is in 
> public boolean service(RequestContext context) throws ServletException, IOException
> the IRequestCycle cycle = null; and under rare circumstances it might stay null and produces the NullPointerException that even prevents the error page to be activated.
> Probably some race condition in service.getService(serviceName), e.g. the _serviceMap in servletContext or something around.
> We didn't yet trace down the service method and why it can throw an exception, that is first catched but thrown again. Unfortunately it cascades in a way that it's possible for the cycle to stay null. This breaks the exception page mechanismn as it needs a cycle at least.
> The last catch block in service() uses the cycle that may never been set to non null.
> activateExceptionPage(cycle, output, ex);
> The initial exception seems to be caused by means to determine a service. Which explains why it might happen only in one of our application that makes heavy use of assets. (although the other apps are quite similar and build upon common components, but not as complex).
> Further details will follow... We'll first try to override the service method in our application with a simple synchronized block calling super.service(). If the problem disappear this would point towards a threading issue.
> Cheers,
> Michael

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org