-
Notifications
You must be signed in to change notification settings - Fork 884
CASSJAVA-92: Local DC provided for nodetool clientstats #2036
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
base: 4.x
Are you sure you want to change the base?
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 |
---|---|---|
|
@@ -18,25 +18,36 @@ | |
package com.datastax.oss.driver.internal.core.context; | ||
|
||
import com.datastax.dse.driver.api.core.config.DseDriverOption; | ||
import com.datastax.oss.driver.api.core.config.DefaultDriverOption; | ||
import com.datastax.oss.driver.api.core.config.DriverExecutionProfile; | ||
import com.datastax.oss.driver.api.core.loadbalancing.LoadBalancingPolicy; | ||
import com.datastax.oss.driver.api.core.session.Session; | ||
import com.datastax.oss.driver.api.core.uuid.Uuids; | ||
import com.datastax.oss.driver.shaded.guava.common.collect.ImmutableMap; | ||
import com.datastax.oss.protocol.internal.request.Startup; | ||
import com.datastax.oss.protocol.internal.util.collection.NullAllowingImmutableMap; | ||
import com.fasterxml.jackson.databind.ObjectMapper; | ||
import edu.umd.cs.findbugs.annotations.Nullable; | ||
import java.util.Map; | ||
import java.util.Optional; | ||
import java.util.UUID; | ||
import net.jcip.annotations.Immutable; | ||
import org.slf4j.Logger; | ||
import org.slf4j.LoggerFactory; | ||
|
||
@Immutable | ||
public class StartupOptionsBuilder { | ||
|
||
public static final String DRIVER_NAME_KEY = "DRIVER_NAME"; | ||
public static final String DRIVER_VERSION_KEY = "DRIVER_VERSION"; | ||
public static final String DRIVER_BAGGAGE = "DRIVER_BAGGAGE"; | ||
public static final String APPLICATION_NAME_KEY = "APPLICATION_NAME"; | ||
public static final String APPLICATION_VERSION_KEY = "APPLICATION_VERSION"; | ||
public static final String CLIENT_ID_KEY = "CLIENT_ID"; | ||
|
||
private static final Logger LOG = LoggerFactory.getLogger(StartupOptionsBuilder.class); | ||
private static final ObjectMapper mapper = new ObjectMapper(); | ||
|
||
protected final InternalDriverContext context; | ||
private UUID clientId; | ||
private String applicationName; | ||
|
@@ -119,6 +130,12 @@ public Map<String, String> build() { | |
if (applicationVersion != null) { | ||
builder.put(APPLICATION_VERSION_KEY, applicationVersion); | ||
} | ||
boolean baggageEnabled = | ||
config.getBoolean(DefaultDriverOption.REQUEST_STARTUP_BAGGAGE_ENABLED, true); | ||
if (baggageEnabled) { | ||
// do not cache local DC as it can change within LBP implementation | ||
driverBaggage().ifPresent(s -> builder.put(DRIVER_BAGGAGE, s)); | ||
} | ||
|
||
return builder.build(); | ||
} | ||
|
@@ -142,4 +159,21 @@ protected String getDriverName() { | |
protected String getDriverVersion() { | ||
return Session.OSS_DRIVER_COORDINATES.getVersion().toString(); | ||
} | ||
|
||
private Optional<String> driverBaggage() { | ||
ImmutableMap.Builder<String, Object> builder = new ImmutableMap.Builder<>(); | ||
for (Map.Entry<String, LoadBalancingPolicy> entry : | ||
context.getLoadBalancingPolicies().entrySet()) { | ||
Map<String, ?> config = entry.getValue().getStartupConfiguration(); | ||
if (!config.isEmpty()) { | ||
builder.put(entry.getKey(), config); | ||
} | ||
} | ||
try { | ||
return Optional.of(mapper.writeValueAsString(builder.build())); | ||
} catch (Exception e) { | ||
LOG.warn("Failed to construct startup driver baggage", e); | ||
return Optional.empty(); | ||
} | ||
} | ||
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. DefaultDriverContext already defines lazy instantiation for (and access to) the startup options map for a given run. Rather than splitting the logic for determining the contents of a STARTUP message between DefaultDriverContext and this class the majority of the logic in this class should be consolidated into the existing DefaultDriverContext methods. 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. I have noticed that and though that other entries of the STARTUP options are added here. The justification of the logic would be that all "dedicated" properties for STARTUP message are lazily instantiated where you pointed out, whereas all properties taken from other components (e.g. compression) are automatically injected in 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. Okay, as I look at this again you're right, there's something of a bifurcation here already. The entries returned by DefaultDriverContext.buildStartupOptions() are more static key/value pairs, mostly (exclusively?) pairs that were used by Insights. Nearly all of those should be removed as part of CASSJAVA-73; driver name and version will stay but the rest should disappear. So how should we format this data? That question is still under discussion in CASSJAVA-92... we probably need to settle on what the data should look like and then adjust this impl accordingly. |
||
} |
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.
We should offer a configuration to disable getStartupConfiguration that matches the current behavior, for users with tons of profiles or custom policies that don't support it properly yet
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 don't know that I'm super-worried about this honestly. Users with custom LBPs should be okay; this PR includes an update to the primary interface com.datastax.oss.driver.api.core.loadbalancing.LoadBalancingPolicy with a default impl of getStartupConfiguration() that returns an empty map. So even if the user is working with a custom LBP that was implemented before this change they'll still be covered by the default method... and since DriverContext.getLoadBalancingPolicies() guarantees we'll get a map of Strings onto LoadBalancingPolicy impls that should cover everybody, right?
Users with lots of LBPs may have some slight overhead but it's far from clear to me that it's enough to worry about disabling the functionality all together.
Whaddya think @aratno?