-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
feat(NODE-3011): Load Balancer Support #2909
Conversation
b8c5ac1
to
c536a22
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I got through almost half of the PR, going to take a fresh look at the rest of it Monday; meanwhile, some thoughts/questions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some more questions/comments, still not quite finished with the PR because I want to take a very close look at connection pool and sessions changes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did a full read through and left a few nit comments - I'll follow up with a final pass once some of the active comments on the PR have been resolved. Very nice work here! 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I went through and resolved the comments that were fully addressed; there are still a few that don't have replies (they might have gotten hidden by github on the main page) and some others that are open for discussion
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just merged in the changes stream test changes, so you can sync those in making the PR a bit smaller.
Got some nits and some more concept questions here:
b996d70
to
b8687dd
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My review request got cleared early I think, there are still comments outstanding (maybe collapsed by GH) I resolved what's been addressed hopefully that makes things more visible
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I went through and resolved all of my comments that didn't require follow up. There's a few things left on outstanding TODOs, but I think we're pretty close
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Accidentally cleared my review, resetting to "request changes" for the unresolved comments
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just following up on a couple of questions, resolved most outstanding comments
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just looking for some discussion on these:
LGTM pending merge conflict resolution and green tests |
453fc4c
to
a1f4489
Compare
212cc48
to
78a8b9b
Compare
302eef1
to
a7c188a
Compare
src/operations/aggregate.ts
Outdated
@@ -79,6 +79,10 @@ export class AggregateOperation<T = Document> extends CommandOperation<T> { | |||
} | |||
} | |||
|
|||
get isCursorCreating(): boolean { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems it would be better suited to be an aspect. If we could refactor to that it would be great but also something we can defer as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we actually need this on operations classes? The cursor design is such that subclasses of AbstractCursor
implement their own initialization which execute an operation, so we should have all the context we need about which operations create cursors without explicitly adding that context to operations classes. Is there a reason you can't move the check in executeOperation
into the AbstractCursor
call to _initialize ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well the addition of this was specifically for retry behaviour, and I wanted to keep all the retry related code in the same place and not have it scattered in multiple places.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also because of the findOne
case - it doesn't directly instantiate a cursor, it calls collection.find
in its operation which means that the session in that case it not owned by the cursor as executeOperation
creates the implicit session, not cursor._initialize
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Refactored in a026ce4 to use aspects.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What tests were failing without this condition? I tried running the tests locally without the creates_cursor aspect and all passed. There are some skips so maybe my environment is incomplete. (I have both multi and single env variables)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No tests fail without this condition, but it leaks the connection each time findOne
retries. This is because findOne
calls executeOperation
, which itself creates an implicit session with the owner
being a symbol. Then inside its execute method it calls collection.find
, which creates a cursor with the already created implicit session. The connection is pinned at the connection pool level because find
is a pinnable operation, and then when the cursor exhausts it does not unpin because the cursor is not the owner of the session. So the connection remains pinned to the session.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do agree in this case that the pin should never have occurred, but until we refactor the operation layer it's always going to be pinned here because we pin on connection checkout from the pool and the find command is pinnable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also we have already set a precedent for doing logic like this in executeOperation
: https://github.com/mongodb/node-mongodb-native/pull/2909/files#diff-f879df64594f4d352859a191839a674ff7a497d6a41f8ccfc71d965b48c6d3d6R144
363d41b
to
9168bbc
Compare
9168bbc
to
8ab4cfa
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couple of small suggestions but this is looking good to me. 🥇
Co-authored-by: Eric Adum <[email protected]>
Co-authored-by: Eric Adum <[email protected]>
No description provided.