Why is PyMongo 3 giving ServerSelectionTimeoutError?

Question

I'm using:

• Python 3.4.2
• PyMongo 3.0.2
• mongolab running mongod 2.6.9
• uWSGI 2.0.10
• CherryPy 3.7.0
• nginx 1.6.2

uWSGI start params:

--socket 127.0.0.1:8081 --daemonize --enable-threads --threads 2 --processes 2

I setup my MongoClient ONE time:

self.mongo_client = MongoClient('mongodb://user:[email protected]:port/mydb')
self.db = self.mongo_client['mydb']

I try and save a JSON dict to MongoDB:

result = self.db.jobs.insert_one(job_dict)

It works via a unit test that executes the same code path to mongodb. However when I execute via CherryPy and uWSGI using an HTTP POST, I get this:

pymongo.errors.ServerSelectionTimeoutError: No servers found yet

Why am I seeing this behavior when run via CherryPy and uWSGI? Is this perhaps the new thread model in PyMongo 3?

Update:

If I run without uWSGI and nginx by using the CherryPy built-in server, the insert_one() works.

Update 1/25 4:53pm EST:

After adding some debug in PyMongo, it appears that topology._update_servers() knows that the server_type = 2 for server 'myserver-a.mongolab.com'. However server_description.known_servers() has the server_type = 0 for server 'myserver.mongolab.com'

This leads to the following stack trace:

result = self.db.jobs.insert_one(job_dict)
File "/usr/local/lib/python3.4/site-packages/pymongo/collection.py", line 466, in insert_one
with self._socket_for_writes() as sock_info:
File "/usr/local/lib/python3.4/contextlib.py", line 59, in __enter__
return next(self.gen)
File "/usr/local/lib/python3.4/site-packages/pymongo/mongo_client.py", line 663, in _get_socket
server = self._get_topology().select_server(selector)
File "/usr/local/lib/python3.4/site-packages/pymongo/topology.py", line 121, in select_server
address))
File "/usr/local/lib/python3.4/site-packages/pymongo/topology.py", line 97, in select_servers
self._error_message(selector))
pymongo.errors.ServerSelectionTimeoutError: No servers found yet

Answer 1

We're investigating this problem, tracked in PYTHON-961. You may be able to work around the issue by passing connect=False when creating instances of MongoClient. That defers background connection until the first database operation is attempted, avoiding what I suspect is a race condition between spin up of MongoClient's monitor thread and multiprocess forking.