[ http://issues.apache.org/jira/browse/WICKET-8?page=comments#action_12443314 ] Alastair Maw commented on WICKET-8: -----------------------------------
If you just open the page in a single Firefox, loading up the images is generally enough to trigger the problem, but I've create a App1Test3 and ResourceTestPage in threadtest which demonstrates this problem clearly. Eelco's kindly committed it. fwiw, ivaynberg's also running into this right now. > 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: 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
