• Type: Icon: Epic Epic
    • Resolution: Unresolved
    • Priority: Icon: Unknown Unknown
    • None
    • Affects Version/s: None
    • Component/s: None
    • Improved Client Close
    • Node Drivers
    • 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?
    • To Do
    • 2
    • 3.5
    • 4.5
    • 100
    • Hide

      Engineer(s): Aditi Khare, Neal Beeken
      2025-01-17: Target date set to 1-24-24

      Last 2 weeks (1.5 eng weeks):

      • The boilerplate to ensure resources remain intact after client.close() was completed, along with ensuring file reads are appropriately interrupted on close.
      • The tests for checking our timers and sockets are cleaned up is in review
      • Cursor tracking is in review (the client automatically closes any active cursors upon closing the client itself).

      Next 2 weeks (1 eng week):

      • Review and merge the remaining tests related to resource cleanup and the cursor tracking work
      • Thread an abort signal from the client throughout the driver (NODE-6632). This is expected to make all the "resources are cleaned up" tests pass.

      Known risks/impediments:

      • None

      Engineer(s): Aditi Khare
      2025-01-02: Target date set to January 17

      Last 2 weeks: (1 eng week)

      • Added test tooling infrastructure to test resource cleanup and set up testing for socket and file system resource testing

      Next 2 weeks:

      • Finish setting up integration testing (timers and server-side resource cleanup)
      • Add an abort controller to the client and plumb that to every node resource that can be tied to it for cancellation. Add cursor tracking and closing to MongoClient.close()

      Known risks/impediments:

      • N/A

      Engineer(s): Aditi Khare
      2024-12-19: Target date set to January 10

      Last 2 weeks:

      • The design document and project breakdown was finalized Dec 12.
      • The most recent week has been spent defining the integration tests and building up the tooling to support launching the driver in a new process and collecting information about the resources we're going to make sure are released.

      Next 2 weeks (1.5 eng weeks):

      • Finish working on the integration testing tools and test cases (various complex examples, kms requests, tls file reads etc)
      • Add an abort controller to the client and plumb that to every node resource that can be tied to it for cancellation. Add cursor tracking and closing to MongoClient.close()

      Known risks/impediments:

      • The testing is quite involved, and in the original design, we thought we would just be closing in-use connections. The new approach is more complete and requires more plumbing of a cancel token (generic term for abort signal) than previously thought was necessary, so we are increasing our original estimate by one engineering week.

      Show
      Engineer(s): Aditi Khare, Neal Beeken 2025-01-17: Target date set to 1-24-24 Last 2 weeks (1.5 eng weeks): The boilerplate to ensure resources remain intact after client.close() was completed, along with ensuring file reads are appropriately interrupted on close. The tests for checking our timers and sockets are cleaned up is in review Cursor tracking is in review (the client automatically closes any active cursors upon closing the client itself). Next 2 weeks (1 eng week): Review and merge the remaining tests related to resource cleanup and the cursor tracking work Thread an abort signal from the client throughout the driver ( NODE-6632 ). This is expected to make all the "resources are cleaned up" tests pass. Known risks/impediments: None Engineer(s): Aditi Khare 2025-01-02: Target date set to January 17 Last 2 weeks: (1 eng week) Added test tooling infrastructure to test resource cleanup and set up testing for socket and file system resource testing Next 2 weeks: Finish setting up integration testing (timers and server-side resource cleanup) Add an abort controller to the client and plumb that to every node resource that can be tied to it for cancellation. Add cursor tracking and closing to MongoClient.close() Known risks/impediments: N/A Engineer(s): Aditi Khare 2024-12-19: Target date set to January 10 Last 2 weeks: The design document and project breakdown was finalized Dec 12. The most recent week has been spent defining the integration tests and building up the tooling to support launching the driver in a new process and collecting information about the resources we're going to make sure are released. Next 2 weeks (1.5 eng weeks): Finish working on the integration testing tools and test cases (various complex examples, kms requests, tls file reads etc) Add an abort controller to the client and plumb that to every node resource that can be tied to it for cancellation. Add cursor tracking and closing to MongoClient.close() Known risks/impediments: The testing is quite involved, and in the original design, we thought we would just be closing in-use connections. The new approach is more complete and requires more plumbing of a cancel token (generic term for abort signal) than previously thought was necessary, so we are increasing our original estimate by one engineering week.

      Summary

      What is the problem or use case, what are we trying to achieve?

      Motivation

      Who is the affected end user?

      Who are the stakeholders?

      How does this affect the end user?

      Are they blocked? Are they annoyed? Are they confused?

      How likely is it that this problem or use case will occur?

      Main path? Edge case?

      If the problem does occur, what are the consequences and how severe are they?

      Minor annoyance at a log message? Performance concern? Outage/unavailability? Failover can't complete?

      Is this issue urgent?

      Does this ticket have a required timeline? What is it?

      Is this ticket required by a downstream team?

      Needed by e.g. Atlas, Shell, Compass?

      Is this ticket only for tests?

      Is this ticket have any functional impact, or is it just test improvements?

      Cast of Characters

      Engineering Lead:
      Document Author:
      POCers:
      Product Owner:
      Program Manager:
      Stakeholders:

      Channels & Docs

      Slack Channel

      [Scope Document|some.url]

      [Technical Design Document|some.url]

            Assignee:
            neal.beeken@mongodb.com Neal Beeken
            Reporter:
            tom.selander@mongodb.com Tom Selander
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: