[
https://issues.apache.org/jira/browse/CASSANDRA-2805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13066059#comment-13066059
]
Gaurav Sharma commented on CASSANDRA-2805:
------------------------------------------
Based on my research so far scanning the MBean's and their internal users
(NodeProbe, NodeCmd and CliClient), there are 4 Cassandra-type dependencies:
CompactionInfo, CompactionType, Token, Range. Addressing them individually and
discussing my plan:
1. CompactionInfo/CompactionType
Now, CompactionInfo/CompactionType are manageable with a Map as suggested but
Range and Token are a bit tightly coupled and more involved.
2. Range
Since Range already has the partitioner (either injected or implicit from
StorageService), I believe I can add 2 new constructors that look like:
public Range(String left, String right)
public Range(String left, String right, IPartitioner partitioner)
and use the partioner.getTokenFactory().fromString() to curate the left and
right Token's.
Also, to replace the StorageServiceMBean's:
public Map<Range, List<String>> getRangeToEndpointMap(String keyspace);
public Map<Range, List<String>> getPendingRangeToEndpointMap(String
keyspace);
based on their usages, the Range in StorageService can be safely copied to
something like a Pair/Tuple.
I noticed that the getRangeToAddressMap() is not exposed on the
StorageServiceMBean interface - is that by design (not that I am complaining
because right now, it is 1 less dependency to decouple but if it is an
omission, I need to account for it)?
3. Token
I can change all MBean interfaces that need a Token to the corresponding String
representation using partitioner.getTokenFactory().toString() and then
reconstruct back using the fromString()
> Clean up mbeans that return Internal Cassandra types
> ----------------------------------------------------
>
> Key: CASSANDRA-2805
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2805
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 0.8.1
> Reporter: Nick Bailey
> Assignee: Gaurav Sharma
> Priority: Minor
> Labels: lhf
> Fix For: 0.8.2
>
>
> We need to clean up wherever we return internal cassandra objects over jmx.
> Namely CompactionInfo objects as well as Tokens. There may be a few other
> examples.
> This is bad for two reasons
> 1. You have to load the cassandra jar when querying these mbeans, which sucks.
> 2. Stuff breaks between versions when things are moved. For example,
> CASSANDRA-1610 moves the compaction related classes around. Any code querying
> those jmx mbeans in 0.8.0 is now broken in 0.8.2. (assuming those moves stay
> in the 0.8 branch)
> For things like CompactionInfo we should just expose more mbean methods or
> serialize to something standard like json.
> I'd like to target this for 0.8.2. Since we've already broken compatibility
> between 0.8.0 and 0.8.1, I'd say just fix this everywhere now.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
