[ http://issues.apache.org/jira/browse/WICKET-8?page=all ]
Johan Compagner resolved WICKET-8.
----------------------------------
Fix Version/s: 1.2.3
2.0
Resolution: Fixed
the patch looks fine. Now we don't have a sync block in a sync block
This makes me wonder what kind of things we more have. We should really analyse
all sync blocks we have.
This sync block is only for one thing and that is the Pagemap access And then
more the AccessStack that needs to be synced
Better would be everywhere we touch the pagemap or page (in that pagemap) we
set a lock on that pagemap..
> 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
> Fix For: 1.2.3, 2.0
>
> 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
