Mailing-List: contact cassandra-commits-help@incubator.apache.org;
 run by ezmlm
Precedence: bulk
Reply-To: cassandra-dev@incubator.apache.org
Message-ID: <97727022.249741263512335224.JavaMail.jira@brutus.apache.org>
Date: Thu, 14 Jan 2010 23:38:55 +0000 (UTC)
From: "Eric Evans (JIRA)" <jira@apache.org>
To: cassandra-commits@incubator.apache.org
Subject: [jira] Commented: (CASSANDRA-698) ClusterProbe
In-Reply-To: <209322085.229411263431814440.JavaMail.jira@brutus.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CASSANDRA-698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12800425#action_12800425 ] 

Eric Evans commented on CASSANDRA-698:
--------------------------------------

I probably didn't explain well.

IMO, NodeProbe is a mess, because if it isn't the general purpose JMX client for nodes (and nothing else fills that role), then I see a future with a lot of overlap/duplication (like I can already see happening with ClusterProbe). But, feature creep has convoluted NodeProbe into an operations oriented console application. 

So what I'm suggesting is that maybe we could push getEndPoints(key) into NodeProbe, where the more cluster-specific tool you're after could make use of it, and likewise, the parts of NodeProbe that are there to contribute to "an operations oriented console application", could be broken out into something separate as well (and I can do this if you want).

In other words, what I'm suggesting shouldn't be at odds with your goals.

> ClusterProbe
> ------------
>
>                 Key: CASSANDRA-698
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-698
>             Project: Cassandra
>          Issue Type: New Feature
>    Affects Versions: 0.9
>            Reporter: Chris Goffinet
>            Assignee: Chris Goffinet
>            Priority: Minor
>             Fix For: 0.9
>
>         Attachments: 0001-Added-ClusterProbe.-Supports-get_endpoints-key.patch
>
>
> I'd like to introduce ClusterProbe, for situations where you want to find information at cluster level. The first operation is get_endpoints, where you can supply a key. I want to also add support for showing hit ratio for column families at cluster level.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.