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

Duplicate error code 15927, thrown directly and massert-ed

    XMLWordPrintableJSON

Details

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major - P3 Major - P3
    • None
    • None
    • None
    • None
    • ALL

    Description

      Code 15927 is used in two places in the code for different cases:

      src/mongo/client/dbclient_rs.cpp line 661:

          string errmsg;
          try{
              if( ! newConn->connect( h , errmsg ) ){
                  throw DBException( errmsg, 15927 );
              }
              log() << "successfully connected to new host " << *i << " in replica set " << this->_name << endl;
          }
          catch( DBException& e ){
              warning() << "cannot connect to new host " << *i << " to replica set " << this->_name << causedBy( e ) << endl;
          }

      src/mongo/db/database.cpp line 434:

          // todo: protect against getting sprayed with requests for different db names that DNE - 
          //       that would make the DBs map very large.  not clear what to do to handle though, 
          //       perhaps just log it, which is what we do here with the "> 40" : 
          bool cant = !Lock::isWriteLocked(ns);
          if( logLevel >= 1 || m.size() > 40 || cant || DEBUG_BUILD ) {
              log() << "opening db: " << (path==dbpath?"":path) << ' ' << dbname << endl;
          }
          massert(15927, "can't open database in a read lock. if db was just closed, consider retrying the query. might otherwise indicate an internal error", !cant);

      It seems bad to reuse an error code, but also bad to change one that a customer might be using. The one in database.cpp suggests in its text that it can't be interpreted unambiguously, so maybe it's the one that should be changed.

      It seems dangerous to use error codes directly in "throw DBException()" statements because our automated tools for preventing duplicate IDs will not detect them.

      Attachments

        Activity

          People

            Unassigned Unassigned
            tad Tad Marshall
            Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: