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