cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-4351) Consider storing more informations on peers in system tables
Date Thu, 04 Oct 2012 21:29:48 GMT


Jonathan Ellis commented on CASSANDRA-4351:

+1 on 0001.

For 0002 ... what if instead we change LongToken (the default on 1.2 and what people "should"
be using) to/fromString to hex-encode with a constant width, the way CASSANDRA-4550 wanted?
 Of course then we'd need to switch it to unsigned comparison to be consistent with what the
hex implies.  Dunno, maybe it's not worth the trouble.
> Consider storing more informations on peers in system tables 
> -------------------------------------------------------------
>                 Key: CASSANDRA-4351
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Sylvain Lebresne
>            Priority: Minor
>             Fix For: 1.2.0 beta 2
>         Attachments: 0001-4351.txt, 0002-Save-tokens-as-strings.txt
> Currently, the only thing we keep in system tables about other peers is their token and
IP addresses. We should probably also record the new ring_id, but since CASSANDRA-4018 makes
system table easily queriable, may it could be worth adding some more information (basically
most of what we gossip could be a candidate (schema UUID, status, C* version, ...)) as a simple
way to expose the ring state to users (even if it's just a "view" of the ring state from one
specific node I believe it's still nice).
> Of course that means storing information that may not be absolutely needed by the server,
but I'm not sure there is much harm to that.
> Note that doing this cleanly may require changing the schema of current system tables
but as long as we do that in the 1.2 timeframe it's ok (since the concerned system table 'local'
and 'peers' are news anyway).

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message