Description
Note: This bug is a regression from 2.0.x behavior in mongos. There are no issues with mongod.
mongos returns the wrong value in the startingFrom field of OP_REPLY. The problem appears to be that mongos sets startingFrom to the same value as numberReturned. This causes PyMongo to assert expecting startingFrom to be 0 on the initial batch:
>>> cur = c.test.test.find()
|
>>> cur.next()
|
startingFrom: 100
|
numberReturned: 100
|
Traceback (most recent call last):
|
File "<stdin>", line 1, in <module>
|
File "pymongo/cursor.py", line 747, in next
|
if len(self.__data) or self._refresh():
|
File "pymongo/cursor.py", line 698, in _refresh
|
self.__uuid_subtype))
|
File "pymongo/cursor.py", line 668, in __send_message
|
assert response["starting_from"] == self.__retrieved
|
The output should look like this (and does with mongod in 2.1.1):
>>> cur = c.test.test.find()
|
>>> cur.next()
|
startingFrom: 0
|
numberReturned: 101
|
{u'i': 0.0, u'_id': ObjectId('4fb1a26cb59381ba9dc941c8')}
|
The problem appears to be in src/mongo/s/cursors.cpp. At line 136 in ShardedClientCursor::sendNextBatch we have:
_totalSent += docCount;
|
Then in the calling method ShardedClientCursor::sendNextBatchAndReply we have:
replyToQuery( 0, r.p(), r.m(), buffer.buf(), buffer.len(), docCount,
|
_totalSent, hasMore ? getId() : 0 );
|
At that point docCount and _totalSent are the same.
Attachments
Issue Links
- depends on
-
SERVER-6236 Provide getter methods for extracting values from OP_REPLY
-
- Closed
-
- is depended on by
-
PYTHON-354 Traceback on query on sharded replicaset: starting_from set incorrectly
-
- Closed
-