Server sent events with Flask/Redis: how can more than one client view a stream?

Question

I have multiple clients trying to connect to a server sent events stream at /stream. This works with a single client, but attempting to connect any more clients results in the new client becoming indefinitely blocked waiting for data. If I send more data, it only goes to the first client, and no others.

Here is a small snippet that illustrates my problem:

import flask
import time

app = flask.Flask(__name__)

def event_stream():
    for i in xrange(9999):
        yield "data: %d\n\n" % i
        time.sleep(1)

@app.route("/stream", methods=[ "GET" ])
def stream():
    return flask.Response(
        event_stream(),
        mimetype="text/event-stream"
    )

I then run this with gunicorn --worker-class=gevent -w 4 -t 99999 app:app. It works for a single client, but any others get blocked when issuing GET /stream.

What is the cause of the block, and how should I fix it?

I debugged a little more and got some strange results. If I do this procedure, then this happens:

Start client 1 (only client 1 receiving data)
Start client 2 (only client 1 receiving data)
Start client 3 (only client 1 receiving data)
Start client 4 (only client 1 receiving data)
Restart client 1 (all 4 clients suddenly start receiving data at the same time)

http://stackoverflow.com/questions/13386681/streaming-data-with-python-and-flask — farzad, Jun 24 '13 at 06:31

score 3 · Accepted Answer · answered Jun 24 '13 at 08:21

3

It turns out that this is something to do with the Chromium web browser, where I was testing. It holds back on making the request until the first one completes, for some reason. Using curl, or an incognito browser session allowed multiple sessions to run at the same time. This means that my problem doesn't really exist in reality, it just appears that way because of the way that Chromium handles simultaneous requests to the same resource.

I'm not sure quite why Chromium behaves this way, it seems weird. Either way, this isn't a real problem, only a perceived one by my browser.

answered Jun 24 '13 at 08:21

Chris Down

1,590
1
14
25

I get similar results in Firefox on OSX. If I make the same reuest from a second tab, it waits until the first hangs (after about 30s) and then starts. Starting an in-private window allows two sessions to run simultaneously. – Spaceghost Jul 19 '13 at 02:15
This also affects Chrome 35 and Opera 22, but not Firefox 29. All on Windows. – rhyek Jun 11 '14 at 14:22
Observing the same problem, why do all these browsers do this? I thought that my server code has a problem – Logan Yang Jul 27 '19 at 18:53

score 2 · Answer 2 · answered Jul 19 '13 at 02:55

2

I was getting similar results in Firefox (as I noted in the comments) then I switched to using WSGIServer in the main block instead of gunicorn and everything works, the timeout is gone (because WSGIServer doesn't timeout its workers but gunicorn does) so I thought this made it worth adding as an answer.

Add this:

if __name__ == '__main__':
http_server = WSGIServer(('127.0.0.1', 8001), app)
http_server.serve_forever()

Then just do

python app.py

[I would not have had a timeout after 30s if I had used Chris' command line and set timeout to 99999 but there would have been much later]

answered Jul 19 '13 at 02:55

Spaceghost

6,835
3
28
42

This wasn't the problem in my case, but I agree that it might come up in other cases. Thanks! – Chris Down Jul 19 '13 at 08:14
Other than curl, did you see this work with anything other than Chromium? – Spaceghost Jul 19 '13 at 13:38
No, I didn't. I guess this should be easy enough to reproduce for anyone that wants to investigate further :-) – Chris Down Jul 19 '13 at 13:58

Server sent events with Flask/Redis: how can more than one client view a stream?

2 Answers2