several exception cases do not put back the dbport in pool, resulting in forever hanging pool to that server

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Done
    • Priority: Major - P3
    • 2.5.3
    • Affects Version/s: None
    • Component/s: None
    • None
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      we are not properly having port.done() in a finally close.
      There are at least 2 spots where port is not properly put back in pool.

      One spot is pretty obvious:

      • in DBTCPConnector.call(), if there is any ioexception during call, then _error() is called
      • in _error(), does a checkMaster(), which will throw an exception if there is no new master
      • due to this exception, the following mp.error() is not called, so port is not put back in pool.
        Consequently if you have a replset, and master dies but it takes some time to elect new master, any find operation will take away a port from pool.
        You just need 10 find calls to make pool unusable for that server, until the application is restarted.

      Other spot:

      • in DBTCPConnector.say(), in case that there is a writeconcern, getlasterror() is called
      • if there is ioexception in getlasterror, it is converted into mongoexception
      • the catch block of mongoexception does not put port back in pool.
        Consequently if you have any ioexception in during the getlasterror call, the port will get lost.

            Assignee:
            Antoine Girbal (Inactive)
            Reporter:
            Antoine Girbal (Inactive)
            None
            Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: