Sanic ecosystem - versioning

Is it possible to run sanic via unicorn while using sanic_cors plugin. If it is as there were a lot of issues with version miss matches can You recommend versions of software to use?

@ashleysommer?

@harpo_marx Do you mean gunicorn or uvicorn?

@harpo_marx
Can you give me some more details please?
There was some problems in January around the release of 19.12 where it took some time for Sanic-Plugins-Framework and subsequently Sanic-CORS to catch up with the changes. Is that what you are referring to? I don’t believe these problems affected gunicorn or uvicorn compatibility.

Yeah sorry for the late reply I was talking about uvicorn on python 3.7 at that moment. Currently it is working with few caveats.
Pip install is working I can start project and serve the app, tested on python 3.7 and 3.8 currently I don’t see any issues in starting the app.

There are issues in stability especially while serving the app with a lot of concurrent connections but I will open a new thread for that purpose.

Thanks. I would be happy to hear what you are experiencing. I am currently running that in production with a high volume of traffic and do not see any stability issues. When you post, the more details you can provide the better :beers:

Hi, well in short until I prepare code snippets from our services I can give a small example.
Issues that we had were daunting and weird. Simple description would be the following. While the server was under heavy load back-end(Sanic) would stop responding. And not in a way that I could understand.

Our infrastructure had a following topology:
Client ---------> NginX ------reverse_proxy------> back-end 1
… … … … … … … … … … . . … … … … |—> back-end 2

On NginX side there where 2 routes connecting back-end to clients (one was machine to machine communication.)

After stress testing the machine back-ends would become unresponsive, but even after stopping the stress test and releasing all connections we could not access the back-end until it was restarted.

Heavy load just showed us the issue faster. In normal operation the locking would still occurred.
At first we thought it could be some sort of memory leak (It was not).
Couple of culprits were found one of them was aiotask_context lib, we removed it and the locking rate diminished.
Currently we are treating Uvicorn as prime suspect.

Amazingly enough if we remove Uvicorn and run sanic from supervisor directly on unix://some_fd,
with NginX we do not have any issue. The server behaves as it should(Sure it is not optimal) but no locks after 2 weeks of testing.

That is certainly of interest, and I will bring the maintainer of uvicorn into the conversation. @tomchristie