Waiting for client events leads to timeouts

[jorgschulze73]

Hi miguel, been using Flask-SocketIO for a while but stumbled upon some issues recently; hopefully you'll be able to provide some insights on how to resolve them.

This is my current setup:

• Flask-SocketIO running both SocketIO and REST endpoints
• Requests to the REST api are "forwarded" to SocketIO clients
• Deployed using uWSGI+gevent behind nginx on 1 worker

The problem: I have noticed that requests are consistently timing out when using call or emit + waiting for callback; in particular way, I'm not seeing the concurrency behaviour that I would expect from using gevent.

Here is a simple snippet:

from flask_socketio import Namespace, call

class MyApiNamespace(Namespace):
    name = '/my_api'

    # connect / disconnect handlers

    @staticmethod
    def handle(request):
        name = '<request_name>'
        body = '<request_body>'
        to = '<random_client_sid>'

        return call(name, body, namespace=MyApiNamespace.name, to=to, timeout=10)

@rest_api.route('/my_api', methods=['POST'])
def my_api():
    return MyApiNamespace.handle(request.data)

What I would expect to happen: The call invocation should take care of yielding the current greenlet, potentially letting another one run. Whenever the socketio will invoke its callback, the request will complete and client would be returned data immediately.

What I'm seeing: The request never returns before the timeout is hit; moreover, the handling time for each one of these requests seem to creep up over time:

Apr 23 10:09:48 myapi uwsgi[31227]: [pid: 31230|app: 0|req: 795/813] <redacted> () {56 vars in 1197 bytes} [Tue Apr 23 10:09:38 2024] POST /my_api => generated 148 bytes in 10017 msecs (HTTP/1.1 200) 2 headers in 81 bytes (3 switches on core 93)
...
Apr 23 10:09:55 myapi uwsgi[31227]: [pid: 31230|app: 0|req: 825/942] <redacted> () {56 vars in 1197 bytes} [Tue Apr 23 10:09:31 2024] POST /my_api => generated 372 bytes in 24237 msecs (HTTP/1.1 200) 2 headers in 81 bytes (3 switches on core 32)

As a side note, I also have monkey patching applied at the very beginning of the entry point invoked by uWSGI.

I would appreciate your guidance in troubleshooting this issue, or attempting to work around possible limitations.

Thank you!