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

Sporadically missing data from a query

    • Type: Icon: Bug Bug
    • Resolution: Done
    • Priority: Icon: Critical - P2 Critical - P2
    • None
    • Affects Version/s: 1.8.1
    • Component/s: Querying
    • Labels:
      None
    • Environment:
    • ALL

      The behavior we are seeing
      is that when we run a query, it will most of the time return a set of
      results that make sense, and then once out of 1000 queries, it will be
      missing a single record. I've tried sorting the results to see if
      it's always the same time, using a snapshot query, setting the Java
      client batch size to Integer.MAX_VALUE, and using the toArray() method
      on the Java client DBCursor object to get it to quickly pull the
      data. I've also removed any indexes that the queries might be using,
      so it doesn't appear to be an issue with indexes. We are only querying
      the master, though we saw this when querying slaves as well, though
      the data missing was very old and it wouldn't have been a replication
      issue.
      I am only able to reproduce this issue on our production servers
      (running Linux), and even with copying all of the files locally, I
      have been unable to reproduce this issue on my local machine (using
      replicates on Mac and Windows). All versions of the DB are 1.8.1.

      I can reproduce the issue in the shell as well, though not as easily.

      I turned on profiling logs and here
      is the output for the 3 queries (full with 523 results, missing with
      522 results, full again with 523 results):

      { "ts" : ISODate("2011-06-24T02:31:23.438Z"), "info" : "query
      pacman.packages ntoreturn:2147483647 reslen:619920 nscanned:7110
      \nquery: { query: { cluster: \"c1\", installableToEnvironment:

      { $in: [ \"UAT\", \"STAGING\", \"PRODUCTION\" ] }

      , deployments: { $elemMatch:
      { environmentType: \"STAGING\", $or: [

      { uninstallDate: null }

      ,
      { uninstallDate:

      { $gte: new Date(1308277883424) }

      } ] } } }, orderby:

      { _id: 1 }

      } nreturned:523 bytes:619904", "millis" : 17 }

      { "ts" : ISODate("2011-06-24T02:31:23.924Z"), "info" : "query
      pacman.packages ntoreturn:2147483647 reslen:618733 nscanned:7110
      \nquery: { query: { cluster: \"c1\", installableToEnvironment:

      { $in: [ \"UAT\", \"STAGING\", \"PRODUCTION\" ] }

      , deployments: { $elemMatch:
      { environmentType: \"STAGING\", $or: [

      { uninstallDate: null }

      ,
      { uninstallDate:

      { $gte: new Date(1308277883909) }

      } ] } } }, orderby:

      { _id: 1 }

      } nreturned:522 bytes:618717", "millis" : 19 }

      { "ts" : ISODate("2011-06-24T02:31:24.354Z"), "info" : "query
      pacman.packages ntoreturn:2147483647 reslen:619920 nscanned:7110
      \nquery: { query: { cluster: \"c1\", installableToEnvironment:

      { $in: [ \"UAT\", \"STAGING\", \"PRODUCTION\" ] }

      , deployments: { $elemMatch:
      { environmentType: \"STAGING\", $or: [

      { uninstallDate: null }

      ,
      { uninstallDate:

      { $gte: new Date(1308277884338) }

      } ] } } }, orderby:

      { _id: 1 }

      } nreturned:523 bytes:619904", "millis" : 19 }

            Assignee:
            aaron Aaron Staple
            Reporter:
            mnorman Michael D. Norman
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: