CASSJAVA-92: Local DC provided for nodetool clientstats #2036
Conversation
lukasz-antoniak
force-pushed
the
CASSJAVA-92
branch
from
d637315 to
1afcf84
Compare
| DefaultDriverOption.LOAD_BALANCING_LOCAL_DATACENTER); // DC from configuration | ||
| } | ||
| return dc; | ||
| } |
There was a problem hiding this comment.
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.
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 build() method.
There was a problem hiding this comment.
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.
| @@ -119,6 +122,12 @@ public Map<String, String> build() { | |||
| if (applicationVersion != null) { | |||
| builder.put(APPLICATION_VERSION_KEY, applicationVersion); | |||
| } | |||
| if (applicationLocalDc == null) { | |||
| applicationLocalDc = localDc(config); | |||
There was a problem hiding this comment.
config here is just the default profile but any profile can define a local datacenter... which in turn means we need to think about how execution profiles interact with this functionality.
I'm going to raise this point on the JIRA ticket; I think it warrants further discussion.
| profile.getString( | ||
| DefaultDriverOption.LOAD_BALANCING_LOCAL_DATACENTER); // DC from configuration | ||
| } | ||
| return dc; |
There was a problem hiding this comment.
Mentioned to @lukasz-antoniak in separate conversation but I'll document is here as well; checking for the presence of this config prop isn't enough. You also need to see whether you have an LBP implementation which cares about that prop; it's entirely possible a user could define LOAD_BALANCING_LOCAL_DATACENTER and then use some other LBP which just ignores it.
It's also worth noting that some LBPs can infer the local DC if it isn't present... which means they may not have anything defined for this property but would still have a notion of a local DC.
Fixes: CASSJAVA-92