[CDRIVER-1221] mongoc_cursor_is_alive() returns false for live cursor from find command Created: 05/May/16 Updated: 10/Aug/16 Resolved: 10/May/16 |
|
| Status: | Closed |
| Project: | C Driver |
| Component/s: | libmongoc |
| Affects Version/s: | 1.4.0 |
| Fix Version/s: | 1.4.0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Jeremy Mikola | Assignee: | A. Jesse Jiryu Davis |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Description |
|
After upgrading PHPC and HHVM to 1.4.0-dev, we started seeing some failed tests that were asserting whether a cursor returned by a find command was dead or alive (
The last change to this code was the addition of CURSOR_FAILED() in a3d0fe2 for Some debugging revealed that cursor->rpc.header.opcode is the cause. For a freshly executed query on its first batch (of two), I observed the following:
We would expect cursor->rpc.header.opcode to be 1 (i.e. MONGOC_OPCODE_REPLY) here, as it is with a legacy OP_QUERY or on any 1.3.x version of libmongoc. This appears to be a regression. |
| Comments |
| Comment by Githook User [ 19/May/16 ] |
|
Author: {u'username': u'jmikola', u'name': u'Jeremy Mikola', u'email': u'jmikola@gmail.com'}Message: This changes our tests based on upstream fixes for mongoc_cursor_is_alive() in |
| Comment by A. Jesse Jiryu Davis [ 10/May/16 ] |
|
AFAICT as far back as 1.2.0, if you have more than 101 docs in a collection and do "find", "is_alive" is false after the 101st document. |
| Comment by Jeremy Mikola [ 10/May/16 ] |
If I understand correctly, we should be able to verify this long-standing bug by tweaking our tests to iterate over three batches instead of two? With the bugged behavior, we would see the cursor marked as dead during the middle batch, when it is very much still alive. |
| Comment by A. Jesse Jiryu Davis [ 10/May/16 ] |
|
Actually, I've tested back to 1.2.0 with MongoDB 2.6 (so, before the "find" command), and the behavior seems consistent: it's not until after mongoc_cursor_next has returned NULL that mongoc_cursor_is_alive is false. Furthermore, there was a bug where a multi-batch cursor was not "alive" after the first batch, a bug which predates 1.2.0. That bug is fixed in the patch for this issue. |
| Comment by A. Jesse Jiryu Davis [ 09/May/16 ] |
|
My fix wasn't correct at the final document. If there are 3 documents and batch size is 2, mongoc_cursor_is_alive should be true after the first 2 calls to mongoc_cursor_next, then false after the 3rd call. Instead, it's false after the 4th call (the first call to mongoc_cursor_next that returns false). |
| Comment by Githook User [ 09/May/16 ] |
|
Author: {u'username': u'ajdavis', u'name': u'A. Jesse Jiryu Davis', u'email': u'jesse@mongodb.com'}Message: |