Forums

I would like to make my app asynchronous, and for that I was thinking of using either Gevent or Tornado to do so. But was unable to find any clear information on how to do this.

I tried editing my WSGI config file (no, I didn't know what I was doing) and changed this line:

from flask_app import app as application

...to this:

from gevent.wsgi import WSGIServer
from flask_app import app
application = WSGIServer(("", 5000), app)

As I anticipated, it did not work. I am guessing that it's because I specified a port number. What is the correct way to do this?

Hmm. The problem with asynchronous apps is that they don't work very well with WSGI, which is the protocol we use to communicate between the web server and your web app. I don't think there's any way to get that working in PythonAnywhere right now, unfortunately.

Okay, thanks anyways.

Should I conclude that it is not possible to use Gevent possibilities on Pythonanywhere?

It is not possible for webapps at the moment :(

(but you can use it in the console etc)

OK, thanks for the explanation (webapp/console distinction). I have one more question : If I want to use Pusher as an external service, can I install the pusher library ?

Thank you.

yup- see here

OK, thank you.

I wish to use the pusher service but I don't want to use their main (default) US API server cluster but the one in Southeast Asia (ap-southeast-1). The API endpoint for this cluster is api-ap1.pusher.com and is not whitelisted on pythonanywhere.

Hence, my webapp gives me the familiar

ProxyError("Cannot connect to proxy.", error("Tunnel connection failed: 403 Forbidden",))

when connecting to their service: (host='api-ap1.pusher.com', port=443)

The main, default endpoint api.pusher.com is already whitelisted, so could you please add the other ones too -- namely:
api-ap1.pusher.com
api-eu.pusher.com

You can find their cluster related documentation here and their python (server) library here.

OK -- that's whitelisted.

Thank you very much!

My interest is similar. I have a plain bottle app:

wsgi = bottle.Bottle()

which then gets wrapped in a gevent (gevent.pywsgi) WSGIServer:

from gevent.pywsgi import WSGIServer
application = WSGIServer(("", 80), wsgi, handler_class = WebSocketHandler)

Testing from the console, if I specify port 80, I get a "permission denied" (not too surprising). If I specify an alternate port, like 8080, I get "Address already in use" -- I would like to serve this on my normal port 80, actually, preferably, but, failing that, I'd like to see something work. My code works fine served on my own server. The:

application.serve_forever()

does just that - it serves forever. The code contains normal bottle WSGI handler functions as well as handlers for web sockets. The pattern is taken basically from https://bottlepy.org/docs/dev/async.html (see bottom of page example). I would suppose that this pattern is not very uncommon (or it's not going to be before long)... is there any attention given to servicing the pattern out-of-the-box sometime in the near future? (i.e., using the standard (altered) PythonAnywhere "config" wsgi.py code?)

Thanks!

See http://help.pythonanywhere.com/pages/Flask504Error/ about app.run the page is specific to Flask, but the general lessons apply for all of the equivalents on other frameworks.

Thank you much for the reference to that post. I'm aware that PythonAnywhere takes responsibility for running the wsgi server, assuming that the 'application' variable set in the wsgi settings python file conforms to the python WSGI interface for such purposes. But, in the OPs post, and mine, we're referring to a WSGI+socket server... a bit of a different beast. Even when I trick the application to serving as a callable object, things don't work as expected. I think that this has to do with the kind of access to port 80 (or alternate ports) that users are directly granted. There's a chance that if I tried a few more ports, I'd find one open, and be able to run my server from the console, but it's not a good "real" solution.

No, that's not going to work on PythonAnywhere. There is no way for you to reach a random port on a console server from outside of PythonAnywhere, so even if you manage to stand up a "server", there's no way to talk to it.

Right, I figured as much. So shall I conclude that the situation is basically the same as it was in 2014 and 2016, with those posters inquiries, and there's nothing really for those of us who want to use python gevent's WSGIServer?

Yes, that is essentially correct.