-
Notifications
You must be signed in to change notification settings - Fork 42
fix: expand contact point hostnames to all DNS IPs at connection time (DRIVER-201) — Part 1/2 #889
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -147,8 +147,7 @@ public Queue<Node> newQueryPlan( | |
| switch (stateRef.get()) { | ||
| case BEFORE_INIT: | ||
| case DURING_INIT: | ||
| // The contact points are not stored in the metadata yet: | ||
| List<Node> nodes = new ArrayList<>(context.getMetadataManager().getContactPoints()); | ||
| List<Node> nodes = new ArrayList<>(context.getMetadataManager().getResolvedContactPoints()); | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This synchronous query-plan path should not trigger DNS resolution. DNS-expanded contact points should be resolved through the async control-connection path, then passed into the plan once available. Please avoid calling a blocking or async-waiting resolver from
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. |
||
| Collections.shuffle(nodes); | ||
| return new ConcurrentLinkedQueue<>(nodes); | ||
| case RUNNING: | ||
|
|
@@ -164,15 +163,33 @@ public Queue<Node> newQueryPlan( | |
|
|
||
| @NonNull | ||
| public Queue<Node> newControlReconnectionQueryPlan() { | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This method needs to become async because it now depends on DNS expansion. Please expose an async control-reconnection query-plan method and compose resolved contact points there. Expected flow: This keeps the existing control-connection sequencing but removes admin-thread blocking.
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In #890 ( |
||
| // Read the state once, before building the regular plan. State transitions are monotonic | ||
| // (BEFORE_INIT -> DURING_INIT -> RUNNING -> ...), so this captured value is <= the value | ||
| // newQueryPlan() reads internally; that guarantees we never both build the plan from resolved | ||
| // contact points (pre-RUNNING branch of newQueryPlan) and append them again below. | ||
| State state = stateRef.get(); | ||
| Queue<Node> regularQueryPlan = newQueryPlan(null, DriverExecutionProfile.DEFAULT_NAME, null); | ||
|
|
||
| if (context | ||
| .getConfig() | ||
| .getDefaultProfile() | ||
| .getBoolean(DefaultDriverOption.CONTROL_CONNECTION_RECONNECT_CONTACT_POINTS)) { | ||
| Set<DefaultNode> originalNodes = context.getMetadataManager().getContactPoints(); | ||
| // Only append resolved contact points as an explicit fallback once the LBP is RUNNING: before | ||
| // that (BEFORE_INIT/DURING_INIT), newQueryPlan() above already built regularQueryPlan directly | ||
| // from getResolvedContactPoints(), so appending them again here would just duplicate every | ||
| // entry and re-trigger DNS resolution for no benefit. | ||
| if (state == State.RUNNING | ||
| && context | ||
| .getConfig() | ||
| .getDefaultProfile() | ||
| .getBoolean(DefaultDriverOption.CONTROL_CONNECTION_RECONNECT_CONTACT_POINTS) | ||
| && !context.getTopologyMonitor().reresolvesNodeAddresses()) { | ||
| // Use DNS-expanded contact points so every resolved IP is tried as a fallback, not just | ||
| // the first IP the JVM happens to return for the hostname. | ||
| // | ||
| // Skipped when the topology monitor re-resolves node addresses on its own (e.g. proxy-based | ||
| // monitors such as client routes or the cloud SNI proxy): those keep addresses fresh without | ||
| // this fallback, and appending raw contact points could resurrect nodes the monitor has | ||
| // authoritatively removed. | ||
| List<Node> resolvedNodes = context.getMetadataManager().getResolvedContactPoints(); | ||
| List<Node> contactNodes = new ArrayList<>(); | ||
| for (DefaultNode node : originalNodes) { | ||
| for (Node node : resolvedNodes) { | ||
| contactNodes.add(DefaultNode.newContactPoint(node.getEndPoint(), context)); | ||
| } | ||
| Collections.shuffle(contactNodes); | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.