-
Notifications
You must be signed in to change notification settings - Fork 1.3k
CSHARP-3984: Remove BinaryConnection.DropBox. #723
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
Conversation
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.
Nice to see it wasn't hard to remove the Dropbox!
Minor changes requested.
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.
Can we word the message more like many other messages we already have?
throw new InvalidOperationException($"Expected responseTo to be {responseTo} but was {receivedResponseTo}."); // should not be reached
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.
done
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 think it should be:
message.AccessBackingBytes(4);
Not 8.
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.
The argument to AccessBackingBytes is the offset into the message, not the number of bytes to read. responseTo is 8 bytes into the message header. So message.AccessBackingBytes(8) looks correct to me.
struct MsgHeader {
int32 messageLength; // total message size, including this
int32 requestID; // identifier for this message
int32 responseTo; // requestID from the original request
// (used in responses from db)
int32 opCode; // request type - see table below for details
}
https://docs.mongodb.com/manual/reference/mongodb-wire-protocol/#standard-message-header
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.
Good catch!
Sorry for the mis-direction.
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.
nice find @JamesKovacs !
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.
LGTM
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.
The argument to AccessBackingBytes is the offset into the message, not the number of bytes to read. responseTo is 8 bytes into the message header. So message.AccessBackingBytes(8) looks correct to me.
struct MsgHeader {
int32 messageLength; // total message size, including this
int32 requestID; // identifier for this message
int32 responseTo; // requestID from the original request
// (used in responses from db)
int32 opCode; // request type - see table below for details
}
https://docs.mongodb.com/manual/reference/mongodb-wire-protocol/#standard-message-header
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.
LGTM
df07e7e to
5b4a6eb
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.
This isn't what the name of the property says...
We should either change the name of the property or spin until the cluster is fully connected (presumably that means that the status of every server in the cluster is "connected").
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 might be stretching the definition of what a property normally does. Properties normally do almost zero work and return quickly.
Maybe this should be a method (or several):
var cluster = DriverTestConfiguration.GetClusterWithConnectedPrimary();
var cluster = DriverTestConfiguration.GetClusterWithConnectedSecondary();
var cluster = DriverTestConfiguration.GetFullyConnectedCluster();
temporary close this PR since we found unexpected behavior and due to low priority of this ticket
No description provided.