-
Notifications
You must be signed in to change notification settings - Fork 37
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
Pre-resolve upstreams and skip nginx configtest
.
#312
Pre-resolve upstreams and skip nginx configtest
.
#312
Conversation
} else if (upstream instanceof UpstreamInfo) { | ||
UpstreamInfo upstreamInfo = ((UpstreamInfo) upstream); | ||
LOG.trace("Trying to resolve an UpstreamInfo upstream of {} with upstreamInfo.getResolvedUpstream() = {}, resolver.resolveUpstreamDNS(upstreamInfo.getUpstream()) = {}, upstreamInfo.getUpstream() = {}", upstreamInfo, upstreamInfo | ||
.getResolvedUpstream(), resolver.resolveUpstreamDNS(upstreamInfo.getUpstream()), upstreamInfo.getUpstream()); |
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.
Looks like this trace line will cause us to call resolveUpstreamDNS twice rather than one and storing in a variable for logging.
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
return Optional.of(String.format("%s:%d", ip, port)); | ||
} else { | ||
try { | ||
InetAddresses.forString(address); |
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.
is there a reason we don't try using the cache if it doesn't contain a :
?
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 carried this code over from ResolveUpstreamHelper
, but now you mention it, I don't see a reason for that. Gonna fix that 👍
&& allUpstreamsAreResolved(maybeResolvedRemoveUpstreams) | ||
&& allUpstreamsAreResolved(maybeResolvedReplaceUpstreams)) { | ||
LOG.trace("Request {} does not change a BaragonService and all upstreams were pre-resolved. Setting noValidate.", nonServiceChangeRequest.request.getQueuedRequestId().getRequestId()); | ||
BaragonRequest requestWithResolvedUpstreams = new BaragonRequestBuilder() |
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.
is it worth making a toBuilder on BaragonRequest?
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.
Probs, yeah. There's a lot of copy boilerplate at the moment
No description provided.