|
Creating a tailable cursor on a capped collection with isAwaitData: false should not block when calling hasNext() on the cursor according to this docs page
However, the following script will still block on hasNext calls:
db.coll.drop();
|
db.createCollection("coll", {size: 100, capped: true});
|
for (var i = 0; i < 10; i++) db.coll.insert({x: i});
|
|
// create a tailable cursor
|
var cursor = db.coll.find().tailable({isAwaitData: false});
|
|
// exhaust cursor
|
while (cursor.hasNext()) cursor.next();
|
|
// the following blocks for one second despite isAwaitData being false
|
cursor.hasNext();
|
This is reproducible using mongo shell version v3.4.7 as well as on master, v3.5.12-204-ge2defe9a85.
Using mongoreplay, it shows the shell passes awaitData:true to the find command regardless of the value of isAwaitData.
12 Sep 17 11:48 -0400 (Connection: 30:1043) op_command find test Request:{"command_args":{"awaitData":true,"filter":{},"find":"coll","tailable":true},"input_docs":[],"metadata":{}}
|
So it looks like a shell issue, not a server issue. I think it is caused from the definition of tailable being incorrect (or the docs are incorrect). The function in shell/query.js for tailable is expecting a boolean:
DBQuery.prototype.tailable = function(awaitData) {
|
this._checkModify();
|
this.addOption(DBQuery.Option.tailable);
|
|
// Set await data if either specifically set or not specified
|
if (awaitData || awaitData == null) {
|
this.addOption(DBQuery.Option.awaitData);
|
}
|
|
return this;
|
};
|
|