Lorin Metzger wrote:
Eelco Hillenius wrote:
 The problem that I had was that it seemed like all other
requests for that session were also blocked even ones that had nothing to do
with that behavior.

You would have to make sure the request for a push behavior is handled
by it's own IRequestTarget, which then would return null at the
getLock method. That would prevent the request being synchronized on
the whole session. This also means you have to take care about the
reentrant behavior of that push behavior. 
Hi,  I created a separate IRequestTarget, that returned NULL for getLock(RequestCycle), to handle a new push behavior.  I've verified that the un-synchronized
doProcessEventsAndRespond(processor); is called in RequestCycle.java line 884 Wicket 1.2.1.  by calling Thread.dumpStack().   Unfortunately all subsequent requests are still being blocked when I block the thread that handles my behavior.

I spun off a separate thread in my application that dumps the stack of all active threads, as far as I can tell all subsequent requests are being blocked in Session.getPage(...).  line 404.

This is the relevant code in Session.java:

 Thread t = (Thread)usedPages.get(id);
  while (t != null && t != Thread.currentThread())
        catch (InterruptedException ex)
          throw new WicketRuntimeException(ex);
        t = (Thread)usedPages.get(id);

I'm guessing that the Thread returned by usedPages.get(id) is actually the initial Thread that I blocked for my PushBehavior.  So t will never == Thread.currentThread()  or null until I release that Thread?  

Does the fact that the Thread used to handle my Behavior (appears to be) is in usedPages indicate that I have done something horribly wrong?



Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
Wicket-user mailing list

Reply via email to