EXT-JS does a nice queueing model where you can set a queue timer (say 100ms) and any AJAX requests get bundled up into a single package that goes across the wire at once, returning and then being sent back to their callers.
This lets a page update many components at once in what appears to be real-time without blocking. Might be an interesting model for wicket at some point in the future. Yes, I know, EST-JS is a client-side framework. I am only using it as an example of how some stacks are resolving these sorts of issues. John- On Fri, Nov 12, 2010 at 9:36 AM, Josh Kamau <[email protected]> wrote: > AjaxSelfUpdatingTimerBehavior works perfectly for notifications. I guess it > wouldnt work very well for a chat-like scenario. I have set mine to 30 > seconds and it works perfectly. Long polling would hold a request with > nothing to report back in most of the times. > > regards. > > On Fri, Nov 12, 2010 at 12:17 PM, Igor Vaynberg > <[email protected]>wrote: > >> why would you need a request every few milliseconds. what is so urgent >> about a notification that you cant poll every ten seconds? >> >> what your long polling thread can do is access the page, render a part >> of it, and send it back to the client - but, only when it has >> something to say. which instead of many very quick requests to the >> page is many very quick accesses to the page. >> >> -igor >> >> On Fri, Nov 12, 2010 at 9:13 AM, José Monzón <[email protected]> wrote: >> > AjaxSelfUpdatingTimerBehavior is cool for simple repetitive requests. >> > But if you try to do long polling with that (comet, retain the request >> > in the server as long as you can while there's nothing to send back) >> > you will see how your other ajax requests are queued and your page >> > freezes. >> > >> > I've seen many people using AjaxSelfUpdatingTimerBehavior to replace >> > long poling. Performing very quick requests to the server (every few >> > millisecons). I believe that abusing AjaxSelfUpdatingTimerBehavior >> > leads you to scalability issues. Not to mention that the browser gets >> > choppy in slow computers. >> > >> > >> > On Fri, Nov 12, 2010 at 4:42 PM, Josh Kamau <[email protected]> >> wrote: >> >> I have implemented an application that alerts the user on various >> events. I >> >> created a notification's bar at the top of my page. This bar has a panel >> on >> >> which i added AjaxSelfUpdatingTimerBehavior. The Panel is available in >> all >> >> pages. whatever the page the use is, as long as the panel is rendered, >> it >> >> polls the server on regular intervals and displays notifications for >> various >> >> events - the facebook style. This is one of the features that has made >> me >> >> stick with wicket. >> >> >> >> regards. >> >> Josh >> >> >> >> >> >> 1. >> >> >> http://wicket.apache.org/apidocs/1.4/org/apache/wicket/ajax/AjaxSelfUpdatingTimerBehavior.html >> >> >> >> On Fri, Nov 12, 2010 at 10:37 AM, Frank van Lankvelt < >> >> [email protected]> wrote: >> >> >> >>> On Fri, Nov 12, 2010 at 3:55 PM, José Monzón <[email protected]> >> wrote: >> >>> > I recently run into a problem that has make me consider whether >> >>> > continuing using Wicket or not for a project. I hope guys you can >> >>> > throw some light into it. >> >>> > >> >>> > I need to create a web application that uses ajax to keep itself >> >>> > udpated while still allows the user interact with it also using Ajax. >> >>> > Imagine something as GMail, Documents, Facebook, Twitter, etc. >> >>> > >> >>> > On this pages, is very common to have some ajax COMMET, long polling >> >>> > or also known as inverse AJAX to keep the page updated. But that >> >>> > doesn't prevent the user to click here and there and update the page >> >>> > also using AJAX. They are independent XMLHttpRequest with a browser >> >>> > can handle perfectly. >> >>> > >> >>> > I was thinking about doing this on Wicket, but apparently it's >> >>> > impossible by design: >> >>> > https://issues.apache.org/jira/browse/WICKET-2437 >> >>> > >> >>> > Page objects aren't thread-safe and wicket will block any other >> thread >> >>> > (AJAX call) that tries to access the page while another request (for >> >>> > instance our long poll) is there. >> >>> > >> >>> > Have you ever find yourself into this kind of problem? What's the >> >>> > workaround if any? >> >>> > >> >>> the comet-like functionality is useful for things like chatting, but >> >>> you wouldn't >> >>> need access to the page for that as you're unlikely to change the >> >>> component tree. >> >>> >> >>> The alternative to long polling is, of course, regular polling. Queue >> >>> the events >> >>> and process them when a request is processed. Then you can access the >> >>> page, >> >>> update the component tree and rerender the relevant parts. >> >>> Maintaining the queue >> >>> is a bit tricky, as one has to make sure that it doesn't grow too >> >>> large and it must be >> >>> disposed of properly. >> >>> >> >>> We've used this method to implement a single-page-application that >> updates >> >>> exclusively with ajax. It's not in the facebook/google/... range, but >> >>> it works well >> >>> enough for our purposes. >> >>> >> >>> cheers, Frank >> >>> >> >>> > --------------------------------------------------------------------- >> >>> > To unsubscribe, e-mail: [email protected] >> >>> > For additional commands, e-mail: [email protected] >> >>> > >> >>> > >> >>> >> >>> >> >>> >> >>> -- >> >>> Hippo >> >>> Europe • Amsterdam Oosteinde 11 • 1017 WT Amsterdam • +31 (0)20 >> 522 >> >>> 4466 >> >>> USA • San Francisco 185 H Street Suite B • Petaluma CA 94952-5100 >> >>> • +1 (707) 773 4646 >> >>> Canada • Montréal 5369 Boulevard St-Laurent #430 • Montréal QC >> >>> H2T 1S5 • +1 (514) 316 8966 >> >>> www.onehippo.com • www.onehippo.org • [email protected] >> >>> >> >>> --------------------------------------------------------------------- >> >>> To unsubscribe, e-mail: [email protected] >> >>> For additional commands, e-mail: [email protected] >> >>> >> >>> >> >> >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
