Uploaded image for project: 'Node.js Driver'
  1. Node.js Driver
  2. NODE-6839

AWS Lambda: MongoDB heartbeat failure has returned in v6

    • Type: Icon: Bug Bug
    • Resolution: Gone away
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: 6.14.1
    • Component/s: Lambda, Mongoose
    • 5
    • Not Needed
    • None
    • Hide

      1. What would you like to communicate to the user about this feature?
      2. Would you like the user to see examples of the syntax and/or executable code and its output?
      3. Which versions of the driver/connector does this apply to?

      Show
      1. What would you like to communicate to the user about this feature? 2. Would you like the user to see examples of the syntax and/or executable code and its output? 3. Which versions of the driver/connector does this apply to?
    • None
    • None
    • None
    • None
    • None
    • None

      Same constant reconnection issue from https://jira.mongodb.org/browse/NODE-3810

      After upgrading an AWS Lambda function to Mongoose v8 which uses mongodb driver 6, the constant reconnection issue has returned. 

       

      MongoDB Driver 4.5.0 fixed the issue.

      MongoDB Driver 6 the issue has returned.

       

      Based on the prior ticket, neal.beeken@mongodb.com  said: 

      "The core of the issue is that unlike normal environments our streaming monitoring protocol is supposed to keep sockets from timing out. MongoDB is supposed to be sending a hello response every heartbeatFrequencyMS (10sec) and normally our driver will not timeout on it's socketTimeout set to connectTimeoutMS (30sec) + heartbeatFrequencyMS (10sec) = 40sec because as long as MongoDB is healthy then the timeout will be refreshed. It appears that in lambda timeouts are allowed to expire in between invocations but of course they will not run without the handler being woken up, since the trigger needs to be the only thing that initiates the runtime. The problem is that when the handler does wake up all these timeout callbacks are expired and Node.js always handles timer callbacks first, so our driver believes that MongoDB is unhealthy and you see the pool clearing etc. What we've done in this updated branch is moved the socket timeout handling code into another queued timeout with the minimum timeout set. This will allow the event loop to reach the poll phase before our error handling is run. As soon as we've received data on the socket we clear the timeout avoiding all the pool reset issue. Since sockets will no longer be discarded you should not see connection counts go up anymore."

       

       

            Assignee:
            bailey.pearson@mongodb.com Bailey Pearson
            Reporter:
            ryanwoodmiami@gmail.com Ryan W
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved:
              None
              None
              None
              None