mirror of
https://github.com/scylladb/scylladb.git
synced 2026-04-24 02:20:37 +00:00
b112a3b78a
in this change, the type of the "generation" field of "sstable" in the return value of RESTful API entry point at "/storage_service/sstable_info" is changed from "long" to "string". this change depends on the corresponding change on tools/jmx submodule, so we have to include the submodule change in this very commit. this API is used by our JMX exporter, which in turn exposes the SSTable information via the "StorageService.getSSTableInfo" mBean operation, which returns the retrieved SSTable info as a list of CompositeData. and "generation" is a field of an element in the CompositeData. in general, the scylla JMX exporter is consumed by the nodetool, which prints out returned SSTable info list with a pretty formatted table, see tools/java/src/java/org/apache/cassandra/tools/nodetool/SSTableInfo.java. the nodetool's formatter is not aware of the schema or type of the SSTables to be printed, neither does it enforce the type -- it just tries it best to pretty print them as a tabular. But the fields in CompositeData is typed, when the scylla JMX exporter translates the returned SSTables from the RESTful API, it sets the typed fields of every `SSTableInfo` when constructing `PerTableSSTableInfo`. So, we should be consistent on the type of "generation" field on both the JMX and the RESTful API sides. because we package the same version of scylla-jmx and nodetool in the same precompiled tarball, and enforce the dependencies on exactly same version when shipping deb and rpm packages, we should be safe when it comes to interoperability of scylla-jmx and scylla. also, as explained above, nodetool does not care about the typing, so it is not a problem on nodetool's front. Signed-off-by: Kefu Chai <kefu.chai@scylladb.com> Closes #13834