Hi, we have observed a problem in one of our comet actors when it sends messages to itself: this ! foo
It looks like those messages are processed immediately and all the results returned to the browser in one lump. However, if I use Schedule to send a message to the actor, the results of processing each message get pushed to the browser as each message is processed.
Is calling ! on itself a bad thing? Am I barking up the wrong tree here? Perhaps I have another problem?
On Tue, Oct 23, 2012 at 7:32 AM, Channing Walton <channingwal...@mac.com>wrote:
> Hi,
> we have observed a problem in one of our comet actors when it sends
> messages to itself: this ! foo
> It looks like those messages are processed immediately and all the results
> returned to the browser in one lump. However, if I use Schedule to send a
> message to the actor, the results of processing each message get pushed to
> the browser as each message is processed.
> Is calling ! on itself a bad thing?
No.
> Am I barking up the wrong tree here? Perhaps I have another problem?
> It looks like those messages are processed immediately and all the results
> returned to the browser in one lump. However, if I use Schedule to send a
> message to the actor, the results of processing each message get pushed to
> the browser as each message is processed.
A few months ago I was doing some experiments to see how many comet
messages could Lift handle, and maybe you are seeing the same thing I
saw during those tests:
Most of the time, when I use comet, I just get one JavaScript command
per http response from the comet long pooling (when using something
like partialUpdate(SetHtml(...))
But if you go ahead and have something like a loop, with no pause in
between, and you send 300 messages to your comet actor, Lift will
group some of them into one http response, so, instead of getting 300
individual http responses, which would be slow, you may get 100 or
less (I can;t remember the real numbers), and each response will have
a group of JavaScript commands that modify the DOM.
In 2.4 we had a bug where you would get a stackoverflow with a very
high number of messages, that was was fixed in 2.5-M1
>> It looks like those messages are processed immediately and all the results
>> returned to the browser in one lump. However, if I use Schedule to send a
>> message to the actor, the results of processing each message get pushed to
>> the browser as each message is processed.
> A few months ago I was doing some experiments to see how many comet
> messages could Lift handle, and maybe you are seeing the same thing I
> saw during those tests:
> Most of the time, when I use comet, I just get one JavaScript command
> per http response from the comet long pooling (when using something
> like partialUpdate(SetHtml(...))
> But if you go ahead and have something like a loop, with no pause in
> between, and you send 300 messages to your comet actor, Lift will
> group some of them into one http response, so, instead of getting 300
> individual http responses, which would be slow, you may get 100 or
> less (I can;t remember the real numbers), and each response will have
> a group of JavaScript commands that modify the DOM.
> In 2.4 we had a bug where you would get a stackoverflow with a very
> high number of messages, that was was fixed in 2.5-M1
> Is this grouping what you are seeing?
> Thanks
> Diego
>> Is calling ! on itself a bad thing?
>> Am I barking up the wrong tree here? Perhaps I have another problem?
On Tue, Oct 23, 2012 at 11:05 PM, Channing Walton <
channing.wal...@googlemail.com> wrote:
> That sounds very plausible, I'll do some more experiments today to confirm.
There is a 50 ms (or something like 50 ms) timeout period between when the
long poll starts its clean-up and preparation to send the response to the
client and when it actually does. This is to avoid a spin situation where
there are lots of single responses that cause lots of individual http
request/responses. Perhaps you are batching up a ton of responses this way.
> On 24 Oct 2012, at 04:54, Diego Medina <di...@fmpwizard.com> wrote:
> >> It looks like those messages are processed immediately and all the
> results
> >> returned to the browser in one lump. However, if I use Schedule to send
> a
> >> message to the actor, the results of processing each message get pushed
> to
> >> the browser as each message is processed.
> > A few months ago I was doing some experiments to see how many comet
> > messages could Lift handle, and maybe you are seeing the same thing I
> > saw during those tests:
> > Most of the time, when I use comet, I just get one JavaScript command
> > per http response from the comet long pooling (when using something
> > like partialUpdate(SetHtml(...))
> > But if you go ahead and have something like a loop, with no pause in
> > between, and you send 300 messages to your comet actor, Lift will
> > group some of them into one http response, so, instead of getting 300
> > individual http responses, which would be slow, you may get 100 or
> > less (I can;t remember the real numbers), and each response will have
> > a group of JavaScript commands that modify the DOM.
> > In 2.4 we had a bug where you would get a stackoverflow with a very
> > high number of messages, that was was fixed in 2.5-M1
> > Is this grouping what you are seeing?
> > Thanks
> > Diego
> >> Is calling ! on itself a bad thing?
> >> Am I barking up the wrong tree here? Perhaps I have another problem?
On 24 Oct 2012, at 15:58, David Pollak <feeder.of.the.be...@gmail.com> wrote:
> On Tue, Oct 23, 2012 at 11:05 PM, Channing Walton <channing.wal...@googlemail.com> wrote:
> That sounds very plausible, I'll do some more experiments today to confirm.
> There is a 50 ms (or something like 50 ms) timeout period between when the long poll starts its clean-up and preparation to send the response to the client and when it actually does. This is to avoid a spin situation where there are lots of single responses that cause lots of individual http request/responses. Perhaps you are batching up a ton of responses this way.
Yes I think that was it - up to 100 responses queued up. We'll do something different :)
