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]
