the problem with the approach is that a behavior is tired to a component that is tied to a page. any thread accessing the page needs to block because you dont want two or more theads working on the page.

i think you need to take a bit of a different approach

have a threadsafe queue of push events you want to be processed in the session/application and some way to publish them.

have the push behavior write out a tag for a hidden iframe that would then initiate the push request thread

have a processing strategy that handles this push request w/out touching pages and pushes _javascript_ form the sessions's queue


that way you have the decoupling that requires no blocking because your push thread doesnt access any objects that need to be synced save the session which can be accessed sync but you need to be careful

whenever something happens - that something publishes a push event to the queue and the push thread outputs it to the hidden iframe where the _javascript_ is processed.


-Igor


On 8/26/06, Lorin Metzger <[EMAIL PROTECTED]> wrote:
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())
  {
        try
        {
          wait(1000);
        }
        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?


Thanks,


-Lorin




-------------------------------------------------------------------------
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
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user



-------------------------------------------------------------------------
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
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Reply via email to