[
https://issues.apache.org/jira/browse/TAPESTRY-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563824#action_12563824
]
Robert Zeigler commented on TAPESTRY-2037:
------------------------------------------
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.
> NullPointerException caused by many rapid page refreshes
> --------------------------------------------------------
>
> Key: TAPESTRY-2037
> URL: https://issues.apache.org/jira/browse/TAPESTRY-2037
> Project: Tapestry
> Issue Type: Bug
> Components: tapestry-core, tapestry-ioc
> Affects Versions: 5.0.7
> Environment: jdk 1.5
> Reporter: Howard M. Lewis Ship
> Assignee: Howard M. Lewis Ship
> Priority: Critical
> Fix For: 5.0.10
>
>
> 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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
