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

JAVA-3131: Add #retrieve method to EndPoint for when caller does not … #1735

Closed
wants to merge 1 commit into from

Conversation

hhughes
Copy link
Contributor

@hhughes hhughes commented Oct 20, 2023

…need the endpoint to be proactively resolved

Refactor existing usages of EndPoint#resolve to use retrieve when resolved ip addresses are not needed.

@hhughes hhughes force-pushed the JAVA-3131 branch 3 times, most recently from 5305d76 to 989f1a5 Compare October 20, 2023 22:25
…need the endpoint to be proactively resolved

Refactor existing usages of EndPoint#resolve to use retrieve when resolved ip addresses are not needed.
Copy link
Contributor

@absurdfarce absurdfarce left a comment

Choose a reason for hiding this comment

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

A few minor things but overall I very much like where this change is headed!

@NonNull
default SocketAddress retrieve() {
return resolve();
}
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm wondering if it makes sense to provide a default implementation for the new method. It's unlikely we'll be adding a new endpoint type anytime soon but failing to distinguish between "look up the addresses again" and "give me the addresses you got last time you looked them up" is what got us into this situation in the first place. I kinda feel like having this as a default might lend itself to landing back in exactly that situation.

@@ -38,6 +38,11 @@ public DefaultEndPoint(InetSocketAddress address) {
@NonNull
@Override
public InetSocketAddress resolve() {
return retrieve();
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit: save yourself the method call overhead here and just return address directly... ?

try {
int[] comp = Arrays.stream(addr.split("\\.")).mapToInt(Integer::parseInt).toArray();
return InetAddress.getByAddress(
new byte[] {(byte) comp[0], (byte) comp[1], (byte) comp[2], (byte) comp[3]});
Copy link
Contributor

Choose a reason for hiding this comment

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

Is there a particular reason to jump through the splitting/to Int/toArray ops here rather than just using InetAddress.getByName()? I don't think it does a reverse lookup if you just give it a string containing an IP address but I could be wrong.

Copy link
Contributor

Choose a reason for hiding this comment

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

Sorry, I am confused. Could you pls explain more?
InetAddress.getByAddress does not do reverse lookup. InetAddress.getByName will look it up. We don't want it to look up. Therefore, I think InetAddress.getByAddress is the one we should use. :)


@Override
public InetSocketAddress retrieve() {
return proxyAddress;
Copy link
Contributor

Choose a reason for hiding this comment

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

Don't we want to cache the last value returned by resolve() and return that here instead?

@SiyaoIsHiding
Copy link
Contributor

Work taken over to #1919

@absurdfarce
Copy link
Contributor

Replaced by #1919. Review comments will be handled there.

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