Let’s start with the single responsibility principle from wikipedia:
In object-oriented programming, the single responsibility principle states that every class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class. All its servicesshould be narrowly aligned with that responsibility.
Enforce the single responsibility priniciple makes your code more readable and maintainable. In this article the goal is to go inside the Cassandra nodetool, and see how we can enforce this princple. For that we use JArchitect to understand how the nodetool works internally.
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
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.
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)
Let’s first discover the major nodetool components and how they work internally.
The nodetool classes exist in the org.apache.cassandra.tools package, and the entry class is NodeCmd.
NodeCmd
To understand the role of this class let’s search for methods called by 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. For that the NodeCmd collaborates with the NodeProbe class.
NodeProbe
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:
Refactor to enforce the responsibility principle
We discovered that NodeCmd parse the command line options and delegate the job to the NodeProbe class which is just a facade to the JMX beans, but what about NodeCmd class, it uses any JMX beans directly?
The NodeCmd uses the EndpointSnitchInfoMBean JMX bean, 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 }
Both 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:
To enforce the single responsibility principle it’s 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.