Lahlali Issam

Subscribe to Lahlali Issam: eMailAlertsEmail Alerts
Get Lahlali Issam via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Cassandra Nodetool Internals

Let's go inside the cassandra nodetool utility.

Relational database management systems are the most commonly used system to store and use data, but for extremely large amounts of data, this kind of system doesn’t scale up properly.

The concept of "NoSQL"(Not Only SQL) has been spreading due to the growing demand for relational database alternatives. The biggest motivation behind NoSQL is scalability. NoSQL solutions can offer a way to store and use extremely large amounts of data, but with less overhead, less work, better performance, and less downtime.

Apache Cassandra implements the “NoSQL” concept. It was developed at Facebook to power their Inbox Search feature, and it became an Apache open source project. Twitter, Digg, Reddit and quite a few others started using it invo

Cassandra exposes a number of management operations via Java Management Extensions (JMX). Java Management Extensions (JMX) is a Java technology that supplies tools for managing and monitoring Java applications and services. Any statistic or operation that a Java application has exposed as an MBean can then be monitored or manipulated using JMX.

In this article the goal is to go inside Cassandra nodetool, and see how easy it would be to extend it or build a Cassandra monitoring UI. For that we use JArchitect to understand how the nodetool works internally.

The nodetool utility is a command line interface for Cassandra. You can use it to help manage a cluster. It’s used like this nodetool -h HOSTNAME [-p JMX_PORT] COMMAND
Here are some available commands:

  ring                   - Print informations on the token ring
  join                   - Join the ring
  info                   - Print node informations (uptime, load, ...)
  cfstats                - Print statistics on column families
  clearsnapshot          - Remove all existing snapshots
  version                - Print cassandra version
  tpstats                - Print usage statistics of thread pools
  drain                  - Drain the node (stop accepting writes and flush all column families)

The nodetool classes exist in the org.apache.cassandra.tools package, and the entry class is NodeCmd.


Let’s search for methods invoked from the main method from the NodeCmd class by executing the following CQLinq query:

from m in Methods where m.IsUsedBy ("org.apache.cassandra.tools.NodeCmd.main(String[])")
select new { m, m.NbBCInstructions }


To treat commands, the main method uses the Apache Commons CLI library which provides an API for parsing command line options. It's also able to print help messages of all the options available.

For each command the NodeCmd switch to the appropriate method to do the job. And the NodeCmd collaborates with the NodeProbe class.


Let’s discover how NodeProbe achieve its task, for that we can search for all types used by it.

from t in Types where t.IsUsedBy ("org.apache.cassandra.tools.NodeProbe")
select new { t }


The NodeProbe class uses mainly the management beans; it acts as a facade and redirects each command to the appropriate JMX bean.

Here is the list of all Cassandra JMX beans:

from t in Types
where t.NameLike (@"mbean\i") && t.IsInterface 
select  t


Many managed beans are available which gives the possibility to create tools exploiting their capabilities, to help administrators monitor and manage the Cassandra cluster.

The idea of such tools is to interact with the JMX beans and invoke some of their methods, for that we need to create a JMX proxy by invoking JMX.newMBeanProxy.

Let’s search for methods which create a JMX proxy.

from m in Methods where m.IsUsing ("javax.management.JMX.newMBeanProxy(MBeanServerConnection,ObjectName,Class)")
select new { m, m.NbBCInstructions }


The NodeProbe which acts as a facade create these proxies, we can take as example the connect method which is invoked to create these proxies, and discover some methods invoked by it.


After the creation of proxies, all the commands will be just a redirection, for example let’s search for methods used by NodeProbe.forceRemoveCompletion.

from m in Methods where m.IsUsedBy ("org.apache.cassandra.tools.NodeProbe.forceRemoveCompletion()")
select new { m, m.NbBCInstructions }


Only the StorageServiceMBean.forceRemoveCompletion is used, all the logic of the treatment is in the server side. TheStorageServiceMBean is implemented by the StorageService class and here are all methods used by the StoageService. forceRemoveCompletion method:


Possible Design improvement

We discovered that NodeProbe is just a facade to the JMX beans, but what about NodeCmd class, it uses any JMX beans directly?

As shown before NodeCmd not create any JMX proxy, the creation of all the proxies is achieved by the NodeProbe. So we can conclude that all JMX beans invoking are from the NodeProbe class, and the responsibility of the NodeCmd class is just to treat the command line and ask the NodeProbe class to do the job. And to check that let’s search for JMX beans used directly by the NodeCmd class.

from t in Types where t.IsUsedBy ("org.apache.cassandra.tools.NodeCmd") && t.NameLike (@"mbean\i") 
select  t


The NodeCmd uses also some JMX beans like EndpointSnitchInfoMBean, and here are all the methods using this bean.

from m in Methods where m.IsUsing ("org.apache.cassandra.locator.EndpointSnitchInfoMBean")
select new { m, m.NbBCInstructions }


NodeCmd and NodeProbe use it, the NodeCmd doesn’t have the proxy but ask it from the NodeProbe class as shown in this dependency graph:


Maybe it will be better to refactor the nodetool and let only NodeProbe redirect commands to the JMX proxies, and acts as the only facade to the management capabilities, and the responsibility of the NodeCmd will be only the parsing of the command line and redirect to the NodeProbe class. Only a few commands are treated directly from the NodeCmd class and delegate this task to the NodeProbe is not a difficult task.

Cassandra expose many management capabilities thought JMX beans, and not all of them are treated by the nodetool utility, it’s very easy to add other commands to it, we can just take as example the already existing commands and add your own. Building administrator tools is also easy, because all the logic is in the Cassandra server side, you have just to develop a nice GUI and interact with the JMX beans. If you want to develop your own administration tool, the nodetool is a good beginning; understanding how it works will facilitate a lot your task.

More Stories By Lahlali Issam

Lahlali Issam Lead Developer at JavaDepend, a tool to manage and understand complex Java code. With JavaDepend, software quality can be measured using Code Metrics, visualized using Graphs and Treemaps, and queried using CQL language, a SQL like to query the code base.