ServerSelectionTimeoutError: No servers found yet with pymongo 3.1 about flask-pymongo HOT 8 CLOSED

@dkiser Out of curiosity, what app server are you using? I am using uwsgi. I just spent like two hours with a bug that I think is the same. Mine never throws an exception but instead just hangs, and this is what I get in the logs.

announcing my loyalty to the Emperor...
/srv/venv/lib/python3.4/site-packages/pymongo/topology.py:74: UserWarning: MongoClient opened before fork. Create MongoClient with connect=False, or create client after forking. See PyMongo's documentation for details: http://api.mongodb.org/python/current/faq.html#using-pymongo-with-multiprocessing>
  "MongoClient opened before fork. Create MongoClient "
[pid: 15145|app: 0|req: 1/2]  1.2.3.4 () {46 vars in 753 bytes} [Sun Jan 24 01:54:21 2016] GET /stats => generated 39 bytes in 30023 msecs (HTTP/1.1 500) 2 headers in 90 bytes (1 switches on core 0)

There's a timeout at 30 seconds. I can connect just fine using exactly the same stack/virtualenv (minus the app server of course) using a Flask-Script shell (https://flask-script.readthedocs.org/en/latest/#shell).

My solution was a one line fix; just add lazy-apps = true to my uwsgi INI file. That makes the workers fork then load the application.

from flask-pymongo.

@dkiser I don't think detection of >1 cores/threads is enough to handle this; I think that the PyMongo crowd would have implemented that instead of adding warnings in the api documentation (https://api.mongodb.org/python/3.1/faq.html#multiprocessing). Seems to me like adding a configuration option for this would be a better way to go.

from flask-pymongo.

@hbldh sounds good to me.

from flask-pymongo.

@dkiser Tests didn't pass on Travis at first, but when I added MONGO_CONNECT=False to all test cases it did.

@ranman Might be that this setting is required for correct handling of PyMongo 3.1 on Travis CI?

from flask-pymongo.

any progress on this?

from flask-pymongo.

@hut8 its been almost 3 months, so that is about 10 tech years ;) I believe I was using the same setup with uwsgi, but it failed immediately for me. We ended up just downgrading to pymong 2.8 in our Docker containers in the meantime.

from flask-pymongo.

@hut8 @dkiser I have been using gunicorn and also CherryPy web server, both of them most often as reverse proxy web servers.
I am using my fork since I sent my pull request, #67, and have not encountered ant problems yet.

A new pull request, #71, has been created with the same intent as this one, so I would not say that this issue is dead ...

from flask-pymongo.

I'll merge #67 after some docs updates

On Sun, Jan 24, 2016 at 2:18 PM, Henrik Blidh [email protected]
wrote:

@hut8 https://github.com/hut8 @dkiser https://github.com/dkiser I
have been using gunicorn http://gunicorn.org/ and also CherryPy
http://www.cherrypy.org/ web server, both of them most often as reverse
proxy web servers.
I am using my fork since I sent my pull request, #67
#67, and have not
encountered ant problems yet.

A new pull request, #71 #71,
has been created with the same intent as this one, so I would not say that
this issue is dead ...

—
Reply to this email directly or view it on GitHub
#66 (comment)
.

from flask-pymongo.