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

Accept long instead of int in SocketSettings.Builder.connectTimeout/readTimeout #1279

Merged
merged 2 commits into from
Jan 4, 2024

Conversation

stIncMale
Copy link
Member

@stIncMale stIncMale self-assigned this Dec 12, 2023
@@ -93,25 +95,27 @@ public Builder applySettings(final SocketSettings socketSettings) {
/**
* Sets the socket connect timeout.
*
* @param connectTimeout the connect timeout
* @param connectTimeout the connect timeout.
* The timeout converted to milliseconds must not be greater than {@link Integer#MAX_VALUE}.
Copy link
Member Author

Choose a reason for hiding this comment

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

We had this requirement for forever (the toIntExact conversion does not, therefore, introduce a new restriction), but did not document it. Now it is documented.

Comment on lines -263 to -268
int result = (int) (connectTimeoutMS ^ (connectTimeoutMS >>> 32));
result = 31 * result + (int) (readTimeoutMS ^ (readTimeoutMS >>> 32));
result = 31 * result + receiveBufferSize;
result = 31 * result + sendBufferSize;
result = 31 * result + proxySettings.hashCode();
return result;
Copy link
Member Author

Choose a reason for hiding this comment

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

The bit shifting in the old code became irrelevant, i.e., hashCode had to be updated. I updated it to use Objects.hash.

Comment on lines +67 to +68
private int connectTimeoutMS = 10000;
private int readTimeoutMS;
Copy link
Member Author

Choose a reason for hiding this comment

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

There is no reason to have the fields internally of the long type, because the millisecond values were not allowed (and will continue being not allowed) to be greater than Integer.MAX_VALUE.

@jyemin jyemin requested review from jyemin and removed request for rozza December 15, 2023 14:01
public Builder connectTimeout(final int connectTimeout, final TimeUnit timeUnit) {
this.connectTimeoutMS = MILLISECONDS.convert(connectTimeout, timeUnit);
public Builder connectTimeout(final long connectTimeout, final TimeUnit timeUnit) {
this.connectTimeoutMS = toIntExact(MILLISECONDS.convert(connectTimeout, timeUnit));
Copy link
Contributor

Choose a reason for hiding this comment

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

Would this be a new thing to have the driver throw ArithmeticException on an invalid value from the application? Should the exception instead be wrapped in IllegalArgumentException, making it similar to ConnectionString?

Copy link
Member Author

Choose a reason for hiding this comment

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

Thank you, done.

public Builder connectTimeout(final int connectTimeout, final TimeUnit timeUnit) {
this.connectTimeoutMS = MILLISECONDS.convert(connectTimeout, timeUnit);
public Builder connectTimeout(final long connectTimeout, final TimeUnit timeUnit) {
this.connectTimeoutMS = toIntExact(MILLISECONDS.convert(connectTimeout, timeUnit));
Copy link
Contributor

Choose a reason for hiding this comment

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

Consider adding a test for the new behavior.

Copy link
Member Author

Choose a reason for hiding this comment

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

Done.

@@ -21,7 +21,9 @@ import spock.lang.Specification

import static java.util.concurrent.TimeUnit.MILLISECONDS


/**
* New unit tests for {@link SocketSettings} are to be added to {@link SocketSettingsTest}.
Copy link
Member Author

Choose a reason for hiding this comment

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

The team discussed and made a decision to create new tests in Java where this is not too much of a hassle, even if there are existing tests in Groovy.

@stIncMale stIncMale requested a review from jyemin January 3, 2024 00:52
@stIncMale stIncMale merged commit 0ecac8c into mongodb:master Jan 4, 2024
58 checks passed
@stIncMale stIncMale deleted the JAVA-3897 branch January 4, 2024 23:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants