Filed https://issues.apache.org/jira/browse/WICKET-3165
Thanks Igor John- On Fri, Nov 12, 2010 at 11:47 AM, Igor Vaynberg <[email protected]> wrote: > not a bad idea. we already have a concept of "channels", but right now > they can only queue or drop requests. with some work it should be > possible to add an "aggregate" mode and process multiple callbacks > within the same request. please file a jira issue. > > -igor > > On Fri, Nov 12, 2010 at 11:44 AM, John Armstrong <[email protected]> > wrote: >> 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] >> >> > > --------------------------------------------------------------------- > 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]
