2015-06-24 16 views
26

sto usando:Perché PyMongo 3 fornisce ServerSelectionTimeoutError?

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

uWSGI start param:

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

ho installato il mio MongoClient UNA volta:

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

ho cercare di salvare un dict JSON per MongoDB:

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

Funziona tramite una prova di unità che esegue lo stesso percorso di codice a MongoDB. Tuttavia quando eseguo via CherryPy e uWSGI utilizzando un HTTP POST, ottengo questo:

pymongo.errors.ServerSelectionTimeoutError: No servers found yet 

Perché vedo questo comportamento quando eseguito tramite CherryPy e uWSGI? È forse questo il nuovo modello di thread in PyMongo 3?

Aggiornamento:

Se corro senza uWSGI e nginx utilizzando i CherryPy server integrato, i insert_one() opere.

Aggiornamento 1/25 16:53 EST:

Dopo l'aggiunta di un po 'di debug in PyMongo, sembra che topology._update_servers() sa che il server_type = 2 per il server 'myserver-a.mongolab.com'. Tuttavia server_description.known_servers() ha la server_type = 0 per il server 'myserver.mongolab.com'

Questo porta alla seguente 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 
+0

Sto colpendo anche questo su una configurazione simile. Hai mai trovato una risposta? – Greg

+0

Ancora niente ... non sono tornati al debugging. – drfence

+1

Vuoi che inizi una taglia? Sareste disponibili a rispondere alle domande di follow-up? Sono completamente bloccato su questo me stesso. – Greg

risposta

25

Stiamo esaminando questo problema, monitorato in PYTHON-961. Potresti essere in grado di risolvere il problema passando connect = False durante la creazione di istanze di MongoClient. Ciò interrompe la connessione in background fino al tentativo della prima operazione di database, evitando ciò che sospetto sia una condizione di competizione tra lo spin up del thread del monitor di MongoClient e il biforcazione multiprocesso.

+2

Questa è forse una domanda stupida, ma come si fa esattamente? – SARose

+2

Questa soluzione ha esito negativo se utilizziamo l'autenticazione in mongodb.È possibile trovare un'altra soluzione per questo –

9

ho fissato per me stesso per il downgrade da pymongo 3,0-2,8. Non ho idea di cosa sta succedendo.

flask/bin/pip uninstall pymongo 
    flask/bin/pip install pymongo==2.8 
+0

Giusto, le versioni precedenti funzionavano anche per me. – drfence

+6

'pip installa pymongo == 2.8 --upgrade' – drgarcia1986

+0

Devo essere un bug, funziona anche per me. – realhu

-1

Questo è stato risolto in PyMongo con this pull_request.

+2

Ho appena aggiornato da pymongo '2.6.2' a' 3.2.2' e sto ricevendo questo errore: 'ServerSelectionTimeoutError: Nessun server trovato ancora '. Eseguendo MongoDB '3.2.5', Python' 2.7', Bottle '0.12.9' su Ubuntu' 16.04'. La correzione è in una versione diversa da '3.2.2'? – user1063287

+1

Questa non è una correzione, questo PR semplicemente _enables_ il _workaround_ menzionato nella risposta accettata: http://stackoverflow.com/a/31194981/1446048 – OJFord

0

Sono arrivato allo stesso problema e alla fine ho scoperto che l'IP del client è bloccato dal firewall del server mongo.

0

Ho incontrato anche questo.

Questo potrebbe essere dovuto a pymongo3 isn't fork safe.

Ho risolto il problema aggiungendo il parametro --lazy-apps a uwsgi, questo può evitare il problema "fork safe".

vedere uwsgi doc preforking-vs-lazy-apps-vs-lazy.

Avviso, non è sicuro che questi due abbiano una connessione positiva.

2

Ho avuto lo stesso problema con Pymongo 3.5 Si scopre la sostituzione di localhost con 127.0.0.1 o l'indirizzo IP corrispondente dell'istanza mongodb risolve il problema.