Tapestry
  1. Tapestry
  2. TAPESTRY-2037

NullPointerException caused by many rapid page refreshes

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 5.0.7
    • Fix Version/s: 5.0.12
    • Component/s: tapestry-core, tapestry-ioc
    • Labels:
      None
    • Environment:
      jdk 1.5

      Description

      This was reported on the mailing list.

      In certain places, hitting the refresh button rapidly can cause a null pointer exception.

      It is believed this is related to a JDK 1.5 bug:

      http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6550283

      Tapestry makes a few uses of ThreadLocal that are consistent with this pattern. ThreadLocals are used to connect service proxies to perthread scope services.

      We will locate all useages of ThreadLocal and, alas, synchronize access to them.

      More discussion: http://markmail.org/message/7bwztu66paz2cfqm

        Issue Links

          Activity

          Hide
          Howard M. Lewis Ship added a comment -

          Really, this was fixed in 5.0.11, but we're accepting Robert's observations as proof it's really gone.

          Show
          Howard M. Lewis Ship added a comment - Really, this was fixed in 5.0.11, but we're accepting Robert's observations as proof it's really gone.
          Hide
          Robert Zeigler added a comment -

          I haven't seen the exception now for three weeks and counting, even in the app where, before, I was seeing it several times daily.
          I think it's safe to call this one fixed.

          Show
          Robert Zeigler added a comment - I haven't seen the exception now for three weeks and counting, even in the app where, before, I was seeing it several times daily. I think it's safe to call this one fixed.
          Hide
          Geoff Callender added a comment -

          Please ignore previous comment. The issue appears to have been resolved.
          I had dependency issues so I was running an older T5 than I thought. Sorry about that.

          Show
          Geoff Callender added a comment - Please ignore previous comment. The issue appears to have been resolved. I had dependency issues so I was running an older T5 than I thought. Sorry about that.
          Hide
          Geoff Callender added a comment -

          With snapshot 5.0.11-20080308.120020-32 I'm not getting the NPE on refresh error (Safari, OS X), BUT alas I am still getting the original problem that kicked off this issue - "While trying to demonstrate the dangers of multiple submits, I found Tapestry throwing NullPointerException".

          Here's how to reproduce it - click a few times quickly on this page's button:

          <html xmlns:t="http://tapestry.apache.org/schema/tapestry_5_0_0.xsd">
          <body>
          <form t:type="form">
          Click often:<input type="submit" value="Submit"/>
          </form>
          </body>
          </html>

          package xyz.pages;

          import xyz.MyOrder;

          import org.apache.tapestry.annotations.ApplicationState;

          public class Page1 {
          private final int ORDER_QTY = 1;

          @InjectPage
          private Page2 _page2;

          @ApplicationState
          private MyOrder _myOrder;

          void onSuccess()

          { sleep(3000); // Sleep 3 seconds to simulate busy system int newQuantity = _myOrder.getQuantity() + ORDER_QTY; _myOrder.setQuantity(newQuantity); }

          private void sleep(long duration) {
          try

          { Thread.sleep(duration); }

          catch (InterruptedException e) {
          }
          }

          public MyOrder getMyOrder()

          { return _myOrder; }

          }

          Stack trace I got was similar to Robert's but it did differ:

          23:08:23,291 ERROR [RequestExceptionHandler] Processing of request failed with uncaught exception: java.lang.NullPointerException
          java.lang.NullPointerException
          at org.apache.tapestry.services.TapestryModule$30.getCookies(TapestryModule.java:1832)
          at $CookieSource_1189dbcd764.getCookies($CookieSource_1189dbcd764.java)
          at org.apache.tapestry.internal.services.CookiesImpl.readCookieValue(CookiesImpl.java:61)
          at $Cookies_1189dbcd763.readCookieValue($Cookies_1189dbcd763.java)
          at org.apache.tapestry.internal.services.PersistentLocaleImpl.getCookieValue(PersistentLocaleImpl.java:50)
          at org.apache.tapestry.internal.services.PersistentLocaleImpl.get(PersistentLocaleImpl.java:43)
          at $PersistentLocale_1189dbcd762.get($PersistentLocale_1189dbcd762.java)
          at org.apache.tapestry.internal.services.LocalizationSetterImpl.setThreadLocale(LocalizationSetterImpl.java:97)
          at $LocalizationSetter_1189dbcd75e.setThreadLocale($LocalizationSetter_1189dbcd75e.java)
          at org.apache.tapestry.internal.services.LocalizationFilter.service(LocalizationFilter.java:41)
          at $RequestHandler_1189dbcd761.service($RequestHandler_1189dbcd761.java)
          at org.apache.tapestry.services.TapestryModule$3.service(TapestryModule.java:516)
          at $RequestHandler_1189dbcd761.service($RequestHandler_1189dbcd761.java)
          at org.apache.tapestry.services.TapestryModule$2.service(TapestryModule.java:491)
          at $RequestHandler_1189dbcd761.service($RequestHandler_1189dbcd761.java)
          at org.apache.tapestry.internal.services.IgnoredPathsFilter.service(IgnoredPathsFilter.java:53)
          at $RequestFilter_1189dbcd75f.service($RequestFilter_1189dbcd75f.java)
          at $RequestHandler_1189dbcd761.service($RequestHandler_1189dbcd761.java)
          at org.apache.tapestry.internal.services.StaticFilesFilter.service(StaticFilesFilter.java:79)
          at $RequestHandler_1189dbcd761.service($RequestHandler_1189dbcd761.java)
          at org.apache.tapestry.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:93)
          at org.apache.tapestry.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:84)
          at org.apache.tapestry.ioc.internal.util.ConcurrentBarrier.withRead(ConcurrentBarrier.java:77)
          at org.apache.tapestry.internal.services.CheckForUpdatesFilter.service(CheckForUpdatesFilter.java:106)
          at $RequestHandler_1189dbcd761.service($RequestHandler_1189dbcd761.java)
          at $RequestHandler_1189dbcd759.service($RequestHandler_1189dbcd759.java)
          at org.apache.tapestry.services.TapestryModule$12.service(TapestryModule.java:904)
          at $HttpServletRequestHandler_1189dbcd758.service($HttpServletRequestHandler_1189dbcd758.java)
          at org.apache.tapestry.TapestryFilter.doFilter(TapestryFilter.java:164)
          at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
          at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
          at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
          at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
          at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
          at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
          at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
          at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
          at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
          at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
          at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
          at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
          at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
          at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
          at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
          at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
          at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
          at java.lang.Thread.run(Thread.java:613)

          Show
          Geoff Callender added a comment - With snapshot 5.0.11-20080308.120020-32 I'm not getting the NPE on refresh error (Safari, OS X), BUT alas I am still getting the original problem that kicked off this issue - "While trying to demonstrate the dangers of multiple submits, I found Tapestry throwing NullPointerException". Here's how to reproduce it - click a few times quickly on this page's button: <html xmlns:t="http://tapestry.apache.org/schema/tapestry_5_0_0.xsd"> <body> <form t:type="form"> Click often:<input type="submit" value="Submit"/> </form> </body> </html> package xyz.pages; import xyz.MyOrder; import org.apache.tapestry.annotations.ApplicationState; public class Page1 { private final int ORDER_QTY = 1; @InjectPage private Page2 _page2; @ApplicationState private MyOrder _myOrder; void onSuccess() { sleep(3000); // Sleep 3 seconds to simulate busy system int newQuantity = _myOrder.getQuantity() + ORDER_QTY; _myOrder.setQuantity(newQuantity); } private void sleep(long duration) { try { Thread.sleep(duration); } catch (InterruptedException e) { } } public MyOrder getMyOrder() { return _myOrder; } } Stack trace I got was similar to Robert's but it did differ: 23:08:23,291 ERROR [RequestExceptionHandler] Processing of request failed with uncaught exception: java.lang.NullPointerException java.lang.NullPointerException at org.apache.tapestry.services.TapestryModule$30.getCookies(TapestryModule.java:1832) at $CookieSource_1189dbcd764.getCookies($CookieSource_1189dbcd764.java) at org.apache.tapestry.internal.services.CookiesImpl.readCookieValue(CookiesImpl.java:61) at $Cookies_1189dbcd763.readCookieValue($Cookies_1189dbcd763.java) at org.apache.tapestry.internal.services.PersistentLocaleImpl.getCookieValue(PersistentLocaleImpl.java:50) at org.apache.tapestry.internal.services.PersistentLocaleImpl.get(PersistentLocaleImpl.java:43) at $PersistentLocale_1189dbcd762.get($PersistentLocale_1189dbcd762.java) at org.apache.tapestry.internal.services.LocalizationSetterImpl.setThreadLocale(LocalizationSetterImpl.java:97) at $LocalizationSetter_1189dbcd75e.setThreadLocale($LocalizationSetter_1189dbcd75e.java) at org.apache.tapestry.internal.services.LocalizationFilter.service(LocalizationFilter.java:41) at $RequestHandler_1189dbcd761.service($RequestHandler_1189dbcd761.java) at org.apache.tapestry.services.TapestryModule$3.service(TapestryModule.java:516) at $RequestHandler_1189dbcd761.service($RequestHandler_1189dbcd761.java) at org.apache.tapestry.services.TapestryModule$2.service(TapestryModule.java:491) at $RequestHandler_1189dbcd761.service($RequestHandler_1189dbcd761.java) at org.apache.tapestry.internal.services.IgnoredPathsFilter.service(IgnoredPathsFilter.java:53) at $RequestFilter_1189dbcd75f.service($RequestFilter_1189dbcd75f.java) at $RequestHandler_1189dbcd761.service($RequestHandler_1189dbcd761.java) at org.apache.tapestry.internal.services.StaticFilesFilter.service(StaticFilesFilter.java:79) at $RequestHandler_1189dbcd761.service($RequestHandler_1189dbcd761.java) at org.apache.tapestry.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:93) at org.apache.tapestry.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:84) at org.apache.tapestry.ioc.internal.util.ConcurrentBarrier.withRead(ConcurrentBarrier.java:77) at org.apache.tapestry.internal.services.CheckForUpdatesFilter.service(CheckForUpdatesFilter.java:106) at $RequestHandler_1189dbcd761.service($RequestHandler_1189dbcd761.java) at $RequestHandler_1189dbcd759.service($RequestHandler_1189dbcd759.java) at org.apache.tapestry.services.TapestryModule$12.service(TapestryModule.java:904) at $HttpServletRequestHandler_1189dbcd758.service($HttpServletRequestHandler_1189dbcd758.java) at org.apache.tapestry.TapestryFilter.doFilter(TapestryFilter.java:164) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446) at java.lang.Thread.run(Thread.java:613)
          Hide
          Howard M. Lewis Ship added a comment -

          Great! Keep us posted and thanks for the help.

          Show
          Howard M. Lewis Ship added a comment - Great! Keep us posted and thanks for the help.
          Hide
          Robert Zeigler added a comment -

          Long delay; apologies. After upgrading to 5.0.11-SNAPSHOT, there were various things that needed changing, and new features that needed to be added, so it took a while to put an app where I frequently see this exception onto the boxes where I see it. I was able to put that up over the weekend. Crossing my fingers that the NPE go away; typically, I see several per day. Ironically, the next two weeks will be slow in terms of app usage. If I see the NPE again, I'll comment (so we know it's not fixed). During a typical-usage day, I see the NPE several times. So if I haven't seen it after the end of three weeks, I think it's fair to call it fixed.
          Crossing my fingers.

          Show
          Robert Zeigler added a comment - Long delay; apologies. After upgrading to 5.0.11-SNAPSHOT, there were various things that needed changing, and new features that needed to be added, so it took a while to put an app where I frequently see this exception onto the boxes where I see it. I was able to put that up over the weekend. Crossing my fingers that the NPE go away; typically, I see several per day. Ironically, the next two weeks will be slow in terms of app usage. If I see the NPE again, I'll comment (so we know it's not fixed). During a typical-usage day, I see the NPE several times. So if I haven't seen it after the end of three weeks, I think it's fair to call it fixed. Crossing my fingers.
          Hide
          Robert Zeigler added a comment -

          I'll try out 5.0.11-SNAPSHOT and see if the issue continues to surface.

          Show
          Robert Zeigler added a comment - I'll try out 5.0.11-SNAPSHOT and see if the issue continues to surface.
          Hide
          Howard M. Lewis Ship added a comment -

          With the fix to TAPESTRY-2141, I'm crossing my fingers that this behavior is fixed.

          Show
          Howard M. Lewis Ship added a comment - With the fix to TAPESTRY-2141 , I'm crossing my fingers that this behavior is fixed.
          Hide
          Howard M. Lewis Ship added a comment -

          Looks highly llikely that these two issues are related. It would be interesting to use a JDK 1.6 and see if that resolves the problem as well.

          Show
          Howard M. Lewis Ship added a comment - Looks highly llikely that these two issues are related. It would be interesting to use a JDK 1.6 and see if that resolves the problem as well.
          Hide
          Robert Zeigler added a comment -

          Sorry, focus on this issue has been scattered; it happens often enough to be annoying, but not often enough to be top priority for me.

          In terms of the "easy to recreate", it still isn't so. That the trivial app recreated the issue suggests that the issue isn't (necessarily) my application code. However, the occurrence of the error in the trivial app is still few and far between, so "proving fixed" proves difficult.

          I can say that in 5.0.10-SNAPSHOT, I'm still seeing this issue on a dual-core box running debian linux on tomcat 4.1.

          Show
          Robert Zeigler added a comment - Sorry, focus on this issue has been scattered; it happens often enough to be annoying, but not often enough to be top priority for me. In terms of the "easy to recreate", it still isn't so. That the trivial app recreated the issue suggests that the issue isn't (necessarily) my application code. However, the occurrence of the error in the trivial app is still few and far between, so "proving fixed" proves difficult. I can say that in 5.0.10-SNAPSHOT, I'm still seeing this issue on a dual-core box running debian linux on tomcat 4.1.
          Hide
          Howard M. Lewis Ship added a comment -

          I guess this is good news ... if its this easy to recreate on 5.0.5, it should be easy to prove it fixed for 5.0.9?

          Show
          Howard M. Lewis Ship added a comment - I guess this is good news ... if its this easy to recreate on 5.0.5, it should be easy to prove it fixed for 5.0.9?
          Hide
          Robert Zeigler added a comment -

          New stack trace.
          Definitely looks like a jdk issue.
          This is from a trivial app. It has one form, but the exception was encountered when hitting the main page.
          There is /no/ db access, no request filters (aside from the example timing filter), etc.

          This is Tapestry 5.0.5 (it will be awhile before I can update this app due to external constraints).

          But it certainly does suggest that ThreadLocale is an issue.

          java.lang.NullPointerException
          at java.lang.ThreadLocal$ThreadLocalMap$Entry.access$602(ThreadLocal.java:235)
          at java.lang.ThreadLocal$ThreadLocalMap.replaceStaleEntry(ThreadLocal.java:518)
          at java.lang.ThreadLocal$ThreadLocalMap.getAfterMiss(ThreadLocal.java:368)
          at java.lang.ThreadLocal$ThreadLocalMap.get(ThreadLocal.java:347)
          at java.lang.ThreadLocal$ThreadLocalMap.access$000(ThreadLocal.java:225)
          at java.lang.ThreadLocal.get(ThreadLocal.java:127)
          at org.apache.tapestry.ioc.internal.services.PerThreadServiceCreator.createObject(PerThreadServiceCreator.java:56)
          at $RequestGlobals_117c6f995f8._perThreadInstance($RequestGlobals_117c6f995f8.java)
          at $RequestGlobals_117c6f995f8.store($RequestGlobals_117c6f995f8.java)
          at $RequestGlobals_117c6f995e4.store($RequestGlobals_117c6f995e4.java)
          at org.apache.tapestry.services.TapestryModule$11.service(TapestryModule.java:1042)
          at $HttpServletRequestHandler_117c6f995f5.service($HttpServletRequestHandler_117c6f995f5.java)
          at org.apache.tapestry.TapestryFilter.doFilter(TapestryFilter.java:135)
          at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:213)
          at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
          at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:243)
          at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
          at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
          at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
          at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:190)
          at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
          at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
          at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
          at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2343)
          at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
          at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
          at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170)
          at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
          at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170)
          at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
          at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:468)
          at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
          at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
          at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
          at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
          at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
          at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
          at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
          at org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java:429)
          at org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:495)
          at java.lang.Thread.run(Thread.java:595)

          I've continued to try to track this down.
          One thing I found, pre tapestry 5.0.10-SNAPSHOT is that the if an exception is thrown in a request filter, you wind up with a null pointer exception trying to handle the exception. This seems to be fixed in 5.0.10-SNAPSHOT (due to reworking the ordering of tapestry's request filter, perhaps?)

          Sorry for the meandering, I have scattered thoughts on this right now, and I'm jotting them down so I don't forget them. Still trying to build a case where I can consistently generate an exception.

          Show
          Robert Zeigler added a comment - New stack trace. Definitely looks like a jdk issue. This is from a trivial app. It has one form, but the exception was encountered when hitting the main page. There is /no/ db access, no request filters (aside from the example timing filter), etc. This is Tapestry 5.0.5 (it will be awhile before I can update this app due to external constraints). But it certainly does suggest that ThreadLocale is an issue. java.lang.NullPointerException at java.lang.ThreadLocal$ThreadLocalMap$Entry.access$602(ThreadLocal.java:235) at java.lang.ThreadLocal$ThreadLocalMap.replaceStaleEntry(ThreadLocal.java:518) at java.lang.ThreadLocal$ThreadLocalMap.getAfterMiss(ThreadLocal.java:368) at java.lang.ThreadLocal$ThreadLocalMap.get(ThreadLocal.java:347) at java.lang.ThreadLocal$ThreadLocalMap.access$000(ThreadLocal.java:225) at java.lang.ThreadLocal.get(ThreadLocal.java:127) at org.apache.tapestry.ioc.internal.services.PerThreadServiceCreator.createObject(PerThreadServiceCreator.java:56) at $RequestGlobals_117c6f995f8._perThreadInstance($RequestGlobals_117c6f995f8.java) at $RequestGlobals_117c6f995f8.store($RequestGlobals_117c6f995f8.java) at $RequestGlobals_117c6f995e4.store($RequestGlobals_117c6f995e4.java) at org.apache.tapestry.services.TapestryModule$11.service(TapestryModule.java:1042) at $HttpServletRequestHandler_117c6f995f5.service($HttpServletRequestHandler_117c6f995f5.java) at org.apache.tapestry.TapestryFilter.doFilter(TapestryFilter.java:135) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:213) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:243) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:190) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2343) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:468) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java:429) at org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:495) at java.lang.Thread.run(Thread.java:595) I've continued to try to track this down. One thing I found, pre tapestry 5.0.10-SNAPSHOT is that the if an exception is thrown in a request filter, you wind up with a null pointer exception trying to handle the exception. This seems to be fixed in 5.0.10-SNAPSHOT (due to reworking the ordering of tapestry's request filter, perhaps?) Sorry for the meandering, I have scattered thoughts on this right now, and I'm jotting them down so I don't forget them. Still trying to build a case where I can consistently generate an exception.
          Hide
          Howard M. Lewis Ship added a comment -

          From the mailing list:

          nterestingly, I can't reproduce the issue on OS X, either. The
          servers where I see the exceptions are debian linux servers, running
          sun's jdk, version 1.5.0_09-b01 on one server, 1.5.0_10 on another,
          and 1.5.0_12-b04 on another. All three machines are dual processor
          machines.

          The server where I most frequently see the exception is the one
          running jdk 1.5.0_09-b01. But it's also the box with the most traffic
          by far, so it's probably that the frequency of exceptions is a
          function of the use of the box, rather than the version.

          I've got a small test app that I'm going to try running on the box to
          see if I can recreate the bug on linux, since I can't duplicate it on
          os x.

          Show
          Howard M. Lewis Ship added a comment - From the mailing list: nterestingly, I can't reproduce the issue on OS X, either. The servers where I see the exceptions are debian linux servers, running sun's jdk, version 1.5.0_09-b01 on one server, 1.5.0_10 on another, and 1.5.0_12-b04 on another. All three machines are dual processor machines. The server where I most frequently see the exception is the one running jdk 1.5.0_09-b01. But it's also the box with the most traffic by far, so it's probably that the frequency of exceptions is a function of the use of the box, rather than the version. I've got a small test app that I'm going to try running on the box to see if I can recreate the bug on linux, since I can't duplicate it on os x.
          Hide
          Howard M. Lewis Ship added a comment -

          Ok, now I have 13 windows running curl against a couple of different pages, and I'm running interactively. This is fun .. .the performance is still quit good for the interactive client. No sign of an exception yet.

          Response rate, measured via FireBug, bounces all over the place: 9ms up to 650ms.

          Show
          Howard M. Lewis Ship added a comment - Ok, now I have 13 windows running curl against a couple of different pages, and I'm running interactively. This is fun .. .the performance is still quit good for the interactive client. No sign of an exception yet. Response rate, measured via FireBug, bounces all over the place: 9ms up to 650ms.
          Hide
          Howard M. Lewis Ship added a comment -

          I'm still having trouble reproducing it under Mac OS X. What is your exact environment? OS version, JDK version, etc?

          I'm running the app in the debugger.

          I have three windows in a tight loop executing requests on the app:

          while true; do curl -O -g http://localhost:8080/validform; done

          I did find one potential deadlock situation inside ThreadCleanupHubImpl, but I haven't been able to get an exception thrown.

          Show
          Howard M. Lewis Ship added a comment - I'm still having trouble reproducing it under Mac OS X. What is your exact environment? OS version, JDK version, etc? I'm running the app in the debugger. I have three windows in a tight loop executing requests on the app: while true; do curl -O -g http://localhost:8080/validform ; done I did find one potential deadlock situation inside ThreadCleanupHubImpl, but I haven't been able to get an exception thrown.
          Hide
          Howard M. Lewis Ship added a comment -

          Please go into your logs and capture the full exception.

          Be careful ... fundamental bugs like this can throw exceptions while reporting an exception, try to get the true, deepest, most underlying cause exception.

          Show
          Howard M. Lewis Ship added a comment - Please go into your logs and capture the full exception. Be careful ... fundamental bugs like this can throw exceptions while reporting an exception, try to get the true, deepest, most underlying cause exception.
          Hide
          Robert Zeigler added a comment -

          Should probably reopen this one. I deployed the 5.0.8 nightly build (1/15/08 build) and I'm still seeing this exception (deployed it late last night; so far, the exception has been hit 3 times today). I'll see if I can come up with a case to consistently reproduce the problem this weekend.

          Show
          Robert Zeigler added a comment - Should probably reopen this one. I deployed the 5.0.8 nightly build (1/15/08 build) and I'm still seeing this exception (deployed it late last night; so far, the exception has been hit 3 times today). I'll see if I can come up with a case to consistently reproduce the problem this weekend.
          Hide
          Howard M. Lewis Ship added a comment -

          Marking this fixed is a stretch, since I'm not sure how to reliably reproduce it. I have found the (fortunately, few) places where ThreadLocal objects were being used, and guarded access to them using synchronized blocks. One further place, part of ConcurrentBarrier, was already guarded via a ReentrantReadWriteLock.

          Show
          Howard M. Lewis Ship added a comment - Marking this fixed is a stretch, since I'm not sure how to reliably reproduce it. I have found the (fortunately, few) places where ThreadLocal objects were being used, and guarded access to them using synchronized blocks. One further place, part of ConcurrentBarrier, was already guarded via a ReentrantReadWriteLock.

            People

            • Assignee:
              Howard M. Lewis Ship
              Reporter:
              Howard M. Lewis Ship
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development