Repeated ws_receive in multichat example with a external test client

[jusic]

Hi,

(As there is no separate issue tracker for channels-examples, I post here instead.)

Thanks for the channels package and examples! I just started playing around with to test WebSockets with Django.

I'm running a slightly modified multichat example and a Autobahn/Twisted-based test client for sending data directly to the WebSocket. I'm getting repetitive chat.consumers.ws_receive calls for a single message.

https://github.com/jusic/channels-examples/

To reproduce, on a Ubuntu 14.04 LTS, redis-server 2.8.4:

$ git clone https://github.com/jusic/channels-examples.git
$ cd channels-examples/multichat/
$ virtualenv -p python3 venv
$ . venv/bin/activate
$ pip install -r requirements.txt
$ redis-cli
127.0.0.1:6379> flushall             # erase all keys from Redis
<Ctrl-D>
$ python manage.py runserver

Open the browser, create one user and one room.

On another terminal, run:

python testclient.py 

In the multichat example, I added a time.sleep(1) to chat.consumers.ws_connect to get the erratic behaviour show up more reliably. This imitates some processing load on the server during the ws_connect.

On my setup, for a two sent messages (join and send), chat.consumers.ws_receive gets called numerous times. I think it should only be called twice. Server console log starts showing some asgiref.base_layer.ChannelFull exceptions after a while. redis-cli shows 100+ asgi keys within few second.:

$ redis-cli
127.0.0.1:6379> keys *
[...snip...]
140) "asgi:4cb836956a1546679152c3b7da2671e8"
141) "asgi:ba593ca4d7214bcf8294aad038cf5090"
142) "asgi:e4690e8946e948aabf3805f7505e7742"
143) "asgi:33ed45b9332644f3b76d271b40584b64"
144) "asgi:a433c6a8e3fd40deb594b049fa4f6a02"
127.0.0.1:6379> 

Manually, after a redis-cli flushall and using the browser example to send a message, there are only < 20 keys.

To verify that the client is not issuing more than two/one calls per every 5 seconds, there is also a testserver.py that can be run instead of Django runserver .

To me, this behaviour would suggest some problem in channels, or that I'm doing something wrong.

[jusic]

I used 0.13.0 release, but it looks like the latest master (363b5a0) fixes this, related to #144 and #141.

[jusic]

The test client might be of some interest for load testing #28.

[andrewgodwin]

Yes, the message duplication issue is fixed in the latest master, there was a typo in enforce_ordering that got fixed with the rest of that patch. I'll get a release out right now.

[jusic]

Ok, thanks!

[andrewgodwin]

Released in 0.13.1.