Hope you're well!
I have a problem with the Psycopg module allowing to interact with the PostgreSQL database.
When I start my HTTP server (I use FastAPI and Uvicorn) normally, and I send a request to my server, I have this error:
error connecting in 'pool-1': Psycopg cannot use the 'ProactorEventLoop' to run in async mode. Please use a compatible event loop, for instance by setting 'asyncio.set_event_loop_policy(WindowsSelectorEventLoopPolicy())'
I have already done what the error solution suggests, that is, set the event loop policy to WindowsSelectorEventLoopPolicy, which I did.
import asyncio
from asyncio import WindowsSelectorEventLoopPolicy
asyncio.set_event_loop_policy(WindowsSelectorEventLoopPolicy())
I put this line in my main file (which is the central file of my app)
But still nothing, I still have the same error when I send a request to my server.
But what is strange is that when I start my server with the --reload option (which is used to reload the files automatically in case of modification but is not adapted for production, according to the documentation of Uvicorn/FastAPI), I have no error when I send my requests and everything goes correctly
Can you tell me what is the cause of the problem and how to solve it?
P.S: Here is how i start my HTTP from Windows Powershell
Here is how I start my HTTP server normally (which doesn't works)
uvicorn src.main:app --port 2314
Here is how I start my HTTP server with the --reload option (which works perfectly)
uvicorn src.main:app --port 2314 --reload
Uvicorn sets the WindowsSelectorEventLoopPolicy policy when using the reload option and Windows by default, otherwise it doesn't. That's why you are facing this mismatch behavior.
Changing another policy should have worked, maybe it's misplaced.
The below works:
import asyncio
import uvicorn
asyncio.set_event_loop_policy(asyncio.DefaultEventLoopPolicy())
async def app(scope, receive, send):
print(asyncio.get_event_loop_policy())
if __name__ == "__main__":
uvicorn.run("main:app", port=8010)
If we remove the line on which we set the policy, and we have uvloop installed (uvicorn automatically selects uvloop if installed), we can see that the uvloop policy is printed.
In case it's not misplaced, I recommend open a discussion on uvicorn.
Disclaimer: I'm a maintainer of Uvicorn.
Thank you! After having made several tests and having read again the documentation of uvicorn.
Everything was a little bit my fault
I launched the uvicorn HTTP server (without the --reload option) directly from the command line from a terminal (in my case Powershell), I got the error.
error connecting in 'pool-1': Psycopg cannot use the 'ProactorEventLoop' to run in async mode. Please use a compatible event loop, for instance by setting 'asyncio.set_event_loop_policy(WindowsSelectorEventLoopPolicy())'
Because this way of doing things didn't read the import I had done in my main.py file, but simply started the server without caring about anything, hence the error asking me to set the event loop policy to WindowsSelectorEventLoopPolicy (which I had done), simply because the import line defining my event loop policy was never reached.
So now instead of launching my uvicorn server directly in the terminal like this
uvicorn src.main:app --port 2314
I execute my python code like this
python -m src.main
and I had to modify my code in main.py like this
import asyncio
from asyncio import WindowsSelectorEventLoopPolicy
import uvicorn
from fastapi import FastAPI
...
asyncio.set_event_loop_policy(WindowsSelectorEventLoopPolicy())
app = FastAPI()
...
if __name__ == '__main__':
uvicorn.run('src.main:app', host="127.0.0.1", port=2314)
The reason why it was working without any problem in the terminal is by running my HTTP server with the --reload option like this
uvicorn src.main:app --port 2314 --reload
is that as #marcelo-trylesinski said, the --reload option automatically sets event loop to WindowsSelectorEventLoopPolicy. I wish this could be notified / mentioned in the documentation.
Thanks again to #marcelo-trylesinski for his help
Related
I'm running a FastAPI app in Python using uvicorn it is totally wrok, but when I upload the file in deta which is https://web.deta.sh/ I got message error
and this is my import
from typing import Union
import uvicorn
I work with last version of uvicron and try version 0.17.1 but nothing has changed
I appreciate your help
It looks like your local and server environment differs. What you can do is:
# Needed for running locally
if __name__ == "__main__":
import uvicorn
uvicorn.run(app, host="0.0.0.0", port=8000)
This will remove the need to import unicorn in Deta.
If this does not work for you, you can add unicorn to the requirements.txt
mustafa from deta here.
i recommend using Charlie V's suggestion in general as deta doesn't use uvicorn to run your code. also make sure to remove uvicorn from the top of your file
i usually skip adding uvicorn to my code altogether and use uvicorn main:app ...
now to the other problem, it seems like your code and micro are out of sync. to fix that, remove the deps from your requirements.txt file, run deta deploy, then add them back and run deta deploy again. this should fix the issue.
if you still have any issue, please create an issue on our github discussions page.
I'm attempting to debug a Flask/Python app running on Google Appengine flexible environment.
However, I see a warning message within the Stackdriver Debug interface in Google Console, and am unable to set any breakpoints.
The warning reads:
Stackdriver Debugger is not set up for the python runtime on GAE Flex
Screenshot of warning
Any thoughts on what I'm doing wrong?
I've:
Enabled the Stackdriver Debugger API (as mentioned here)
Imported and initialised the Debugger (following the instructions here)
Included google-python-cloud-debugger in requirements.txt
main.py (the app entry point defined in app.yaml)
from werkzeug.serving import run_simple
from werkzeug.wsgi import DispatcherMiddleware
from wsgi import api, frontend, manage
try:
import googleclouddebugger
googleclouddebugger.AttachDebugger()
except ImportError:
pass
app = DispatcherMiddleware(frontend.create_app(), {
'/api': api.create_app(),
'/manage': manage.create_app()
})
if __name__ == '__main__':
run_simple('0.0.0.0', 5000, app, use_reloader=True, use_debugger=True)
app.yaml
runtime: python
env: flex
entrypoint: gunicorn -b :$PORT main:app
runtime_config:
python_version: 2
manual_scaling:
instances: 1
resources:
cpu: 1
memory_gb: 0.5
disk_size_gb: 10
env_variables:
SQLALCHEMY_DATABASE_URI: "postgresql+psycopg2://myusername:mypassword!#/instancename?host=/cloudsql/instancename"
beta_settings:
cloud_sql_instances: "instancename"
Update 1
After a comment and noticing a urllib import error, I wondered if the wsgi nature of my application was causing issues. I went back to the documentation, saw a note about Django framework doing something similar and changed the following:
googleclouddebugger.AttachDebugger()
to
googleclouddebugger.enable()
This got rid of the urllib import error, but hasn't resolved the overall issue.
I don't see anything wrong with this configuration, but here are some suggestions:
Once you open the GCP Console Debug page, please make sure you selected the correct version of the app from the top dropdown menu before starting the debugging session. It may be pointing to an old app version that is not debuggable, or the page and the dropdown might need a refresh to display the latest version.
Similarly, please check if your Stackdriver stderr logs contains a line that like this:
2017-12-24 15:14:14.000 PST I1224 23:14:14.600462 12 gcp_hub_client.py:335] Debuggee registered successfully, ID: gcp:1025611681465:7144dac417e43025
This means the debugger is actually setup/working properly, and most likely indicates that the UI is requires a refresh or selecting the right app version from the dropdown.
Make sure you have the google-python-cloud-debugger in the requirements.txt file.
Consider adding a simple print statement in the try/except block for the debugger, as folllows:
...
except ImportError as e:
print 'Failed to import Google Cloud Debugger: %s' % str(e)
pass
Then, check the stderr logs on Stackdriver Logging to see if this printed any exceptions.
I don't know about werkzeug, but you might want to try disabling the default debugger there by passing use_debugger=False, just to avoid possible conflicts.
Try deploying a simpler flask app (e.g., start with the hello world for Flex from here but modify it to use python_version: 2) and see if the debugger works for you there.
I was running flask in a public_ip server(with some users)
run command is
(host='0.0.0.0', port=80, debug=True)
but flask server blocking somewhere one hour ago (the log show last request is one hour before)
so how can I debug on it?(figure out it's blocking on which python line?)
I have tried
gdb python3.4-dbg pid,but my flask app can't run by python3.4-dbg,for
from PIL import _imaging as core
ImportError: cannot import name '_imaging'
I believe the command is:
gdb -p pid
to attach to a running process.
oh,I find a way
after install python-dbg
use gdb python pid to attach flask
and use py-bt py-list py-locals to check the blocking stack
I found this 0 dependency python websocket server from SO: https://gist.github.com/jkp/3136208
I am using gunicorn for my flask app and I wanted to run this websocket server using gunicorn also. In the last few lines of the code it runs the server with:
if __name__ == "__main__":
server = SocketServer.TCPServer(
("localhost", 9999), WebSocketsHandler)
server.serve_forever()
I cannot figure out how to get this websocketserver.py running in gunicorn. This is because one would think you would want gunicorn to run server_forever() as well as the SocketServer.TCPServer(....
Is this possible?
GUnicorn expects a WSGI application (PEP 333) not just a function. Your app has to accept an environ variable and a start_response callback and return an iterator of data (roughly speaking). All the machinery encapsuled by SocketServer.StreamRequestHandler is on gunicorn side. I imagine this is a lot of work to modify this gist to become a WSGI application (But that'll be fun!).
OR, maybe this library will get the job done for you: https://github.com/CMGS/gunicorn-websocket
If you use Flask-Sockets extension, you have a websocket implementation for gunicorn directly in the extension which make it possible to start with the following command line :
gunicorn -k flask_sockets.worker app:app
Though I don't know if that's what you want to do.
I'm having a weird issue testing my flask app.
I reduced it to the following, let this be 'test.py':
if __name__ == '__main__':
from flask import Flask
app = Flask(__name__)
#app.route('/hello')
def hello():
return 'hello\n'
app.run(debug = True)
So I simply run this as:
python test.py
* Running on http://127.0.0.1:5000/
* Restarting with reloader
Now on another terminal I can do this:
>> curl http://localhost:5000/hello
hello
However, what does not work, is this:
>> curl http://192.168.178.23:5000/hello
curl: (7) couldn't connect to host
Where ifconfig en1 gives:
[...] inet 192.168.178.23 [...]
Originally I'd like to test my actual app from another machine within the local network - that's how I came across this issue.
I also tried with my browser, wget and other "clients".
If I replace all the Flask/Werkzeug stuff with the python builtin BaseHTTPServer & Handler, things are fine - which lets me conclude that there's some weird issue going on with flask or werkzeug underneath, rather than e.g. with my network configuration.
I'm not too familiar with all low-level io, so don't really know where to start looking the for the source of the problem.
Apologies in advance, if I'm missing something stupid here...
By default, Flask listens only on your loopback interface, as exposing the debug interface (which allows execution of arbitrary Python code) to other machines is a serious security risk. To override this, try:
app.run(host='0.0.0.0', debug=True)
However, make sure your system is appropriately shielded from untrusted machines.