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]
