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

Fix maxTimeMS/readPref/readConcern for sharded view query

    • Minor Change
    • ALL
    • v3.4
    • Hide

      Start a one-shard cluster, then run the following against the mongos:

      db.c.drop();
      var padding = new Array(12000000).toString();
      for (var j=0; j < 100; ++j) {
          db.c.insert({x: padding})
      }
      db.createView("view", "c", []);
       
      // As expected, this errors with ExceededTimeLimit.
      db.c.find().maxTimeMS(1).itcount();
       
      // This operation is expected to time out, but instead it succeeds (and takes much longer than 1 millisecond).
      db.view.find().maxTimeMS(1).itcount();
      
      Show
      Start a one-shard cluster, then run the following against the mongos: db.c.drop(); var padding = new Array(12000000).toString(); for ( var j=0; j < 100; ++j) { db.c.insert({x: padding}) } db.createView( "view" , "c" , []);   // As expected, this errors with ExceededTimeLimit. db.c.find().maxTimeMS(1).itcount();   // This operation is expected to time out, but instead it succeeds (and takes much longer than 1 millisecond). db.view.find().maxTimeMS(1).itcount();
    • Query 2017-03-27, Query 2017-04-17

      When a sharded query on a view with maxTimeMS is rewritten on mongos to a query over the view's backing collection, the maxTimeMS is discarded. The consequence is that the maxTimeMS is not enforced for a sharded queries over views. This is true for both views on sharded and unsharded collections. MaxTimeMS does work, however, for queries against a view delivered directly to mongod.

            Assignee:
            james.wahlin@mongodb.com James Wahlin
            Reporter:
            david.storch@mongodb.com David Storch
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: