Masaryk University Faculty of Informatics
JGgroups Configurator and Visualiser
Master’s Thesis
Bc. Michal Sorentíny
Brno, Spring 2017 Replace this page with a copy of the official signed thesis assignment and the copy of the Statement of an Author. Declaration
Hereby I declare that this paper is my original authorial work, which I have worked out by my own. All sources, references and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source.
Bc. Michal Sorentíny
Advisor: RNDr. Adam Rambousek, Phd.
i Acknowledgement
I would like to thank to both of my advisors RNDr. Adam Rambousek, Phd. and Mgr. Radim Vansa for valuable feedback during all hard times I had writing this thesis.
ii Abstract
JGroups is a messaging toolkit for reliable multicast communication. The diploma thesis analyzes possibilities of convenient configuration and visualization of JGroups clusters and describes creating a con- figurator and visual probe tool with ability to retrieve or change cur- rent configuration, state and statistics of running cluster in a graphical user interface.
iii Keywords
JGroups, Java, Probe, Cluster, IP Multicast
iv Contents
1 Introduction ...... 1 2 Problem Analysis ...... 2 2.1 Terminology ...... 2 2.1.1 Cluster ...... 2 2.1.2 Node ...... 2 2.1.3 IP multicasting ...... 3 2.1.4 JMX ...... 4 2.1.5 Network reliability ...... 4 2.2 Clustering applications ...... 6 2.3 JGroups ...... 7 2.3.1 Current configuration and visualization options8 3 Problem Definition ...... 11 3.1 Stack Overflow research ...... 11 3.2 Use Cases ...... 11 3.2.1 Use case 1 ...... 12 3.2.2 Use case 2 ...... 12 3.2.3 Use case 3 ...... 13 3.2.4 Use case 4 ...... 13 3.2.5 Use case 5 ...... 13 4 Possible Solutions ...... 16 4.1 Using JChannel ...... 16 4.2 Using JMX ...... 17 4.3 Utilizing existing ProbeHandler implementations ...... 17 5 Justification of Selected Solution ...... 19 6 Description of the Solution ...... 22 6.1 Graphical User Interface ...... 22 Header field group ...... 22 Information tab ...... 22 Configuration tab ...... 22 Monitoring tab ...... 23 6.2 Controllers ...... 23 6.2.1 ClusterExplorer interface ...... 23 JChannelClusterExplorer ...... 24 ProbeClusterExplorer ...... 25 6.2.2 ClusterBuilder interface ...... 25
v void updateProtocol(Address node, Protocol protocol) 25 6.3 Utility classes ...... 26 6.3.1 ProtocolFactory ...... 26 7 Conclusion ...... 31 7.1 Evaluation of the Results ...... 31 7.1.1 Development process ...... 31 Requirements ...... 31 Design ...... 31 Implementation ...... 32 Verification ...... 32 Maintenance ...... 32 7.1.2 Used tools ...... 33 7.1.3 Lessons learned ...... 33 7.2 Possible Further Improvements ...... 34 A JGroups configuration for Infinispan distributed cache .. 38
vi List of Figures
2.1 Cluster Architecture [12] 3 2.2 JMX architecture[6] 5 2.3 The JGroups architecture [2] 8 2.4 Example of graphical cluster visualization using Clusplot [4] 9 3.1 Stack Overflow questions 12 3.2 Stack Overflow related tags 14 3.3 Use case diagram 15 6.1 Class diagram 27 6.2 Information tab 28 6.3 Configuration tab 29 6.4 Monitoring tab 30
vii 1 Introduction
High availability of cheap microprocessors, high-speed networks and increasing need of higher computing power gave foundations to com- puter clustering. With computer clustering we can connect multiple computers or programs so that they can act as a single system. This is widely used in high availability systems and distributed computing. This thesis is aimed at JGroups – an open source Java framework that enables user to simply implement clustering functionality in it’s software. Jgroups is a great tool, however it’s configuration can be quite cumbersome in some situations. There is no graphical user in- terface that would guide the user through the cluster configuration or pointed at problems in configuration. The resulting application is called Jgroups-conf 1. It is published under the MIT License2 on GitHub.3 Second chapter contains a glossary of used terms, a brief analysis of the given problem, current clustering options and introduces the JGroups framework. Third chapter, the Problem Definition will describe the current sit- uation of the problem and how does it affect the end users. It identi- fies the use cases for different roles of the users. In the fourth chapter three possible solutions are be described and analyzed. Fifth chapter will include the list of features and the justification of the selected solution for each of the features. It’s detailed description and analysis will be included in the sixth chapter with the list of methods and screen shots of the actual appli- cation. Seventh chapter concludes the achieved result, evaluates proce- dures how were the results achieved and suggests further improve- ments of the developed application.
1. Further referenced only as application 2. https://opensource.org/licenses/MIT 3. https://github.com/Myhall/JGroups-conf
1 2 Problem Analysis
2.1 Terminology
To properly understand the problem we will first have a look at basic terms necessary to understand the topic.
2.1.1 Cluster
Cluster or often known as clustering, a group of nodes that operate independently and work closely with each other to be governed by a master computer (master node, coordinator) and will be seen by the user as if the computer is connected a computer unit.[1] Clustering is the practice of connecting multiple processors or servers using a high-speed interconnect such as InfiniBandTM to cooperate on com- plex workloads as a single, unified computing resource.[[8] Cluster consists of a set of loosely or tightly connected nodes that work to- gether so that they can be viewed as a single system.[13] Today, clusters are widely used for research and development of science, engineering, commerce and industry applications that de- mand high performance computations. In addition, clusters encom- pass strengths such as high availability and scalability that motivate wide usage in nonsupercomputing applications as well, such as clus- ters working as web and database servers.[12] The typical architec- ture of a cluster is shown in figure 2.1. Terms cluster and group are interchangeable in further context.
2.1.2 Node
The computer clustering approach usually (but not always) connects a number of readily available computing nodes (e.g. personal com- puters used as servers) via a fast local area network. The activities of the computing nodes are orchestrated by "clustering middleware", a software layer that sits atop the nodes and allows the users to treat the cluster as by and large one cohesive computing unit, e.g. via a single system image concept. [7]
2 2. Problem Analysis
Figure 2.1: Cluster Architecture [12]
Cluster node is a single participant of the cluster, can be either a single hardware computer, a virtual machine or even a single soft- ware application. The node term is interchangable with the term mem- ber.
2.1.3 IP multicasting
IP multicasting is the transmission of an IP datagram to a "host group", a set of zero or more hosts identified by a single IP destination ad- dress. A multicast datagram is delivered to all members of its desti- nation host group with the same "best-efforts" reliability as regular unicast IP datagrams, i.e., the datagram is not guaranteed to arrive intact at all members of the destination group or in the same order relative to other datagrams. The membership of a host group is dynamic; that is, hosts may join and leave groups at any time. There is no restric tion on the location or number of members in a host group. A host may be a member of more than one group at a time. A host need not be a member of a group to send datagrams to it.[5]
3 2. Problem Analysis
2.1.4 JMX The Java Management Extensions (JMX) API is a standard API for management and monitoring of resources such as applications, de- vices, services, and the Java virtual machine. The JMX technology was developed through the Java Community Process (JCP) as Java Speci- fication Request (JSR) 3, Java Management Extensions1, and JSR 160, JMX Remote API2. Typical uses of the JMX technology include: ∙ Consulting and changing application configuration ∙ Accumulating statistics about application behavior and mak- ing them available ∙ Notifying of state changes and erroneous conditions. The JMX API includes remote access, so a remote management program can interact with a running application for these purposes. Fundamental concept of JMX are Managed Beans, or MBeans. An MBean is a managed Java object, similar to a JavaBeans component, that follows the design patterns set forth in the JMX specification. An MBean can represent a device, an application, or any resource that needs to be managed. MBeans expose a management interface that consists of a set of readable or writable attributes (or both), a set of invokable operations and a self-description.[11] The architecture of JMX is displayed in figure 2.1.4.
2.1.5 Network reliability As a reliable network protocol is considered a protocol that provides features for ensuring reliability in delivery of the data to the intended recipients. Main reliability properties are: ∙ Acknowledgment - user is notified if the delivery fails (nega- tive acknowledgment) or after receiving every packet (positive acknowledgement) ∙ Delivery guarantee - protocol guarantees data delivery to in- tended recipients
1. JSR 3: https://www.jcp.org/en/jsr/detail?id=3 2. JSR 160: https://www.jcp.org/en/jsr/detail?id=160
4 2. Problem Analysis
Figure 2.2: JMX architecture[6]
∙ Last copy recall - as long as at least a single copy of a message remains available at any of the recipients, every other recipient that does not fail eventually also receives a copy
∙ Atomicity is stronger than the last copy recall. It means that each message is always delivered to either all or none of the recipients.
∙ Virtual synchrony is not based on transactions, but introduces a similar approach. In the virtual synchrony model, the simpli- fying abstraction seen by the developer is that of a set of pro- cesses (the group members) which all see the same events in the same order.[3]
5 2. Problem Analysis 2.2 Clustering applications
User has currently several options when choosing a Java framework that would use clustering in his application. Most of them also of- fer enhanced functions like transactions, events, querying and dis- tributed processing. Let’s mention few of them: ∙ Terracotta3 (open source, based on Mozilla Public License); ∙ Oracle Coherence4 (commercial); Formerly Tangosol Coherence. Based on JSR 107, which was never adopted officially; ∙ GigaSpaces5 (commercial); Based on JavaSpaces API, part of Jini; ∙ GridGain6 (open source: LGPL); ∙ memcached7 with a Java client library (open source: BSD Li- cense); Implementation of memcached on top of JGroups can be accessed directly from JGroups project web site.8 ∙ EHCache9 (open source: Apache Software License); It can use JGroups as the underlying mechanism for the replication op- erations. ∙ OSCache (open source: modified Apache License); Uses JGroups for clustering. Opensymphony – company developing the project has quit. It’s source code can be accessed on Google Code page.10 ∙ Infinispan11 (open source, Apache License 2.0); A distributed in-memory key/value data store with optional schema. It uses JGroups for network communications when in clustered mode.
3. https://www.terracotta.org/ 4. https://www.oracle.com/middleware/coherence/index.html 5. http://www.gigaspaces.com/ 6. http://www.gridgain.com/ 7. https://memcached.org/ 8. http://www.jgroups.org/memcached/memcached.html 9. http://www.ehcache.org/ 10. https://code.google.com/archive/p/opensymphony-oscache-backup/ 11. http://infinispan.org/
6 2. Problem Analysis 2.3 JGroups
The nature of the clusters - nodes being connected by network implies the main problem in their communication - reliability. Data transfer over the network is unreliable due to various environment conditions. JGroups12 itself is a toolkit for reliable messaging in the cluster. It can be used to create clusters whose nodes can send messages to each other.[10] The main features include: ∙ Cluster creation and deletion. Cluster nodes can be spread across LANs or WANs
∙ Joining and leaving of clusters
∙ Membership detection and notification about joining, leaving or crashing of cluster nodes
∙ Detection and removal of crashed nodes
∙ Sending and receiving of node-to-cluster messages (point-to- multipoint)
∙ Sending and receiving of node-to-node messages (point-to- point) Nodes are processes residing on some hosts. There is no limit of nodes per host, except for physical limits of host’s hardware re- sources. One host can also run members of different clusters and one node can also belong to multiple groups. The JGroups architecture is shown in the figure 2.3. Application on top is connected either directly with the JChannel, or it can make use of the Building blocks, if higher-level abstraction is desired. Un- derneath the JChannel is the layer of protocols:
∙ GMS - a group membership protocol which handles joins, leaves and crashes (suspicions) and emits new views accordingly
∙ MERGE - a protocol for discovering subgroups and for joining subgroups back together
12. Short for Java Groups
7 2. Problem Analysis
∙ FRAG - a fragmentation layer, splits messages longer than pre- defined size and reassembles fragmented packets back together
∙ UDP / TCP - a transport protocol layer directly communicating with the network
Figure 2.3: The JGroups architecture [2]
2.3.1 Current configuration and visualization options As mentioned earlier, the current options of configuring the cluster as a whole and it’s individual nodes are limited. The typical work- flow consists of deploying an application using one of default con- figurations distributed with the JGroups, adjusting and tweaking it afterwards. An administrator often runs into problems with running a cluster and is dependent on cumbersome debugging of individual
8 2. Problem Analysis
nodes using the Probe tool. Worst case scenario includes doing huge changes or even rewriting completely the cluster configuration XML. Current options of getting a cluster members representation are limited. One of them is a textual list of the cluster view members that is kept by every node. Even using external tools for cluster visualiza- tion does not make a configuration of individual nodes any easier. The typical cluster visualization tool produces a 2D graph depicting nodes in clusters - please see the figure 2.3.1.
Figure 2.4: Example of graphical cluster visualization using Clusplot [4]
Such plot is useful to get a complex image of a cluster members and node relationships, however especially for large clusters, the plot
9 2. Problem Analysis becomes unreadable what diminishes it’s helpfulness by cluster con- figuration and it disqualifies itself for the use in this application.
10 3 Problem Definition
3.1 Stack Overflow research
To find out main problems that are users dealing with, I have browsed the Stack Owerflow1 web page, looking for the JGroups keyword and conducted a research of submitted questions. Stack Overflow contains 211 questions related to JGroups -based on a tagging system. 133 of them are answered or solved. Research shows that even though the amount of questions is relatively small, the community is live and the resolve rate is 63%. The tagging sys- tem statistics show that mostly used tags are java, infinispan, cluster- computing, jboss and others - please see the figure 3.2. Analyzing the related tags shows that main areas of struggle are with implementa- tion and clustering own application using JGroups (the java tag). The rest of the related tags point to problems with clustering of tools which are using JGroups internally (infinispan, ehcache, hybernate- search) and clustering in commercially available environments (amazon- ec2). Most users struggle with the configuration of their clusters and with detecting the problems in their configuration. It is often hard to find out why did nodes not form a cluster or figuring out problems with multicast. Currently there are not available any tools with user friendly graph- ical user interface (GUI) that would help user with cluster configura- tion and troubleshooting.
3.2 Use Cases
I have transformed the identified problems into following use cases for the intended users of my application:
1. www.stackowerflow.com
11 3. Problem Definition
Figure 3.1: Stack Overflow questions
3.2.1 Use case 1
As a cluster administrator, I want to be able to discover clusters run- ning in my local network and easily connect and work with them. This is mainly a convenience feature, since typical cluster admin- istrator should know what clusters are running in his network, how- ever cluster names can sometimes be cumbersome, especially if they are created by automated tools. The discovery can also be used as a diagnostic feature in situations were nodes refuse to form a cluster because of a typo in configuring a cluster name when running nodes manually.
3.2.2 Use case 2
As a clustered application user, I want to be able to view real-time statistics of the running cluster. Cluster monitoring is a part of the assignment and it is a handy tool for various users and situations. In case a certain node suffers from instability or when an administrator deploys a new cluster, needs the monitoring to reveal any problems.
12 3. Problem Definition
3.2.3 Use case 3 As a clustered application user, I want to inspect and change protocol stack configuration of individual nodes of the cluster. Using a CLI of a Probe tool is very intricate. Especially when work- ing with a large cluster, finding necessary information in a long print- out in command line is difficult. Hence there is a need for convenient access to individual nodes and their configuration.
3.2.4 Use case 4 As a cluster administrator, I want to have a validation of attributes of the protocols. Protocol behavior can vary according to many properties. These properties are of various types and are measured in various units - from boolean values through bytes to seconds. Hence there is a need of validating that a user enters correct values.
3.2.5 Use case 5 As a cluster administrator, I want to have a visual indication of at- tributes having different values from its original settings. This use case is based on the same reason as previous use case – protocols having high number of attributes – most of them with de- fault values. A user will With this feature be able to quickly recognize attributes that have been altered to help with troubleshooting and di- agnostics. Goal of this thesis is to create a tool that would make the JGroups cluster configuration easy and convenient and it would help the user with solving problems of the cluster configuration.
13 3. Problem Definition
Figure 3.2: Stack Overflow related tags
14 3. Problem Definition
Figure 3.3: Use case diagram
15 4 Possible Solutions
Configuration of a JGroups cluster is mainly done by writing thecon- figuration XML file with the protocols and it’s attributes and proper- ties. Writing such an extensive XML file is very inconvenient and error prone. In the time of writing this thesis were even some of the XSD schemes describing the JGroups protocol stack invalid. An example XML configuration file taken from Infinispan project can be foundin the attachment A. Even if user already has the configuration XML file complete, valid and deployed on the nodes of the cluster, some nodes can require different values of certain attributes. There is one existing tool for exploring cluster configuration, po- tentially altering certain settings. It is part of the JGroups and it’s called Probe. Probe is the Swiss Army Knife for JGroups; it allows to fetch information about the members running in a cluster, get and set properties of the various protocols, and invoke methods in all cluster members. Probe can even insert protocols into running cluster mem- bers, or remove or replace existing protocols.[10] Probe is included in standard JGroups jar file. Using Probe for configuring the cluster is possible, however it ex- ists only as a command line script (probe.sh1) which requires exten- sive knowledge about the cluster and about JGroups generally. As the solution I have chosen to create a GUI application that will be ran locally and which will be able to connect to the running clus- ter, inspect it’s nodes and their configuration. It will be able to alter any node’s configuration, even change the configuration of the whole cluster. Application will also show statistics from various protocols in a convenient way.
4.1 Using JChannel
The first possible solution is also the most convenient one. It utilizes org.jgroups.JChannel class as the main entry point to the cluster. JChannel contains all neccessary methods to explore the cluster nodes,
1. Also version for Windows is available - probe.bat
16 4. Possible Solutions
it’s protocol stack and also for communication with other group mem- bers. The main disadvantage of this approach is that the JGroups_conf application connected by JChannel becomes one of the nodes of the cluster. Every member can see the application in the View. This may not be a problem for certain cluster applications, however it can cause problems if the JGroups_conf runs different protocol stack than the rest of the members, eventually if applications on the other nodes ex- pect certain behavior from every group member. After consulting with the technical advisor, this solution has been dismissed, however the source code does still contain the JChannel- ClusterExplorer class and can be used. See the chapter 6.2.1 for more details.
4.2 Using JMX
All JGroups protocol classes already contain annotations exposing it’s attributes and operations for the JMX framework in form of the MBean.2 The annotations can be found in org.jgroups.annotations package, they are MBean, ManagedAttribute and ManagedOperation. Direct usage of JMX is a straightforward solution, taking advatage of a mature API present in Java since Java 5. The idea is to create a Spe- cific Console as shown in figure 2.1.4 Disadvantage of this solution is limited added value, since man- aging MBeans is already possible with standard Java tool called JCon- sole.3 It already contains an exhaustive set of options for managing not only attributes and operations in protocol classes but also all JVM attributes including a memory consumption and a processor usage of the process.
4.3 Utilizing existing ProbeHandler implementations
This approach makes use of the fact that JGroups protocols are listen- ing for commands via network. Every stack has an additional multi-
2. See the section 2.1.4 3. http://docs.oracle.com/javase/8/docs/technotes/guides/management/jconsole.html
17 4. Possible Solutions
cast socket that by default listens on 224.0.75.75:7500 for diagnostics requests from the Probe. Sadly, the org.jgroups.test.Probe class is written in a not very extensible way, so simple use of it was not possible without propagat- ing the changes into the JGroups source code. However mimicking the actions of Probe can be performed. This approach can be used for discovering reachable clusters, re- trieve real-time statistics for every protocol, alter configuration of in- dividual nodes and even changing the protocol stack of the group members.
18 5 Justification of Selected Solution
Choosing the solution has been based on the identified use cases. Main features of the application will provide convenient solutions to every use case. Find the following list of the features with the justifi- cation of each solution. ∙ Application will be written in Java Justification: JGroups itself is a Java framework. Although one .NET port - The Group Communication Toolkit (GCT) 1 does exist, vast majority of users rely on it’s Java implementation. Application will be compatible with the latest Java release (Java 8 at the time of writing this thesis). It is based on Jgroups v. 4.0.0, however recompiling with a newer version in the future should preserve all functionality smoothly. Java is great be- cause of it’s multi-platform spread. It allows future application users to use it in any environment and on any platform. ∙ Application will use Java Swing as a GUI framework Justification: Typical user wants to run the application locally on the PC connected to the network with the cluster. Therefore there is no need to build web-based interface running on the server. Swing has been chosen because it is a stable part of the Java standard library and it offers the flexibility and features required for the project. Also I (the implementator) have more experience with swing than with the JavaFX 2. ∙ Application will be able to discover clusters using IP multi- cast Justification: This feature is linked with the use case 1. It relies on the fact, that every cluster stack has an additional multi- cast socket. By default it listens on 224.0.75.75:7500 in case of IPv4, or on ff0e::0:75:75 in case of IPv6. By sending a re- quest to one of these addresses and listening for answers, ap- plication can identify all clusters running in the local network.
1. The Group Communication Toolkit 2. JavaFX
19 5. Justification of Selected Solution
It receives response from every node of every cluster. In order for this feature to be effective, IP multicasting has to be enabled in the network.
∙ Application will have a cluster monitoring module Justification: As described in the second use case, the applica- tion shall have the monitoring module for exploring the real- time statistics of the running clusters. Every node acts as an individual inside the cluster with it’s own configuration. Since the protocol stack consists of multiple protocols with different responsibilities it is important to be able to filter the statistics for the individual nodes and respective protocols.
∙ Application will have a cluster configuration module Justification: The third use case corresponds with the main goal of the application to provide the convenient way of configura- tion of cluster node’s protocol stack. As mentioned above, con- figuration can be slightly different for each node of the cluster so it is important to differentiate between cluster nodes and set the configuration properly for each of them.
∙ Cluster configuration module will visually indicate changes of attribute values from default values Justification: The fifth use case demands the application topro- vide visual clues of the attribute changes. The application im- plements this use case by highlighting the background and changing font of rows containing affected attributes.
∙ Cluster configuration module will validate configuration at- tributes Justification: As stated in the thesis assignment, configuring a cluster by writing the XML file can be quite cumbersome and prone for errors. Therefore the application will contain both a text description of the properties implemented by tooltips and a basic validation of attribute values which will help adminis- trators avoid the sub-optimal settings.
20 5. Justification of Selected Solution
∙ The application will be able to load and save the node con- figuration from / to the file Justification: All nodes in cluster require the same or at least similar setup of the protocol stack. Since the protocol stack can be extensive and it can have many customized attributes, it is important to be able to save the configuration for later use. It is equally important to be able to load the configuration in a single step and distribute it over the cluster nodes. The appli- cation will produce the XML props file that can be later used by any JGroups instance.
21 6 Description of the Solution
The core of the application consists of two interfaces: ClusterExplor- er and ClusterBuilder. Application GUI consists of the main win- dow - JGConfForm. JGConfForm uses both interfaces as a Controllers for observing and manipulating the cluster. The UI features are de- livered by standard controls like JTable, JTree with customized ed- itors, renderers and models. The application shall be run by the JGConf.java, where a main method suits as a dependency injector for JGConfForm by setting an implementation of a ClusterBuilder and ClusterExplorer - see the class diagram.
6.1 Graphical User Interface
JGConfForm consists of header field group and three tabs: Informa- tion, Configuration and Monitoring.
Header field group Contains controls for loading a node configuration XML file and con- necting to specified cluster. The Discover button runs cluster discov- ery service. It’s results are filled in the clusterNameComboBox;
Information tab This tab displays raw information about the cluster retrieved by the ProbeClusterExplorer instance. It contains raw text representing the View and the JMX properties of the cluster. The contents of the tab correspond to the command line printout of the Probe tool commands.
Configuration tab Configuration tab is divided into three columns. The first column contains the JTable with the list of nodes which are currently con- nected to the cluster. This solution has proven to be the best alterna- tive for implementing the third use case. The simplicity brought by a
22 6. Description of the Solution list view of connected nodes also suites for visually representing the amount of members and easy access to each member’s configuration. Second column is designated for protocols of the currently se- lected node. They can be added from the protocolComboBox and are displayed in the JTree control. The protocolComboBox sources data from inner protocol list contained in the ProtocolFactory class. Each protocol’s attributes can be subsequently edited. Third column serves for editing currently selected protocol’s at- tributes. For this purpose serves the JTable. One attribute per row, each contains a tooltip that displays a description of the attribute. If the attribute has been changed from it’s initial value, the row changes it’s color to yellow to indicate the change. The table also provides val- idation of entered values, visual notification of changed value (high- lighted rows) and a reference description for each attribute in form of a tool tip - see the screen shot.
Monitoring tab The monitoring tab’s GUI is very similar to the Configuration tab. It also consists of three columns - displaying the nodes list, protocols and protocol attributes. Main difference is it can not be used to add or remove protocols running on selected node, nor does it provide any validation. The view of the monitoring tab is however constantly updated so it better fits for the visualization and monitoring of the cluster.
6.2 Controllers
The application is an open-source solution and the thesis alongside serves as a brief documentation of the code and it’s purpose. Below follows a brief description of crucial code parts for anyone who would like to further enhance the code.
6.2.1 ClusterExplorer interface com.sorentiny.jgroups_conf.ClusterExplorer interface serves as main controller to examine the properties and settings of the clusters.
23 6. Description of the Solution
It’s methods are then used by the GUI to display values. It contains following methods:
Collection
String getClusterPropertiesString() Returns String represen- tation of all properties of currently connected cluster.
String getProtocolStackXML() Returns String XML representa- tion of protocol stack.
List
getClusterView(String clusterName) Gets the List of Address classes representing the View of the cluster specified in the clusterName parameter. Typically the first Address in the list is the cluster coordinator.Map
JChannelClusterExplorer Implementation of the ClusterExplorer interface that takes advan- tage of org.jgroups.Channel.JChannel class. It connects to the clus- ter using the JChannel.connect() method. The Class also implements the ClusterBuilder interface, so it is also used for cluster manipula- tion.
24 6. Description of the Solution
The class is not directly used in the final version of the applica- tion since it has a major disadvantage. After connecting to the cluster using the JChannel, it acts as another node of the cluster. Some clus- ters or applications that rely on certain behavior of their nodes have problems if nodes are inactive or irresponsive.
ProbeClusterExplorer case Primary implementation of the ClusterExplorer interface. It’s major functionality is delivered by mirroring the org.jgroups.test. Probe class behavior. Communication with clusters is maintained us- ing IP multicasting, eventually with every node Address specifically. Connection is not maintained permanently but it is rather initiated with every call.
6.2.2 ClusterBuilder interface com.sorentiny.jgroups_conf.ClusterBuilder interface is the main entry point for creating and altering a cluster configuration. Interface methods can be used to add or delete protocols from the protocol stack or alter their attributes. The methods in the interface are:
void addProtocol(Address node, Protocol protocol) Adds the protocol specified in protocol parameter to the protocol stack run- ning on node specified by the node parameter. If the node parameter is null, the protocol is added to all nodes in the cluster.
void removeProtocol(Address node, Protocol protocol) Removes the protocol specified in protocol parameter from the pro- tocol stack running on node specified by the node parameter. If the node parameter is null, the protocol is removed from all nodes in the cluster.
void updateProtocol(Address node, Protocol protocol) Updates the protocol specified in protocol parameter from the pro- tocol stack running on node specified by the node parameter. If the node parameter is null, the protocol is updated on all nodes in the cluster.
25 6. Description of the Solution 6.3 Utility classes
6.3.1 ProtocolFactory com.sorentiny.jgroups_conf.ProtocolFactory is a helper class con- taining list of all Protocol available by default in JGroups distribu- tion. The lists are composed by the purpose of the protocols to follow- ing categories:
∙ Transport protocols
∙ Membership Discovery protocols
∙ Merging protocols
∙ Failure detection protocols
∙ Reliable Messaging protocols
∙ Message Stability protocols
∙ Group Membership protocols
∙ Flow Control protocols
∙ Fragmentation protocols
∙ Ordering protocols
∙ State Transfer protocols
∙ Locking protocols
∙ Misc protocols
public static
26 6. Description of the Solution
Figure 6.1: Class diagram
27 6. Description of the Solution
Figure 6.2: Information tab
28 6. Description of the Solution
Figure 6.3: Configuration tab
29 6. Description of the Solution
Figure 6.4: Monitoring tab
30 7 Conclusion
7.1 Evaluation of the Results
The Jgroups-conf application successfully fulfills all of the use cases listed in the chapter 3.2. Application is able to discover clusters running in the local net- work and easily start working with selected cluster. It shows real-time traffic statistics for every cluster node and validates attribute values entered by user. Application also indicates modified attributes so that the user can easily distinguish important configuration aspects for various nodes.
7.1.1 Development process The development of the application took advantage of a Waterfall software development process. Reasons for taking this approach are that the project is fairly small and taking on full incremental process with full testing and evaluation after every prototype would be very time-consuming and would require a great deal of excess documen- tation which would be an overkill for a small open-source project.
Requirements The requirements have been collected in the beginning of the devel- opment. This was done on a meeting with a thesis ordering party. Along the official requirements, the research has been performed at the Stack Overflow page which provided broader context to the prob- lem. Later, the requirements were transformed to specific use cases - see the chapter 3.
Design After analysis of the use cases, the project came to a phase of explor- ing possible technical solutions. This process is described in the chap- ter 4. The first prototype using a JChannel connection proved to benot a right approach so the application undertook a massive architecture
31 7. Conclusion change to communicating with a cluster utilizing ProbeHandler im- plementations of JGroups Protocol classes. Such a change meant that the design and implementation steps of the waterfall process had to be repeated. A new design caused the application to grow and also came up with new challenges. It was no longer possible to use a con- veniently provided JGroups API and the program needed to imple- ment communication with cluster in separate threads. Multithread- ing often brings unwanted experience. Even the code that is easy to follow can become completely nightmarish when debugging a mul- tithreaded application.
Implementation The implementation was approached incrementally by delivering in- dividual features. The code has been refactored multiple times, taking into account Robert C. Martin’s Clean Code. Key back-end components are covered by unit tests, however the proper test driven development has not been used.
Verification The verification step has been carried out by running prepared test suites and also extensive exploratory testing - the hands-on approach with minimal planning and maximum testing. The results of the test- ing were not formally documented as I was the only person on the project, hence there was no need for official format of results. The flaws detected during testing were often immediately fixed inthe code, eventually the //TODO annotations in code were used to take note of the future improvements or fixes.
Maintenance The development of the JGroups-conf will continue after submitting the thesis. It resides on GitHub and it is available under the MIT Li- cense. As it is publicly available, it awaits for community members to actively adopt it for broader use of JGroups cluster configuration. The list of features and bugs that will be fixed during the maintenance period can be found in the section 7.2.
32 7. Conclusion
7.1.2 Used tools The list of used tools according to the phase of the project they were used in: ∙ Trello1 - very agile productivity and collaboration software used for organizing work, keeping track of important dates and mile- stones. For this project I used a simple Kanban board ∙ Gliffy2 - a web-based diagram editor ∙ Google Sheets3 - part of the Google Docs, used for elaboration of the research and charts ∙ IntelliJ Idea4 - an advanced IDE, used for producing the code ∙ Gradle5 - a modern open source polyglot build automation system ∙ GitHub6 - an online service for hosting Git versioning system repositories
7 ∙ Overleaf - an online LATEXeditor, used for documentation and writing of this thesis. It provides a real-time preview of the final document and features for online collaboration.
7.1.3 Lessons learned Managing and implementing a small project like this brought a lot of experience. Main skills developed during the project were: ∙ Time management. Since I worked on JGroups-conf along my regular job, my time management skills undertook a great trial. Not everything went as planned, especially working regularly during the free time hours was difficult. Creating a Trello board
1. https://trello.com/ 2. https://www.gliffy.com/ 3. https://docs.google.com/spreadsheets 4. https://www.jetbrains.com/idea/ 5. https://gradle.org/ 6. https://github.com/ 7. https://www.overleaf.com/
33 7. Conclusion
and regularly checking the progress has proven to be very help- ful.
∙ Project management. Organizing a work on a whole applica- tion by one person could seem easy, however a decent project manager has to select a correct approach so that work chunks are meaningful and the person does not feel overwhelmed. Di- viding project to small tasks and approaching them one at a time is a very useful skill that can be used in all areas of life.
∙ Java programming. Since Java is used as a main programming language for this project, I have explored parts of the Java API yet unknown to me, familiarized myself with Java 8 and en- hanced my event-based programming skills, especially in multi- threaded environment.
∙ Network clustering. This was an unknown topic for me until I started working on the JGroups-conf project. I was sincerely surprised how widely used clustering is nowadays. With fast spreading of the cloud technologies, the clustering and tech- nologies which benefit from it’s concept are becoming more and more important. Experience gained by using JGroups are very valuable and induced new ideas for other projects I par- ticipate in.
7.2 Possible Further Improvements
As every software application, also JGroups-conf does not come out perfect and needs further polishing. Even testing can never reveal all bugs but there are several areas known to undertake maintenance af- ter finishing the thesis. Major areas for improvements in JGroups_conf and known issues are:
∙ Cluster configuration needs to work on per-node basis.
∙ Performance: the efficiency of network calls can be improved. Communicating with very large clusters could cause conges- tion and slowness of the application.
34 7. Conclusion
∙ Multithreading: occasional bugs caused by late multithreaded approach should be diminished.
35 Bibliography
[1] Ahmad Ashari and Mardhani Riasetiawan. “High Performance Computing on Cluster and Multicore Architecture.” In: Telkom- nika 13.4 (2015), pp. 1408 –1413. issn: 16936930. url: http:// ezproxy.muni.cz/login?url=http://search.ebscohost. com/login.aspx?direct=true&AuthType=ip,cookie,uid&db= a9h&AN=112315820&lang=cs&site=eds-live&scope=site. [2] Bela Ban. JGroups manual. url: http : / / www . jgroups . org / manual/index.html (visited on 05/26/2016). [3] Kenneth P. Birman. Reliable distributed systems: technologies, Web services, and applications. 1st ed. Springer, 2005. isbn: 0387215093. [4] Clusplot cluster visualization. url: http : / / 3 . bp . blogspot . com/-9KCD1QBeDtU/UMbK2fYx9GI/AAAAAAAAAaM/y_JdIB_6v0A/ s1600/S6%2Bclusplot.png (visited on 2016). [5] Steve Deering. Host Extensions for IP Multicasting. RFC 1112. RFC Editor, 1989. url: http://www.rfc-editor.org/rfc/rfc1112. txt. [6] Didier Donsez. The JMX 3-level architecture. 2008. url: https:// en.wikipedia.org/wiki/File:Jmxarchitecture.png (visited on 05/16/2016). [7] Tomoya. Enokido, Leonard. Barolli, and Makoto. Takizawa. Network- based information systems. first international conference, NBiS 2007, Regensburg, Germany, September 3-7, 2007 : proceedings. New York: Springer, c2007. isbn: 35-407-4572-6. [8] IBM Cluster systems. url: http://www-03.ibm.com/systems/ clusters/benefits.html (visited on 05/15/2016). [9] infinispan-quickstart. url: https://github.com/infinispan/ infinispan - quickstart / blob / master / clustered - cache / src/main/resources/jgroups.xml (visited on 05/26/2016). [10] JGroups project web page. url: http://jgroups.org/ (visited on 05/15/2016). [11] Oracle. Java Management Extensions (JMX). 2016. url: http:// docs.oracle.com/javase/6/docs/technotes/guides/jmx/ index.html (visited on 05/16/2016).
36 BIBLIOGRAPHY
[12] Chee Shin Yeo; Rajkumar Buyya; Hossein Pourreza; Rasit Eski- cioglu; Peter Graham; Frank Sommers. Cluster Computing: High- Performance, High-Availability, and High-Throughput Processing on a Network of Computers. url: http://www.cloudbus.org/papers/ ic_cluster.pdf (visited on 05/15/2016). [13] Wikipedia. Computer cluster — Wikipedia, The Free Encyclopedia. [Online; accessed 15-May-2016]. 2016. url: https://en.wikipedia. org/w/index.php?title=Computer_cluster&oldid=719201275.
37 A JGroups configuration for Infinispan dis- tributed cache
Following listing shows a simple example of JGroups configuration file taken from Infinispan project.
Listing A.1: jgroups.xml[9] 1 < !−− 2 ~ JBoss, Home of Professional Open Source 3 ~ Copyright 2010 Red Hat Inc. and/or its affiliates and other 4 ~ contributors as indicated by the @author tags. All rights reserved. 5 ~ See the copyright.txt in the distribution for a full listing of 6 ~ individual contributors. 7 ~ 8 ~ This is free software; you can redistribute it and/or modify it 9 ~ under the terms of the GNU Lesser General Public License as 10 ~ published by the Free Software Foundation; e i t h e r version 2 . 1 o f 11 ~ the License, or (at your option) any later version . 12 ~ 13 ~ This software is distributed in the hope that it will be useful, 14 ~ but WITHOUT ANY WARRANTY; without even the implied warranty of 15 ~ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See t h e GNU 16 ~ Lesser General Public License for more details . 17 ~ 18 ~ You should have received a copy of the GNU Lesser General Public
38 A. JGroups configuration for Infinispan distributed cache
19 ~ License along with this software; if not, write to the Free 20 ~ Software Foundation, Inc., 51 Franklin St, Fifth Floor , Boston, MA 21 ~ 02110−1301 USA, or see the FSF site: http:// www. fsf .org. 22 −−> 23 39 A. JGroups configuration for Infinispan distributed cache 44 enable_diagnostics="false" 45 bundler_type =" old " 46 47 thread_naming_pattern="pl" 48 49 thread_pool.enabled="true" 50 thread_pool.min_threads="2" 51 thread_pool.max_threads="30" 52 thread_pool.keep_alive_time="60000" 53 thread_pool.queue_enabled="true" 54 thread_pool.queue_max_size="100" 55 thread_pool.rejection_policy="Discard" 56 57 oob_thread_pool.enabled="true" 58 oob_thread_pool.min_threads="2" 59 oob_thread_pool.max_threads="30" 60 oob_thread_pool.keep_alive_time ="60000" 61 oob_thread_pool.queue_enabled="false" 62 oob_thread_pool.queue_max_size="100" 63 oob_thread_pool.rejection_policy=" Discard " 64 /> 65 66 40 A. JGroups configuration for Infinispan distributed cache 75 discard_delivered_msgs="true "/> −−> 76
41