Eelco Hillenius wrote:
On 8/25/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
  
i might be totally missing something - but dont you need a special servlet
container that maintains open socket separate from threads by using nio?
like jetty 6? and then once you have that you need to use that servlet
container's special api to do this?
    

Yeah, I think so too. Isn't that why our issue
(http://sourceforge.net/tracker/index.php?func=detail&aid=1294920&group_id=119783&atid=684978,
 Lorin if you are interested in it, feel free to open that issue
again) is specifically for Jetty?
  
Right, you do need a Servlet containers specific API to do this and achieve any kind of performance for just the reason that Igor mentioned.  So you would need to specifically use Jetty's API.  Jetty Continuations differ from other solutions however, because if a Servlet container does not support Continuations, it will just fallback to threadful waiting, i.e. (100 users 100 threads), but won't actually fail unlike, Tomcat's CometServlet, and BEA's AbstractAsyncServlet.    Please note

http://blogs.webtide.com/gregw/2006/07/25/1153845234453.html


I apologize, last night when I was searching I did not come across posting on the issue tracker.


For me the servlet container specific things are less of an issue, maybe its because of my lack of familiarity with wicket, but let me try to rephrase my question this way.


I don't care about performance (lets pretend), and I'm willing to waste one thread for every blocked request.  Do you have any suggestion about the best way I could asynchrously call the server through wicket, have that request be blocked, and then based upon some action on the server have that thread wake up, and send updated data back to the server.


I like the idea of the AjaxPushBehavior mentioned in the issue tracker posting.  At one point I tried extending AbstractDefaultAjaxBehavior, and adding an addOnLoadModifier() which asynchrously called back on page load and then I blocked that thread, with the intention of waking up that thread and calling AjaxRequestTarget.addComponent when some action took place on the server.  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.


I'm willing to open the issue back up and work on it, but considering my failure in the above mentioned paragraph I'm not exactly sure what the right approach is for the wicket aspects to asynchronously call back to the server, block that requests, and then send updates via that blocked request.   Am I conceptually missing something about here?


with the current architecture if you have a hundred clients doing comet you
will have a hundred threads - not so good.
    

Yeah. What do you think Lorin? Is there something we might have missed
from e.g. DWR? An alternative for your use case that would work today
is AJAX polling. Comet style afaik is an optimization of this polling
anyway.
  
Right polling would work, and COMET is just an optimization, but it could be useful for other things :)


Thanks for the feedback,


-Lorin

Eelco

-------------------------------------------------------------------------
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