Clean up SocketFinder.findSocket(...) handling#663
Merged
cheenamalhotra merged 3 commits intomicrosoft:devfrom Jun 21, 2018
Merged
Clean up SocketFinder.findSocket(...) handling#663cheenamalhotra merged 3 commits intomicrosoft:devfrom
cheenamalhotra merged 3 commits intomicrosoft:devfrom
Conversation
Codecov Report
@@ Coverage Diff @@
## dev #663 +/- ##
============================================
- Coverage 48.32% 48.16% -0.16%
- Complexity 2623 2625 +2
============================================
Files 113 113
Lines 26626 26609 -17
Branches 4480 4472 -8
============================================
- Hits 12867 12817 -50
- Misses 11601 11662 +61
+ Partials 2158 2130 -28
Continue to review full report at Codecov.
|
8bd7d2f to
0f5c355
Compare
Contributor
Contributor
|
Hi @sehrope , Would you mind resolving the conflicts? |
0f5c355 to
c433c4f
Compare
Contributor
Author
|
@ulvii Done. |
Refactors socket creation in SocketFinder.findSocket(...) to simplify handling of socket creation. When the host resolves to a single address the driver now defers to getConnectedSocket(...) to create the socket without spawning any threads. This happens regardless of whether we're running on an IBM JDK. Previously the single address case would still use NIO on an IBM JDK. On non-IBM JDKs the driver now handles both IPv4 and IPv6 addresses concurrently with a single shared timeout. Previously hosts that resolved to both types of addresses were allowed half the timeout for socket creation per address type with the resolution performed sequentially.
c433c4f to
487574e
Compare
Contributor
Author
|
One more rebase as dev has been updated since the last one. |
peterbae
approved these changes
May 29, 2018
ulvii
approved these changes
Jun 20, 2018
cheenamalhotra
approved these changes
Jun 20, 2018
Member
cheenamalhotra
left a comment
There was a problem hiding this comment.
I agree with the advantage of having a generic implementation for IBM JDK and OpenJDK - which was differently done before, also using full timeout for all IP addresses instead of splitting half between IPv4 and IPv6 makes it better.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Cleans up
SocketFinder.findSocket(...)a bit and simplifies the logic for the simple case of a single address being resolved.This changes some of the prior functionality though I wouldn't consider it a breaking change as it's not documented functionality and the new approach seems (to me) to be more correct. Previously if a host resolved to both IPv4 and IPv6 addresses, each set would get half the time out and the IPv4 addresses would be attempted first. This PR changes the logic to handle all IP addresses concurrently using the full timeout.
It also centralizes the logic for handling the case where there's a single address. Regardless of JVM type it now attempts to directly connect to it. This changes the behavior for the IBM JDK as previously it would have attempted the NIO approach followed by a normal socket creation upon success. Again this seems like a better choice as the overall logic is simpler and end result is the same.
This PR was coded atop #662. See there for more details on the parent change.