Thanks for explanation guys!
I wasn't aware of the clock.
A single poll every 140s sounds perfectly reasonable to me.
I'm not aware of any better alternatives for long polling, yet
fortunately I don't desperately need one :)
Now I'm no longer concerned about Comet performance in my planned
Liftwe
On Wed, Apr 22, 2009 at 12:53 AM, Alexander Kellett wrote:
>
> are you sure this isn't the gc poll?
It's not the GC ping
> i agree 10 seconds is too short
> (thats a lot of traffic...)
10 seconds, as Marius pointed out, is the periodicity of the app because the
clock is updating every 10 sec
Hold on guys ... are you talking about the online demo application
http://demo.liftweb.net/ ? ... If so, note that there is also a clock
Comet Actor that every 10 seconds is updating the time in the browser.
It is the application intent not the comet implementation. Note that
by default the COMET
are you sure this isn't the gc poll? i agree 10 seconds is too short
(thats a lot of traffic...), but its a very quick operation, its not
an actual poll on the page afaiu
On Wed, Apr 22, 2009 at 8:54 AM, przemek.pokrywka
wrote:
>
> It is 10 sec actually at Comet chat example.
> Not very good for
It is 10 sec actually at Comet chat example.
Not very good for high-traffic public portals.
Przemek
On Apr 21, 7:21 pm, "marius d." wrote:
> But what is the problem with long pooling if a request is done every x
> minutes (if server does not have any message for this client)?
--~--~-~-
Comet is also known as long polling especially when browsers are
involved. That's because:
1. When timeout occurs ... after x seconds/minutes client needs to re-
establish connection
2. Client reconnects after response is provided by server
But what is the problem with long pooling if a request