Develop Reference

Problem with running Socket IO through gunicorn on Fly.io

I am trying to host my flask website on fly.io. My website uses the flask_socketio library and needs a 2 ended connection with the client and server, so this is the gunicorn command I use in the Profile:
web: gunicorn -k geventwebsocket.gunicorn.workers.GeventWebSocketWorker -w 1 main:app
This causes the following error in my fly.io log
TypeError: Cannot convert greenlet.greenlet to gevent._gevent_c_greenlet_primitives.SwitchOutGreenletWithLoop
I have searched stack overflow and found this person having a practically identical problem using Hikaru. Unfortunatly no one gave him an answer and he solved the problem on his own by updating python and re-installing gunicorn.
I tried this, without any positive outcome.
Python: 3.10.9
gevent==22.10.2
gevent-websocket==0.10.1
greenlet==2.0.1
gunicorn==20.1.0

App Engine Flexible can't use datastore with websockets example

I tried adding the websockets example project to the datastore project and the websockets work but when a page queries the datastore or tries to put a new entity I get a 502 response. In the logs it shows a critical error on the service worker. If I remove the websocket code the datastore code works as intended. The only difference I can see is the entrypoints for the app samples slightly differ
the websocket sample uses
entrypoint: gunicorn -b :$PORT -k flask_sockets.worker main:app
while the datastore sample uses
entrypoint: gunicorn -b :$PORT main:app
websocket sample https://github.com/GoogleCloudPlatform/python-docs-samples/tree/master/appengine/flexible/websockets
datastore sample
https://github.com/GoogleCloudPlatform/python-docs-samples/tree/master/appengine/flexible/datastore

The problem appears to be that GRPC (the default transport mechanism of the Cloud Datastore client) is not compatible with gevent. Aside from using a different websockets framework, you can work around the issue by activating grpc's gevent compatibility patch, using the following code:
import grpc.experimental.gevent as grpc_gevent
grpc_gevent.init_gevent()

As a complement of Andrew's answer, you can extend the gunicorn worker class to run gRPC applications.
# gevent_grpc_worker.py
from gunicorn.workers.ggevent import GeventWorker
from grpc.experimental import gevent
class GeventGrpcWorker(GeventWorker):
def patch(self):
super(GeventGrpcWorker, self).patch()
gevent.init_gevent()
self.log.info('patched grpc')
# config.py for gunicorn
import multiprocessing
from gevent_grpc_worker import GeventGrpcWorker
# http://docs.gunicorn.org/en/stable/design.html#how-many-workers
workers = multiprocessing.cpu_count() * 2 + 1
worker_connections = 10000
# Use an asynchronous worker as most of the work is waiting for websites to load
worker_class = '.'.join([GeventGrpcWorker.__module__,
GeventGrpcWorker.__name__])
timeout = 30
Then start your managed application by:
gunicorn -c config.py app:app

As you said it seems there is a problem with the flask_socket.worker, I have test it and it does not work with the datastore client.
I have tried with the Flask-SocketIO framework using the eventlet worker and the datastore queries work fine.
entrypoint: gunicorn -b :$PORT --worker-class eventlet -w 1 main:app
Also you need to add the eventlet module in the requirements.txt file eventlet==0.24.1
The downside of this is that it breaks the compatibility with the websocket code so you need to rewrite this part. Keep in mind that code samples are just intended to show in a few lines how to use the Google Cloud products and copy-paste them without modifying the configuration undelied in the app.yaml is not a good idea.

Hosting Flask App on Centos with Apache

Very new to this.
I am trying to follow along with this tutorial.
The main difference to my setup is that I am not using a domain, but would rather just access the flask site (something for personal use only) through the ip address.
This step:
Test sample flask app: If you want, test yourself for typos. uwsgi --socket 0.0.0.0:5000 --protocol=http -w wsgi
... works and I can access the flask app at ipaddress:5000
My /etc/httpd/conf/httpd.conf ServerName is configured with the ipaddress rather than flaskdemo.com
Problematically though once I spin up the apache service with
sudo systemctl start httpd
... I get a 503 at ipaddress
Thanks in advance for any support.

Running aiohttp server using gunicorn

I am trying to run a aiohttp based server using Gunicorn.
Here is the command:
gunicorn aiohttpdemo_polls:app --bind 127.0.0.1:8080
It returns:
Failed to find application: 'aiohttpdemo_polls'
But when I am running it using python -m like below:
python -m aiohttpdemo_polls
It works fine. The code can be found from here which is a demo app in the aiohttp repo.
Also tried it like below:
gunicorn aiohttpdemo_polls.main:app --bind 127.0.0.1:8080
But its also not running the server. It returns
Failed to find application: 'aiohttpdemo_polls.main'
Any idea where to look further for fixing the issue?

aiohttp 3.1 supports coroutine as application factory, such as:
async def my_web_app():
app = web.Application()
app.router.add_get('/', index)
return app
Current implementation of aiohttpdemo_polls uses this approach. It can be started with
gunicorn aiohttpdemo_polls.main:init_app --bind localhost:8080 --worker-class aiohttp.GunicornWebWorker

The demo does not support gunicorn yet.
I filed an issue: https://github.com/aio-libs/aiohttp-demos/issues/10
Thanks for report.

"Empty reply from server" for Flask + uWSGI setup

I'm getting started with WSGI and until now, with a little help from some tutorials,I'm making some tests towards Flask with uWSGI in front of it, since that Flask is not a good option for Production environments (doesn't scale well and by default, it answers one request per time - http://flask.pocoo.org/docs/0.12/deploying/) and uWSGI gives flexibility and more reliability, spawning workers and processes. Am I wrong?
Most of the tutorials that I saw until, are pointing about setups with Nginx in front of WSGI, but is it really necessary? What I'm trying to do is just to give a scalable way to deliver requests to my Flask application, something with more performance and scalability.
So I have this basic setup:
hello.py
from flask import Flask
app = Flask(__name__)
#app.route("/")
def hello():
return "Hello World!"
if __name__ == "__main__":
app.run(host='0.0.0.0', port=8080)
wsgi.py
from hello import app
if __name__ == "__main__":
app.run()
Running uWSGI:
uwsgi --socket 0.0.0.0:8080 --plugin python --wsgi-file wsgi.py --callable app --master --processes 4 --threads 2 &
When I perform a curl against the loopback address, I receive an empty reply..
curl http://127.0.0.1:8080
invalid request block size: 21573 (max 4096)...skip
curl: (52) Empty reply from server
Forgive me, but I can't see what I'm missing. Does anyone here, more experienced with WSGI, could point where is the failure of this setup? Any help would me much appreciated.
Reference documents:
https://www.digitalocean.com/community/tutorials/how-to-serve-flask-applications-with-uwsgi-and-nginx-on-ubuntu-16-04
http://uwsgi-docs.readthedocs.io/en/latest/WSGIquickstart.html

Your option, socket should be used when you combine uwsgi with web server (nginx for example). Otherwise you should use http, so
uwsgi --http 0.0.0.0:8080 --plugin python --wsgi-file wsgi.py --callable app --master --processes 4 --threads 2
will work.
Production environments (doesn't scale well and by default, it answers
one request per time - http://flask.pocoo.org/docs/0.12/deploying/)
and uWSGI gives flexibility and more reliability, spawning workers and
processes. Am I wrong?
You are right.
Most of the tutorials that I saw until, are pointing about setups with
Nginx in front of WSGI, but is it really necessary? What I'm trying to
do is just to give a scalable way to deliver requests to my Flask
application, something with more performance and scalability.
Well, nginx is designed to be in front and having it is much better then only application server (uwsgi). Specialisation, that's the key. Let your application server focus on bussiness processing and python.