[SERVER-13562] Queries that use tailable cursors do not stream results if skip() is applied Created: 11/Apr/14 Updated: 11/Jul/16 Resolved: 15/Apr/14 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | 2.6.0 |
| Fix Version/s: | 2.6.1, 2.7.0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Steve Green | Assignee: | David Storch |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Operating System: | ALL | ||||||||
| Backport Completed: | |||||||||
| Participants: | |||||||||
| Description |
| Comments |
| Comment by Githook User [ 15/Apr/14 ] | ||||||||||||
|
Author: {u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}Message: Doing so could cause missing results for a tailable cursor. (cherry picked from commit 9d1f365bf8f0c3d6192284cffab4e3927722e17c) | ||||||||||||
| Comment by David Storch [ 15/Apr/14 ] | ||||||||||||
|
A clarification on the behavior of tailable cursors combined with limit:
I think the 2.6.1-pre- behavior is reasonable in that usually limits don't apply to tailable cursors, but if you really want a limit you can use a negative value. | ||||||||||||
| Comment by Githook User [ 15/Apr/14 ] | ||||||||||||
|
Author: {u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}Message: Doing so could cause missing results for a tailable cursor. | ||||||||||||
| Comment by J Rassi [ 12/Apr/14 ] | ||||||||||||
|
Confirmed the issue; updated summary/description accordingly. Thanks for the report. hari.khalsa@10gen.com, david.storch: please take a look. | ||||||||||||
| Comment by Steve Green [ 12/Apr/14 ] | ||||||||||||
|
Jason, I've been playing with this all day, and I'm now pretty convinced that the actual issue has nothing to do with capped collections created by older versions (although that may still be an issue, I don't really have any way to test it again, now that my server has been upgraded to 2.6). What appears to be different is the way the 'skip' parameter is handled on a v2.4 server compared to a v2.6 server in a query that results in a tailable cursor. The capped collections we have are used to hold audit logs. I have scripts in several languages (e.g., perl, c) that use a tailable cursor to emulate the unix 'tail -f' behavior. So the script counts the number of entries in the collection, subtracts the number of entries we want to display, and uses the skip parameter in the query to set the cursor on the first record we want to display. If I don't skip any records, the tailable cursor works as expected. If I skip a single record, the tailable cursor never sees any new data (note that this was not a problem with v2.4). So, to reproduce the issue, create a capped collection and add 2 records (as described in the original post), then use the following command to create a tailable cursor db.cap1.find().skip(1).addOption(34) Now, when you add new data to the capped collection, the new entries are not displayed. The new entries are displayed when this is done on a v2.4 server | ||||||||||||
| Comment by J Rassi [ 12/Apr/14 ] | ||||||||||||
|
slg1013: after following "Steps to Reproduce", I am unable to reproduce your findings. Can you give another set of instructions for reproducing either of the unexpected behaviors you're reporting on? | ||||||||||||
| Comment by Steve Green [ 11/Apr/14 ] | ||||||||||||
|
Perhaps I should file another bug, but I'm seeing strange behavior with tailable cursors even for capped collections created with v2.6.0. In one case, two capped collections created with the same command, where the tailable cursor appears to work with one and not the other; the only difference between the two collections being the number of documents inserted into each. In another case, using a perl script, the tail seems to work initially, but after I restart the script, new data doesn't appear to be sent to the cursor. I'm not able to nail down any of these differences in behavior to a single cause... | ||||||||||||
| Comment by Steve Green [ 11/Apr/14 ] | ||||||||||||
|
I should have mentioned that this is a 64 bit Windows Server 2008 installation. |