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

ShardingTest.js Does Not Merge Multiple SetParameters Properly

    • Cluster Scalability
    • ALL
    • 5
    • 4

      ShardingTest will merge its parameters object with its own "other" field. However, if both the regular field and the other variant of that field contain a setParameter object, the regular field will be clobbered in favor of the other field, instead of merging the parameters.

      For example, the continuous stepdown suite sets the other config server log verbosity, and the resharding test fixture sets the regular critical section timeout. The resulting params object to ShardingTest looks like this:

      {
          "mongos": 1,
          "mongosOptions": {
              "setParameter": {}
          },
          "config": 1,
          "configOptions": {
              "setParameter": {
                  "reshardingCriticalSectionTimeoutMillis": 86400000
              }
          },
          "shards": 3,
          "rs": {
              "nodes": 2
          },
          "rsOptions": {
              "setParameter": {
                  "maxNumberOfTransactionOperationsInSingleOplogEntry": 1
              },
              "oplogSize": 256
          },
          "configReplSetTestOptions": {},
          "manualAddShard": true,
          "configShard": false,
          "other": {
              "configOptions": {
                  "setParameter": {
                      "logComponentVerbosity": "{\n\t\"verbosity\" : 0,\n\t\"command\" : {\n\t\t\"verbosity\" : 1\n\t},\n\t\"network\" : {\n\t\t\"verbosity\" : 1,\n\t\t\"asio\" : {\n\t\t\t\"verbosity\" : 2\n\t\t}\n\t},\n\t\"tracking\" : {\n\t\t\"verbosity\" : 0\n\t}\n}"
                  }
              }
          }
      }
      

      And after merging, it will look like this:

      {
          "mongos": 1,
          "mongosOptions": {
              "setParameter": {}
          },
          "config": 1,
          "configOptions": {
              "setParameter": {
                  "logComponentVerbosity": "{\n\t\"verbosity\" : 0,\n\t\"command\" : {\n\t\t\"verbosity\" : 1\n\t},\n\t\"network\" : {\n\t\t\"verbosity\" : 1,\n\t\t\"asio\" : {\n\t\t\t\"verbosity\" : 2\n\t\t}\n\t},\n\t\"tracking\" : {\n\t\t\"verbosity\" : 0\n\t}\n}"
              }
          },
          "shards": 3,
          "rs": {
              "nodes": 2
          },
          "rsOptions": {
              "setParameter": {
                  "maxNumberOfTransactionOperationsInSingleOplogEntry": 1
              },
              "oplogSize": 256
          },
          "configReplSetTestOptions": {},
          "manualAddShard": true,
          "configShard": false,
          "other": {
              "configOptions": {
                  "setParameter": {
                      "logComponentVerbosity": "{\n\t\"verbosity\" : 0,\n\t\"command\" : {\n\t\t\"verbosity\" : 1\n\t},\n\t\"network\" : {\n\t\t\"verbosity\" : 1,\n\t\t\"asio\" : {\n\t\t\t\"verbosity\" : 2\n\t\t}\n\t},\n\t\"tracking\" : {\n\t\t\"verbosity\" : 0\n\t}\n}"
                  }
              }
          }
      }
      

      This has lead to at least one failure in BF-28593 where the critical section timed out due to the timeout parameter not being extended as expected.

            Assignee:
            backlog-server-cluster-scalability [DO NOT USE] Backlog - Cluster Scalability
            Reporter:
            brett.nawrocki@mongodb.com Brett Nawrocki
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: