CODEWITHSUNDEEP
mongodbpymongo
user37203
user37203

Reputation: 706

Cursor id not valid at server even with no_cursor_timeout=True

Traceback (most recent call last):
  File "from_mongo.py", line 27, in <module>
    for sale in pm.events.find({"type":"sale", "date":{"$gt":now-(_60delta+_2delta)}}, no_cursor_timeout=True, batch_size=100):
  File "/usr/local/lib/python2.7/dist-packages/pymongo/cursor.py", line 968, in __next__
    if len(self.__data) or self._refresh():
  File "/usr/local/lib/python2.7/dist-packages/pymongo/cursor.py", line 922, in _refresh
self.__id))
  File "/usr/local/lib/python2.7/dist-packages/pymongo/cursor.py", line 838, in __send_message
codec_options=self.__codec_options)
  File "/usr/local/lib/python2.7/dist-packages/pymongo/helpers.py", line 110, in _unpack_response
cursor_id)
pymongo.errors.CursorNotFound: cursor id '1025112076089406867' not valid at server

I have also experimented with bigger or lower batch size, and no no_cursor_timeout at all. I have even managed to get this error on a very small collection (200 documents with id and title). It seems to happen when the database is not responsive (heavy inserts). The setup is a cluster of 3 shards of 3 replica sets (9 mongodb instances), mongodb 3.0.

Upvotes: 2

Views: 1234

Answers (2)

user37203
user37203

Reputation: 706

It just hit me that I thought I was using pymongo 3.0 which has a flag called no_cursor_timeout=True, when in fact I was using 2.8.

Upvotes: 0

A. Jesse Jiryu Davis
A. Jesse Jiryu Davis

Reputation: 24007

Based on the line numbers in your traceback, it looks like you're using PyMongo 3, which was released last week. Are you using multiple mongos servers in a sharded clusters? If so, the error is probably a symptom of a critical new bug in PyMongo 3:

https://jira.mongodb.org/browse/PYTHON-898

It will be fixed in PyMongo 3.0.1, which we'll release within a week.

Upvotes: 2

Related Questions