[ http://issues.apache.org/jira/browse/WICKET-8?page=all ]
Alastair Maw updated WICKET-8:
------------------------------
Attachment: DefaultRequestTargetResolverStrategy-WICKET-8.patch
I attach a patch which I believe fixes this issue. I've tested things on a
fairly complex site, and it certainly seems to work.
The issue appears to be that
DefaultRequestTargetResolverStrategy#resolve(RequestCycle, RequestParameters)
needs to drop its lock on the Session before calling resolveRenderedPage().
> deadlock contention for sessions
> --------------------------------
>
> Key: WICKET-8
> URL: http://issues.apache.org/jira/browse/WICKET-8
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.2.3, 1.3
> Reporter: Alastair Maw
> Assigned To: Johan Compagner
> Priority: Blocker
> Attachments: DefaultRequestTargetResolverStrategy-WICKET-8.patch,
> ResourceTestPage.html, ResourceTestPage.java
>
>
> I have a bunch of custom image thumbnails that each take a little while to
> serve up.
> With lots of them on the page at once I'm seeing what looks like a deadlock
> going on for the session objects. 1.2.2 didn't do this.
> Here's an edited thread-dump. There are lots of these:
> "http-8080-Processor26" daemon prio=1 tid=0x08875a60 nid=0x5480 waiting for
> monitor entry [0xa5ef9000..0xa5efee60]
> at
> wicket.request.compound.DefaultRequestTargetResolverStrategy.resolve(DefaultRequestTargetResolverStrategy.java:102)
> - waiting to lock <0xab6ee028> (a com.foo.MyWebSession)
> at
> wicket.request.compound.AbstractCompoundRequestCycleProcessor.resolve(AbstractCompoundRequestCycleProcessor.java:48)
> at wicket.RequestCycle.step(RequestCycle.java:992)
> at wicket.RequestCycle.steps(RequestCycle.java:1084)
> at wicket.RequestCycle.request(RequestCycle.java:454)
> at wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:219)
> [...]
> One of these:
> "http-8080-Processor23" daemon prio=1 tid=0x082a7988 nid=0x547a waiting for
> monitor entry [0xa5af8000..0xa5afd0e0]
> at wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:929)
> - waiting to lock <0xab6ee028> (a com.foo.MyWebSession)
> at wicket.RequestCycle.step(RequestCycle.java:1010)
> at wicket.RequestCycle.steps(RequestCycle.java:1084)
> at wicket.RequestCycle.request(RequestCycle.java:454)
> at wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:219)
> [...]
> And one of these:
> "http-8080-Processor20" daemon prio=1 tid=0x082a6978 nid=0x5116 in
> Object.wait() [0xa57f2000..0xa57f7160]
> at java.lang.Object.wait(Native Method)
> - waiting on <0xab7695c8> (a java.util.HashMap)
> at wicket.Session.getPage(Session.java:427)
> - locked <0xab7695c8> (a java.util.HashMap)
> at
> wicket.request.compound.DefaultRequestTargetResolverStrategy.resolveRenderedPage(DefaultRequestTargetResolverStrategy.java:215)
> at
> wicket.request.compound.DefaultRequestTargetResolverStrategy.resolve(DefaultRequestTargetResolverStrategy.java:152)
> - locked <0xab6ee028> (a com.foo.MyWebSession)
> at
> wicket.request.compound.AbstractCompoundRequestCycleProcessor.resolve(AbstractCompoundRequestCycleProcessor.java:48)
> at wicket.RequestCycle.step(RequestCycle.java:992)
> at wicket.RequestCycle.steps(RequestCycle.java:1084)
> at wicket.RequestCycle.request(RequestCycle.java:454)
> at wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:219)
> [...]
> Let me know if you need any more info. I can probably make an example webapp
> if required, but hopefully this will be sufficient.
> As far as I'm concerned it's pretty critical, as the entire session falls
> over and never recovers, so I'm marking it as a blocker. Hope that's OK.
--
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
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
