Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-13562

Queries that use tailable cursors do not stream results if skip() is applied

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: 2.6.0
    • Fix Version/s: 2.6.1, 2.7.0
    • Component/s: Querying
    • Labels:
      None
    • Operating System:
      ALL
    • Backport Completed:

      Description

      Issue Status as of April 15, 2014

      ISSUE SUMMARY
      Queries that use tailable cursors do not stream results if .skip() or negative values for .limit() are applied but instead close the cursor after returning the first batch.

      USER IMPACT
      Internal operations (replication etc.) are not affected but user-issued queries using tailable cursors may return incomplete results.

      WORKAROUNDS
      Try avoiding .skip() with tailable cursors and use other query predicates (e.g. $gt) if possible.

      RESOLUTION
      Tailable cursors now correctly continue to return batches via the getmore command when combined with .skip() or negative values of .limit().

      AFFECTED VERSIONS
      Version 2.6.0 is affected by this bug.

      PATCHES
      The patch is included in the 2.6.1 production release.

      Original description

      Queries that use tailable cursors do not stream results if skip() is applied.

      e.g.

      db.foo.find().addOption(34).skip(1)

      Original description:

      A capped collection created by an older version of the server can no longer be 'tracked' by a tailable cursor in 2.6.0; there was no issue with these collections using tailable cursors in v2.4.9. The capped collection being used was probably created pre-v2.2, but I'm not sure and can't find a way to determine. This collection did not have an index on '_id', which was added prior to the v2.6.0. upgrade.

      This is not an issue if the capped collection is created with v2.6.0.

      Steps to Reproduce:

      Using a capped collection created in an older version of the server, e.g. 'test.cap1', attempt to track the inserts to this collection using two mongodb shell sessions.

      In the first shell, perform inserts, e.g.,

      use test
      db.cap1.insert( { 'msg' : 'test' } )

      In the second shell, attempt to track new insertions, e.g.,

      use test
      db.cap1.find().addOption(34) // 2 = tailable, 32 = await_data

      When running with 2.6.0, no updates are displayed.

      If a new capped collection is created using v2.6.0, and the shell commands above are run, the updates are displayed.

        Attachments

          Issue Links

            Activity

              People

              • Votes:
                0 Vote for this issue
                Watchers:
                13 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: