CometActors sending messages to itself

[Channing Walton]

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?

Channing

[David Pollak]

On Tue, Oct 23, 2012 at 7:32 AM, Channing Walton <channin...@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?

No idea. Can you put together a sample app?

 

Channing

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code
 
 
 

--

Telegram, Simply Beautiful CMS https://telegr.am

Lift, the simply functional web framework http://liftweb.net

Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im

[Diego Medina]

> 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?
>
> Channing
>

> --
> --
> Lift, the simply functional web framework: http://liftweb.net
> Code: http://github.com/lift
> Discussion: http://groups.google.com/group/liftweb
> Stuck? Help us help you:
> https://www.assembla.com/wiki/show/liftweb/Posting_example_code
>
>
>



--

Diego Medina
Lift/Scala Developer
di...@fmpwizard.com
http://www.fmpwizard.com

[Channing Walton]

That sounds very plausible, I'll do some more experiments today to confirm.

Thanks,

Channing

Sent from my iPhone

[David Pollak]

On Tue, Oct 23, 2012 at 11:05 PM, Channing Walton <channin...@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.

--

Telegram, Simply Beautiful CMS https://telegr.am

Lift, the simply functional web framework http://liftweb.net

[Channing Walton]

On 24 Oct 2012, at 15:58, David Pollak <feeder.of...@gmail.com> wrote:

On Tue, Oct 23, 2012 at 11:05 PM, Channing Walton <channin...@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 :)

Thanks for all the help.

Channing