Long polling in the messaging example on CherryPy?

[Chris]

Hi Guys,

I have been exploring AmFast by playing with the examples. I have
made it through "Hello World" and am on to "Producer/Consumer." I am
new to python and the various web frameworks, so I apologize in
advance for a potentially silly question.

The code cp_server.py sets up a longPolling example like so:
# Long-poll channels do not return
# a response to the client until
# a message is available, or channel.max_interval
# is reached.
long_poll_channel = CherryPyChannel('longPoll', wait_interval=90)
channel_set.mapChannel(long_poll_channel)

But the documentation for HTTP suggests: wait_interval = -1 for long
polling. Is 90 the correct number?

I have tried both settings on my local machine and it looks like the
server is serving up the queued messages to my two clients once every
3 seconds, the same as with the polling example. I was expecting the
long polling connections to serve all of the open connections
immediately when new data comes in.

Am I thinking about this correctly? Is there a way to do what I am
imagining by modifying this example slightly? My assumption was with
long polling the chat client should have a latency in the sub-second
range.

-Chris.

[limscoder]

When the 'wait_interval' is set to 90, the server will return a
response to the client when a new message is available, or once 90
seconds has passed. When the 'wait_interval' is set to -1, the server
will return a response only when a new message is available.

-Dave

[Chris]

Thanks for the quick response.

I guess I was not expecting the server to respond on ~2 second
intervals with up to ~2 second latency, rather I was expecting it to
respond immediately (<100ms) to the polling connections which were
open. Is this the expected behavior or do I have something setup
improperly?

Here is the output of cp_server.py output with two longPoll
connections open:

::1 - - [26/Jan/2011:17:09:41] "POST /amf HTTP/1.1" 200 290 ""
"Shockwave Flash"
::1 - - [26/Jan/2011:17:09:41] "POST /amf HTTP/1.1" 200 290 ""
"Shockwave Flash"
::1 - - [26/Jan/2011:17:09:44] "POST /amf HTTP/1.1" 200 290 ""
"Shockwave Flash"
::1 - - [26/Jan/2011:17:09:44] "POST /amf HTTP/1.1" 200 290 ""
"Shockwave Flash"
::1 - - [26/Jan/2011:17:09:45] "POST /amf HTTP/1.1" 200 279 ""
"Shockwave Flash"
::1 - - [26/Jan/2011:17:09:47] "POST /amf HTTP/1.1" 200 600 ""
"Shockwave Flash"
::1 - - [26/Jan/2011:17:09:47] "POST /amf HTTP/1.1" 200 600 ""
"Shockwave Flash"
::1 - - [26/Jan/2011:17:09:50] "POST /amf HTTP/1.1" 200 290 ""
"Shockwave Flash"
::1 - - [26/Jan/2011:17:09:50] "POST /amf HTTP/1.1" 200 290 ""
"Shockwave Flash"
::1 - - [26/Jan/2011:17:09:53] "POST /amf HTTP/1.1" 200 290 ""
"Shockwave Flash"

-Chris.

[Dave Thompson]

That does seem to be an abnormal amount of latency. How are the messages being sent? By the server, or by 2nd client?

-Dave

--
You received this message because you are subscribed to the Google Groups "AmFast" group.
To post to this group, send email to amf...@googlegroups.com.
To unsubscribe from this group, send email to amfast+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/amfast?hl=en.

[Chris]

I am running the "producer/consumer"/messaging example here:

The server is:
amfast-read-only\examples\messaging\python

And the two clients are:
amfast-read-only\examples\messaging\flex\deploy\messaging.swf

I send messages from either client. The server receives them
immediately (and I see a post to the terminal,) and then once every
few seconds (it looks like a heart beat on the server?) the clients
get updated.

I pasted the wrong server log above (that one was to /amf which is the
polling channel.) The behavior from the longPoll channel is the same
though:

::1 - - [27/Jan/2011:10:31:13] "POST /longPoll HTTP/1.1" 200 290 ""
"Shockwave Flash"
::1 - - [27/Jan/2011:10:31:15] "POST /longPoll HTTP/1.1" 200 290 ""
"Shockwave Flash"
::1 - - [27/Jan/2011:10:31:16] "POST /longPoll HTTP/1.1" 200 290 ""
"Shockwave Flash"
::1 - - [27/Jan/2011:10:31:18] "POST /longPoll HTTP/1.1" 200 290 ""
"Shockwave Flash"
::1 - - [27/Jan/2011:10:31:19] "POST /longPoll HTTP/1.1" 200 290 ""
"Shockwave Flash"
::1 - - [27/Jan/2011:10:31:21] "POST /longPoll HTTP/1.1" 200 279 ""
"Shockwave Flash"
::1 - - [27/Jan/2011:10:31:21] "POST /longPoll HTTP/1.1" 200 607 ""
"Shockwave Flash"
::1 - - [27/Jan/2011:10:31:22] "POST /longPoll HTTP/1.1" 200 607 ""
"Shockwave Flash"
::1 - - [27/Jan/2011:10:31:24] "POST /longPoll HTTP/1.1" 200 279 ""
"Shockwave Flash"
::1 - - [27/Jan/2011:10:31:24] "POST /longPoll HTTP/1.1" 200 607 ""
"Shockwave Flash"
::1 - - [27/Jan/2011:10:31:25] "POST /longPoll HTTP/1.1" 200 607 ""
"Shockwave Flash"
::1 - - [27/Jan/2011:10:31:27] "POST /longPoll HTTP/1.1" 200 290 ""
"Shockwave Flash"
::1 - - [27/Jan/2011:10:31:28] "POST /longPoll HTTP/1.1" 200 279 ""
"Shockwave Flash"
::1 - - [27/Jan/2011:10:31:28] "POST /longPoll HTTP/1.1" 200 607 ""
"Shockwave Flash"

-Chris.

> > amfast+un...@googlegroups.com<amfast%2Bunsu...@googlegroups.com>
> > .

[limscoder]

Your example application is giving me consumer subscribe error.

Are you using the stock CherryPy example, or have you changed
anything?

[Chris Carlson]

Hi, sorry about that, for some reason that port has stopped working on webfaction.

This is the base example with no changes, I was just trying to make it easy to evaluate.

-Chris.

To unsubscribe from this group, send email to amfast+un...@googlegroups.com.

[Chris]

I managed to reset that process (required a kill -9,) so it should
work for a while anyway...

> > <amfast%2Bunsu...@googlegroups.com<amfast%252Bunsubscribe@googlegroups. com>

[limscoder]

Have you tried running the example locally? I would be interested to
see if the latency is the same.

[Chris Carlson]

I have been running the example locally and see the same latency with the long polling example.

With the console debug messages on, my interpretation of what is going on is 1) The server wakes up once every 2 seconds or so, then goes back to sleep. 2)  the producer sends the message to the server  3) the server immediately prints a message to the console which means it gets it right a way, but it does not send it to the registered consumers 4) The server goes back to sleep 5) The server wakes up with its normally scheduled heart beat and sends any queued messages to the consumer.

So the latency is coming from the heart beat of each of the consumer subscriptions to the server.  I somehow expected that the longPoll behavior would have been to send messages to all subscribed consumers when they arrived, not on the heart beat of the longPolling thread.

I am sure I am not getting this correct technically, but it is the best explanation I have come up with so far.

Has anyone else run the current example and seen a more immediate behavior?

I am running the local example on windows 7 with Python 2.6, compiled to x64 with VS Express 2008.

-Chris.

To unsubscribe from this group, send email to amfast+un...@googlegroups.com.