Currently there doesn't seem to be any way to readily identify the driver that clients are using to connect to Cassandra. Add the capability of identifying the driver through metadata information much like how HTTP Clients identify themselves through User-Agent HTTP header. This is useful for debugging in large deployments where clients tend to use different drivers, wrappers and language bindings to connect to Cassandra. This can help surface issues as well as help detect clients which are using older or unsupported drivers.
The identification information should be a string that unambiguously identifies the driver. It should include information such as the name of the driver, it's version, CQL version, Platform (Linux, macOS, Windows, etc.) and architecture (x86, x86_64).
We should surface this information in `nodetool clientstats` command.
I have a similar ticket open for Cassandra (see: https://issues.apache.org/jira/browse/CASSANDRA-14275). I have a proof of concept that I can put up shortly.
Looking great! I have some minor feedback, but otherwise it looks good to me:
The _OPTION part of the keys is redundant, it would be good to remove that (i.e. use DRIVER_NAME instead of DRIVER_NAME_OPTION)
Since Startup is a package private class, we don't need to have 2 different constructors. I think just keeping only Startup(ProtocolOptions.Compression compression, boolean noCompact) and setting the options automatically would be fine. driverName / driverVersion instance fields would not be needed since they aren't used outside of constructor.
Minor nit, but would prefer DataStax Java Driver over DataStaxJavaDriver for the name.
Thanks, Andrew. I have addressed all your comments including the nit
Excellent, looks great! The only other small thing I just noticed was that DRIVER_NAME could be static final since its always the same for each instance. Also the Optional import can be removed since its no longer used. Pending the review on the C* side, please open up a pull request against the driver so we can incorporate it into a future release.
Similar as discussed on , we want to get this in. This is straightforward thing to implement, I'll create a separate PR.