Cassandra
  1. Cassandra
  2. CASSANDRA-1031

get cassandra version via JMX (previously thrift)

    Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Fix Version/s: 0.7 beta 1
    • Component/s: Core
    • Environment:

      Linux x86

      Description

      I know I can get thrift API version.

      However, I writing a CLI for Cassandra in Python with readline support,
      and it will supports one-key deploy/upgrade cassandra+thrift remote,
      I need to get ApacheCassandra version to make sure it has deploy successfully.

      Please add Get *cassandra version* with thrift feature, thank you so much.

      1. trunk-1031.txt
        5 kB
        Matthew F. Dennis

        Issue Links

          Activity

          Hide
          Eric Evans added a comment -

          I agree that we need make it easier to obtain the release/software version, but disagree that exposing it over Thrift is the right answer. IMO, the right place for this is exposed via JMX (w/ cli access using nodetool or similar).

          Show
          Eric Evans added a comment - I agree that we need make it easier to obtain the release/software version, but disagree that exposing it over Thrift is the right answer. IMO, the right place for this is exposed via JMX (w/ cli access using nodetool or similar).
          Hide
          Jonathan Ellis added a comment -

          how would you make a client supporting both 0.6 (String keys) and 0.7 (byte[] keys) otherwise? call methods that only exist in one or the other? i suppose that's workable but it's a little ugly.

          what are the downsides to exposing it over thrift?

          Show
          Jonathan Ellis added a comment - how would you make a client supporting both 0.6 (String keys) and 0.7 (byte[] keys) otherwise? call methods that only exist in one or the other? i suppose that's workable but it's a little ugly. what are the downsides to exposing it over thrift?
          Hide
          Eric Evans added a comment -

          how would you make a client supporting both 0.6 (String keys) and 0.7 (byte[] keys) otherwise? call methods that only exist in one or the other? i suppose that's workable but it's a little ugly.

          These are differences in the API. Do you have in mind some way in which the release version better indicates this condition than the API version?

          what are the downsides to exposing it over thrift?

          That it encourages people to use it for gauging API compatibility instead of using the more capable API version (more capable because it does not move in lock-step with releases, and because it also encodes the type of change).

          Show
          Eric Evans added a comment - how would you make a client supporting both 0.6 (String keys) and 0.7 (byte[] keys) otherwise? call methods that only exist in one or the other? i suppose that's workable but it's a little ugly. These are differences in the API. Do you have in mind some way in which the release version better indicates this condition than the API version? what are the downsides to exposing it over thrift? That it encourages people to use it for gauging API compatibility instead of using the more capable API version (more capable because it does not move in lock-step with releases, and because it also encodes the type of change).
          Hide
          Jonathan Ellis added a comment -

          that makes sense to me.

          what about just having the server log its release version as part of the startup messages, for non-API stuff?

          Show
          Jonathan Ellis added a comment - that makes sense to me. what about just having the server log its release version as part of the startup messages, for non-API stuff?
          Hide
          Eric Evans added a comment -

          what about just having the server log its release version as part of the startup messages, for non-API stuff?

          Yeah, definitely, (we still have CASSANDRA-972 still open for that).

          Does that mean you don't like the idea of adding it to JMX (and nodetool)?

          Show
          Eric Evans added a comment - what about just having the server log its release version as part of the startup messages, for non-API stuff? Yeah, definitely, (we still have CASSANDRA-972 still open for that). Does that mean you don't like the idea of adding it to JMX (and nodetool)?
          Hide
          Jonathan Ellis added a comment -

          Does that mean you don't like the idea of adding it to JMX (and nodetool)?

          i'm okay with that too.

          Show
          Jonathan Ellis added a comment - Does that mean you don't like the idea of adding it to JMX (and nodetool)? i'm okay with that too.
          Hide
          Eric Evans added a comment -

          This patch exposes the release version over Thrift.

          I still haven't heard a sensible argument for what a non-management application (i.e. a data access client) would do with the release version that it could not do with the API version. In the absence of said argument, the release version seems applicable for management only (i.e. JMX), and exposing it over Thrift encourages improper use.

          I believe the true motivation is for management purposes (that is in fact the genesis of this ticket), which is why I suggested JMX. I empathize with the "sucks to use JMX outside Java" argument, but if this belongs in Thrift, so does everything else we currently expose with JMX.

          -0

          Show
          Eric Evans added a comment - This patch exposes the release version over Thrift. I still haven't heard a sensible argument for what a non-management application (i.e. a data access client) would do with the release version that it could not do with the API version. In the absence of said argument, the release version seems applicable for management only (i.e. JMX), and exposing it over Thrift encourages improper use. I believe the true motivation is for management purposes (that is in fact the genesis of this ticket), which is why I suggested JMX. I empathize with the "sucks to use JMX outside Java" argument, but if this belongs in Thrift, so does everything else we currently expose with JMX. -0
          Hide
          Jonathan Ellis added a comment -

          agree that it should go in JMX.

          Show
          Jonathan Ellis added a comment - agree that it should go in JMX.
          Hide
          Matthew F. Dennis added a comment -

          new patch adds CassandraVersion as an attribute over JMX and adds "version" command to nodetool

          Show
          Matthew F. Dennis added a comment - new patch adds CassandraVersion as an attribute over JMX and adds "version" command to nodetool
          Hide
          Jonathan Ellis added a comment -

          can we call it ReleaseVersion to be unambiguous?

          Show
          Jonathan Ellis added a comment - can we call it ReleaseVersion to be unambiguous?
          Hide
          Matthew F. Dennis added a comment -

          new patch (trunk-1031.txt) uses ReleaseVersion

          Show
          Matthew F. Dennis added a comment - new patch (trunk-1031.txt) uses ReleaseVersion
          Hide
          Jonathan Ellis added a comment -

          committed

          Show
          Jonathan Ellis added a comment - committed
          Hide
          Hudson added a comment -

          Integrated in Cassandra #493 (See http://hudson.zones.apache.org/hudson/job/Cassandra/493/)
          get cassandra release version via JMX. patch by mdennis; reviewed by jbellis for CASSANDRA-1031

          Show
          Hudson added a comment - Integrated in Cassandra #493 (See http://hudson.zones.apache.org/hudson/job/Cassandra/493/ ) get cassandra release version via JMX. patch by mdennis; reviewed by jbellis for CASSANDRA-1031

            People

            • Assignee:
              Matthew F. Dennis
              Reporter:
              Lee Li
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development