Skip to content

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

Closed
hhughes wants to merge 1 commit intoapache:4.xfrom
hhughes:JAVA-3131
Closed

JAVA-3131: Add #retrieve method to EndPoint for when caller does not …#1735
hhughes wants to merge 1 commit intoapache:4.xfrom
hhughes:JAVA-3131

Conversation

@hhughes
Copy link
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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.

@NonNull
@Override
public InetSocketAddress resolve() {
return retrieve();
Copy link
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
Contributor

Work taken over to #1919

@absurdfarce
Copy link
Copy Markdown
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