I created this, hope it fits your expectations
https://issues.apache.org/jira/browse/CASSANDRA-1068
patch is attached to the bug and ready for review
2010/5/7 Ted Zlatanov
> On Fri, 7 May 2010 09:24:40 +0200 gabriele renzi
> wrote:
>
> gr> On Thu, May 6, 2010 at 7:00 PM, Nathan McCall
> wrote:
Please Unsubscribe me from this list
2010/5/7 Ted Zlatanov
> On Fri, 7 May 2010 09:24:40 +0200 gabriele renzi
> wrote:
>
> gr> On Thu, May 6, 2010 at 7:00 PM, Nathan McCall
> wrote:
> >> FYI - I asked a similar question in #cassandra-dev yesterday (based on
> >> this message thread actually) a
On Fri, 7 May 2010 09:24:40 +0200 gabriele renzi wrote:
gr> On Thu, May 6, 2010 at 7:00 PM, Nathan McCall
wrote:
>> FYI - I asked a similar question in #cassandra-dev yesterday (based on
>> this message thread actually) and was directed to this issue:
>> https://issues.apache.org/jira/browse/C
On Thu, May 6, 2010 at 7:00 PM, Nathan McCall wrote:
> FYI - I asked a similar question in #cassandra-dev yesterday (based on
> this message thread actually) and was directed to this issue:
> https://issues.apache.org/jira/browse/CASSANDRA-754
Interesting, but it seems the objection is more on t
> In my very modest opinion, this is still clumsy (shouldn't we add this
> to CassandraDaemon in .avro too?)
> I believe it would be nice to have a stanza in the configuration where
> we just list implementations of a CassandraDaemon interface
> (start,stop,configure,destroy), try to load and start
On Thu, May 6, 2010 at 2:50 PM, Gary Dusbabek wrote:
> If there is enough interest in having this in trunk, I suggest this approach:
> 1) Make the CassandraDaemon.java changes, except modify it so that the
> adapter will only spin up if one of the mx4j classes is found in the
> classpath.
In my v
Works for me.
On Thu, May 6, 2010 at 08:18, Jonathan Ellis wrote:
> I'd rather just add a note somewhere saying "add the mx4j jars to your
> classpath to enable this" than ship the jars in contrib (which doesn't
> get included in the binary release, anyway).
>
> On Thu, May 6, 2010 at 7:50 AM, Ga
I'd rather just add a note somewhere saying "add the mx4j jars to your
classpath to enable this" than ship the jars in contrib (which doesn't
get included in the binary release, anyway).
On Thu, May 6, 2010 at 7:50 AM, Gary Dusbabek wrote:
> If there is enough interest in having this in trunk, I
If there is enough interest in having this in trunk, I suggest this approach:
1) Make the CassandraDaemon.java changes, except modify it so that the
adapter will only spin up if one of the mx4j classes is found in the
classpath.
2) Place the required mx4j jars in contrib. The license
(http://mx4j.
Thanks Gabriele, it's quite nice!
The code change is pretty small I would even say for simplicity it's better
to just commit that to the core. I'll paste the code below.
In main():
daemon.startJmxOverHttp();
And we have:
public void startJmxOverHttp()
{
try
On Wed, May 5, 2010 at 12:00 PM, Ran Tavory wrote:
> can you send it to me? I'll try to work from it.
I updated it to trunk, moved the code into a method and added a few
catch'es (before: in main() throws Exception) .
As you can see, once exception handling and imports are removed it's
about ten
can you send it to me? I'll try to work from it.
On Wed, May 5, 2010 at 12:25 PM, gabriele renzi wrote:
> On Tue, May 4, 2010 at 8:09 PM, Gary Dusbabek wrote:
>
> > I agree: there is a place for both types of solutions. contrib is
> > probably best place (for both).
> >
> > IMO: jetty > tomcat
On Tue, May 4, 2010 at 8:09 PM, Gary Dusbabek wrote:
> I agree: there is a place for both types of solutions. contrib is
> probably best place (for both).
>
> IMO: jetty > tomcat, especially from the point of embedding.
FWIW, I had a patch for cassandra that adds an http interface to JMX
using
One thing to note about the solution that we created with mondemand, it
requires no changes to cassandra, and it works on any long running java
process with jmx. We basically have a few pieces
1. a command line JMX client which does 2 things
a. dumps a config file with all available jmx stats
On Tue, May 4, 2010 at 13:05, Ran Tavory wrote:
> IMO there's a good case for both external monitoring tools and per-host
> minimalistic interface but I see Eric's point that every piece of code will
> require its maintenance. A cluster monitoring tool is definitely required.
> An embedded one has
Of course, it would very nice to have some tool out of the box.
For the 2nd point, an external tool can be fast enough to know what's
happening now. There could be a cluster monitoring part, and a
per-node monitoring interface, from the same tool. That was my goal at
least...
On Tue, May 4, 2010
IMO there's a good case for both external monitoring tools and per-host
minimalistic interface but I see Eric's point that every piece of code will
require its maintenance. A cluster monitoring tool is definitely required.
An embedded one has two nice properties:
1. It works out of the box
2. If I
Anthony, very nice to see this, this is exactly the kind of thing I've
started on a web UI!
I'll try to get more things done this week and post it somewhere for
those who are interested.
On Tue, May 4, 2010 at 2:49 PM, Anthony Molinaro
wrote:
> And just to show you what the dashboards look like
And just to show you what the dashboards look like here's a couple
of screen shots
Jconsole like page of jvm stats
http://herbie.ddv.com/~anthonym/mondemand-2.png
Cassandra specific memtable stats
http://herbie.ddv.com/~anthonym/mondemand-1.png
-Anthony
On Tue, May 04, 2010 at 10:03:52AM -0700,
On 5/4/2010 7:21 AM, Eric Evans wrote:
On Tue, 2010-05-04 at 08:41 +0300, Ran Tavory wrote:
How about the following compromise:
Add a simple web server to each node with only one simple servlet that
simply spits out all JMX stats on one page. Not fancy, no graphs,
simply the same values you can
Hi! I was working on a separate monitoring client, and not a per-node approach.
At the time, we talked on having a single server that queries the
nodes on a Cassandra cluster.
There's some discussions on the list, about technologies being used,
etc. I was pretty busy these last weeks (and some da
On Tue, 2010-05-04 at 08:41 +0300, Ran Tavory wrote:
> How about the following compromise:
> Add a simple web server to each node with only one simple servlet that
> simply spits out all JMX stats on one page. Not fancy, no graphs,
> simply the same values you can get from jconsole, but on a web pa
How about the following compromise:
Add a simple web server to each node with only one simple servlet that
simply spits out all JMX stats on one page. Not fancy, no graphs, simply the
same values you can get from jconsole, but on a web page.
To me it seems like a fair tradeoff b/w maintenance and e
For the record, I was just pointing #918 for the web admin gui part but
I totally agree and also think that a centralized management thingy is the
way to go.
On Mon, May 3, 2010 at 5:38 PM, Eric Evans wrote:
> On Mon, 2010-05-03 at 12:58 +0200, Sylvain Lebresne wrote:
>> https://issues.apache.org
On Mon, 2010-05-03 at 12:58 +0200, Sylvain Lebresne wrote:
> https://issues.apache.org/jira/browse/CASSANDRA-918
>
> Someone seems to be working on the idea. Don't know what's the status
> exactly.
#918 is to create a centralized, browser-based, management station,
(FWIW, I think this is The Way
That was one of our ill-fated gsoc projects. Pablo has indicated that
he is still interested in working on it, but I don't know what his
availability is.
I'm personally not in favor of the webserver-per-node approach, but I
do see its merits. For this reason I think that it would be good that
wh
https://issues.apache.org/jira/browse/CASSANDRA-918
Someone seems to be working on the idea. Don't know what's the status exactly.
On Mon, May 3, 2010 at 12:49 PM, Ran Tavory wrote:
> I'd be happy to get a management web interface on each cassandra node so i
> can easily (and visually) see what'
27 matches
Mail list logo
