Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: allow event loop to process during wait queue processing #2541

Merged
merged 1 commit into from Sep 14, 2020

Conversation

mbroadst
Copy link
Member

@mbroadst mbroadst commented Sep 9, 2020

Running processWaitQueue on the next tick allows the event loop
to process while the connection pool is processing large numbers of
wait queue members. This also uncovered a few issues with timing
in our tests, and in some cases our top-level API:

  • commitTransaction / abortTransaction use maybePromise now
  • endSession must wait for all the machinery behind the scenes to
    check out a connection and write a message before considering its
    job finished
  • internal calls to kill a cursor now await the the process of fully
    sending that command, even if they ignore the response

NODE-2803

NOTE: this is the port from 3.6 to 4.0

@mbroadst mbroadst force-pushed the NODE-2803/4.0/process-wait-queue-nextTick branch 2 times, most recently from d7eb72d to 2f83360 Compare September 10, 2020 13:10

cursor.close(() => client.close(() => done()));
promise.then(() => {
cursor.close(() => client.close(() => done()));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • One thought here is we may want to close the client regardless if success / error?
  • If there's no reason to use the promise response do we need to call then? Or is there some sort of lingering promise issue?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My thought here was "its an empty iterator across the result set" so there would never be a failure, but just in case I switched it to just return the promise. The reason this was initially introduced is that the test was not actually ever waiting for the promise to resolve, so we had random errors because the internal logic was never able to take the time to check out a connection before the client was closed.

@mbroadst mbroadst force-pushed the NODE-2803/4.0/process-wait-queue-nextTick branch from 2f83360 to cd91139 Compare September 14, 2020 11:41
Running `processWaitQueue` on the next tick allows the event loop
to process while the connection pool is processing large numbers of
wait queue members. This also uncovered a few issues with timing
in our tests, and in some cases our top-level API:
  - `commitTransaction` / `abortTransaction` use `maybePromise` now
  - `endSession` must wait for all the machinery behind the scenes to
     check out a connection and write a message before considering its
     job finished
   - internal calls to `kill` a cursor now await the the process of fully
     sending that command, even if they ignore the response

NODE-2803
@mbroadst mbroadst force-pushed the NODE-2803/4.0/process-wait-queue-nextTick branch from cd91139 to d95ed76 Compare September 14, 2020 11:47
@mbroadst mbroadst merged commit 7bbc783 into master Sep 14, 2020
@mbroadst mbroadst deleted the NODE-2803/4.0/process-wait-queue-nextTick branch September 14, 2020 15:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants