An Interactive Graph-Based Automation Assistant: A Case Study to Manage the GIPSY's Distributed Multi-tier Run-Time System
AAn Interactive Graph-Based AutomationAssistant: A Case Study to Manage the
GIPSY’s Distributed Multi-tier Run-Time
System
Sleiman Rabah, Serguei A. Mokhov and Joey PaquetComputer Science and Software EngineeringConcordia University, Montreal, QC, Canada {s_rabah,mokhov,paquet}@encs.concordia.ca
Abstract
The GIPSY system provides a framework for a distributed multi-tier demand-driven evaluation of heterogeneous programs, in which certain tiers can generate de-mands, while others can respond to demands to work on them. They are connectedthrough a virtual network that can be flexibly reconfigured at run-time. Althoughthe demand generator components were originally designed specifically for the educ-tive (demand-driven) evaluation of Lucid intensional programs, the GIPSY’s run-time’s flexible framework design enables it to perform the execution of various kindsof programs that can be evaluated using the demand-driven computational model.Management of the GISPY networks has become a tedious (although scripted) taskthat took manual command-line console to do, which does not scale for large exper-iments. Therefore a new component has been designed and developed to allow usersto represent, visualize, and interactively create, configure and seamlessly managesuch a network as a graph. Consequently, this work presents a Graphical GMTManager, an interactive graph-based assistant component for the GIPSY networkcreation and configuration management. Besides allowing the management of thenodes and tiers (mapped to hosts where store, workers, and generators reside), itlets the user to visually control the network parameters and the interconnection be-tween computational nodes at run-time. In this paper we motivate and present thekey features of this newly implemented graph-based component. We give the graphrepresentation details, mapping of the graph nodes to tiers, tier groups, and specificcommands. We provide the requirements and design specification of the tool andits implementation. Then we detail and discuss some experimental results.
Key-words: graph-based management, visualization, GIPSY network, demand-drivencomputation, GUI 1 a r X i v : . [ c s . D C ] J un ontents A.1 Using the Graph editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16A.2 Saving/Loading a graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17A.3 Using the GMT Operator . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
B Stored Graph Example
List of Figures
The GIPSY (General Intensional Programming System) project is an ongoing researchproject developed at Concordia University. Its initial goal was to investigate on a generalsolution for the evaluation of programs written in the Lucid intensional programmingfamily of languages using a distributed demand-driven evaluation model. In order tomeet the flexibility goals of the project, the system has been designed using a frameworkapproach integrating a Lucid compiler framework, as well as a demand-driven run-timesystem framework.In its eductive model of execution, the system assumes the presence of demand gen-erators, as well as a demand workers. Each demand generated is paired along with thecontext in which it is made and is uniquely identified. The demands are migrated using acommunication node that enables the connection between demand generators and demandworkers. Through the communication node, any demand worker can pick-up demands,compute its resulting value, and send it back to the communication node to be picked upby the generator.Notably, the framework has demonstrated its flexibility by having the run-time systemput to use in the demand-driven distributed evaluation of programs not involving theLucid language. The work presented here goes in this direction and makes abstractionof the intensional programming aspect of the project and concentrates on the demand-driven evaluation of heterogeneous programs. We concentrate on showing how a virtualnetwork of demand-driven computational nodes can be represented graphically at run-time, enabling the user to map the demand-driven computation nodes over an underlyingphysical network of computers, and to control their execution and connectivity at run-time.In the current implementation, the node’s connectivity is expressed in a set of con-figuration files. Upon starting, a node reads its configuration file and establishes its ownconnection according to the information contained in the configuration file. The config-uration can be changed at any time, so that a node can reconfigure its connectivity atrun-time.A manager node, which acts as a supernode, has been implemented to manage aGIPSY network. It enables new node(s) to automatically establish connection with itand receive commands from it. Therefore, enabling the manager node to remotely changethe configuration of any registered node. The virtual network is thus constructed from theinterconnection of the generators, workers, communication, and manager nodes, the laterbeing able to establish the connectivity between the three first ones. All communicationbetween nodes, including commands exchanged for configuration changes, are using thesame demand-driven communication mode.The rest of this paper is organized as follows: Section 2 gives on overview of theGIPSY Framework and its multi-tier architecture, the GIPSY run-time system and finallydiscusses the related work. Section 3 summarizes the objectives of this work. Section 4presents how currently the GIPSY run-time system is being managed, discusses the designand implementation of the proposed solution and evaluates the results of some conductedexperiments. Then, Section 5 concludes the paper and points out new research directionplanned as future work.
The GIPSY run-time system is a distributed multi-tier and demand-driven framework. Itmainly consists of a set of loosely coupled software components enabling the evaluationof programs in a distributed demand-driven manner. The run-time system is composedof the following basic entities [17]: (a)
A GIPSY tier is an abstract and generic entity.Each tier instance is a separate thread (one or more) that runs within a registered pro-cess, namely (GIPSY node), and represents a computational unit that contribute to thedistributed computation. Tiers cooperate in a demand-driven mode of computation; (b)
A GIPSY node is a registered process that hosts one or more GIPSY tier instances be-longing to different GIPSY instance(s). Node registration is done through a manager tiercalled the GIPSY Manager Tier (GMT). More specifically, a node is a computer runninga
GIPSYNode process; (c)
A GIPSY instance is a group of tier instances collaboratingtogether to achieve program execution. It can be considered as a set of interconnectedGIPSY tier instances hosted/deployed on one or more GIPSY nodes executing GIPSYprograms by sharing their respective resources. A GIPSY instance can be executed acrossdifferent GIPSY nodes. Moreover, as shown in Figure 1, a GIPSY network is designed asan overlay network where network nodes, GIPSY tiers, are organized in a cluster calledGIPSY instance. A GIPSY tier can be seen as a virtual network node and hosted on aGIPSY node. In such a network, the mapping between a GIPSY node and a physicalnode is made upon starting and registering the node through the GMT.
In [17], a distributed multi-tier architecture has been defined and adopted in the imple-mentation of GIPSY run-time system. The architecture inherits some of the peer-to-peernetwork architecture principles, e.g (1) no single-point of failure: any tier or node canfail without fatally affecting the system; (2) nodes and tiers can seamlessly join/leave thenetwork by adding/removing them on the fly as computation is happening; (3) demandsare propagated without knowing where they will be processed or stored; (4) availablenodes and tiers can be affected at run-time to the execution of any GIPSY program whileother nodes and tiers could be computing demands for different programs. The multi-tierarchitecture is composed of four distinct tiers: (a) a Demand Store Tier (DST) that actsas a middleware between tiers in order to migrate demands, provides persistent storageof demands and their resulting values (demands caching), and exposes Transport Agents(TAs) used by other tiers to connect to the DST; (b) a Demand Generator Tier (DGT)that generates demands according to the declarations and resources stored in the GEERgenerated for the program being evaluated. The DGT maintains a local demand pro-cessing dictionary pool that contain the definitions required to formulate demands; (c)a Demand Worker Tier (DWT) which processes demands by executing method definedin such a dictionary. The DWT connects to the DST, retrieves pending demands andreturns back the computed demands to the DST; (d) a General Manager Tier (GMT)(see Figure 1), as its name implies, locally and remotely controls and monitors other tiers (DGT, DWT and DST) by exchanging system demands. Furthermore, the GMT canregister new nodes, move tier instances from one node to another, or allocate/deallocatetier instance from/on a registered node.Figure 1: Example of a GIPSY Nodes Network [17]
A demand is a run-time request asking for a value of certain identifier defined in a GIPSYprogram. Demands are migrated to other tiers using the DST. There are three types ofdemands: (a) intensional demands, which are generated for the evaluation of a GIPSYprogram by a generator. GIPSY programs are written in a declarative style, where anidentifier is defined as an expression using other identifiers defined in a multidimensionalcontext space [17]. All demands for GIPSY identifiers contain the context in which theyare made, and their evaluation depend on this context. The GIPSY program also usesan algebra of procedures that can be called during evaluation, which are called at run-time and become procedural demands; (b) procedural demands which are generated by theDGT when it encounters a procedural function call during the GIPSY program evaluation.Procedural demands are processed by the DWT; (c) system demands, in turn, are issuedby the GMT for run-time management purposes and include demands for monitoring andcontrolling tiers at run-time. It is worth mentioning that system demands are requests formanagerial tasks e.g. demand for node registration, tier allocation and deallocation. Incontrast, intensional demands and procedural demands are computational demands, i.e.demands that are generated during the evaluation process of a specific GIPSY program.In the GIPSY environment, each demand has a state and demand states are used tomanage and propagate demands. The state transitions are managed by the demand store tier DST, who is responsible for demand migration between generator and worker tiers.We distinguish three possible states as follows: (a)
Pending: a pending demand is ademand that has been issued by a tier to the demand store and not yet picked by anothertier for further processing. Pending demands are sent to generators and workers whenthey notify their availability for processing [17]; (b)
Processing: a processing demandis a demand that has been grabbed by a tier from the demand store and its evaluationstill being processed. This state is assigned by the demand store in order to make surethat the same demand is grabbed by only one tier for processing. When a tier goes outof service, all its associated processing demands are put back to the pending state bythe demand store, ensuring a fail-safe behavior [17]; (c)
Computed: indicates that ademand has been computed. When a tier grabs a demand and is finished computing itscorresponding value, it sends back the result to the demand store, that stores it in placeof the initial demand and marks it as computed. Any further demands generation withthe same context will result in the store to directly respond with the resulting value, thussaving computation time [17].
Here we provide some details how the graph-based tool we developed assists with theautomation of the startup sequence and management tasks of the system.
Configuration.
The tier instantiation process has a flexible design and has been imple-mented using Java Reflection [5] and the Factory design pattern [4]. It uses a configuration-based system to instantiate tiers on the fly. Generic configuration instances are stored infiles and their settings can be easily updated and tailored to a specific tier’s implementa-tion requirements. Configurations contain a set of key-value pairs where the key denotesthe name of the configuration property while the values could be anything from a servicename, port number, IP address, etc. Such a configuration system eliminates the need ofwriting or adapting source code to reflect a specific tier configuration. The propertiesstored in the
Configuration object determine the tier class to instantiate and consistof different settings interpreted by the tier implementation class. Upon receiving a tierinstantiation request, the
TierFactory inspects the configuration instance to determinewhich tier implementation class to instantiate using Java Reflection [5].
Bootstrapping. as mentioned earlier, a GIPSY network consists of a set of intercon-nected GIPSY nodes each hosting GIPSY tiers mapped to physical machines where theGIPSY run-time is deployed. Such a network is managed by a GIPSY manager tier (GMT)that enables nodes registration to the network and tier allocation on the registered nodes.The bootstrap process of the GIPSY manager tier starts a registration demand store thatis used solely for the exchange of system demands with the nodes and tiers allocated inthe GIPSY network managed by this manager tier. Thus, system demands and compu-tational demands are exchanged using different communication channels. Any computerdeploying the GIPSY node run-time system can send a registration request to the man- ager tier, enabling this manager tier to remotely connect and control the allocation ofvarious tiers on the registered nodes. After tiers are allocated to the registered nodes, themanager tier can connect the different tiers together, and eventually instruct a genera-tor to start the demand-driven evaluation of a GIPSY program. Even after execution isstarted, the manager tier can accept new nodes registrations, or allocate/deallocate newtiers on any registered node that it manages and make newly allocated tiers to contributeto a program’s evaluation on the fly [8, 7].
GIPSY Node Registration.
When a node wants to join the network, first, a GIPSYnode issues a request to the GMT expressed as
NodeRegistration system demand having pending as state. Upon receiving a
NodeRegistration demand, the GMT assigns a DSTto the GIPSY node who issued the request. Afterward, the GMT saves the node regis-tration information in a
GMTInfoKeeper object and sends back a
RegistrationResult demand having computed as state and containing the DST information and the assignednode ID. Finally, the GIPSY node processes the result and uses the information con-tained in the demand to establish a connection to the assigned DST. Establishing suchconnection creates a communication channel for further exchange of system demands.
Tier Allocation.
Tiers are allocated inside a previously registered GIPSY node. Theprocess of tier allocation is performed through the operation of the GMT using a pair ofsystem demands:
TierAllocationRequest and
TierAllocationResult . Both demandsshare the same demand signature but have different states: pending and computed respec-tively. The following information needs to be specified in the
TierAllocationRequest demand: the node identifier of the GIPSY node where the tiers to be allocated, the typeof the tier and how many tier instances are to be allocated. When the allocation processis completed a
TierAllocationResult demand is triggered and contains a set of tierregistrations. Each tier registration contains information such as the tier identifier, whichis internally assigned by the GIPSY node.
Tier Deallocation.
Tier deallocation consists of removing previously allocated tiers.Similarly to the case of the tier allocation process, two system demands
TierDeallocationRequest and
TierDeallocationResult are issued by the GMT todeallocate tiers upon user’s request. The type and the ID of the tier to be deallocatedare embedded in a
TierDeallocationRequest and sent to the
GIPSYNode process todeallocate the tier specified.
Related work by several researchers on visualization of load balancing, configuration,formal systems for diagrammatic modeling and visual languages and the correspondinggraph systems are presented in [20, 19, 1, 2, 10]. They all define key concepts that arerelevant to our visualization mechanisms within GIPSY and its corresponding GeneralManager Tier [7].
The GIPSY framework has been designed in a modular manner but has a lot of config-urable components; hence, the need of an automation solution for configuring and manag-ing GIPSY deployment components is crucial. Moreover, prior to this work, the run-timesystem was managed using primarily a command-line interface. The project should pro-vide an integrated tool that allows the user to: create a GIPSY network and configure itscomponents (GIPSY instances, tiers and nodes); save/load a GIPSY network configura-tion; start/stop GIPSY nodes and register them with the GMT, and allocate/deallocateGIPSY tiers; dynamically visualize GIPSY nodes and tiers and inspect/change their prop-erties at run-time; change tiers connectivity at run-time; increase the usability of GIPSYrun-time system as a whole; provide means and semantics for scheduling, validation, andvisual mapping to Lucid programs. The GMT is the central element of our system fromthe user’s perspective. It enables to handle the managerial tasks related to the configura-tion and functioning of a GIPSY network. The proposed solution should be transparentand efficient enough in order to enhance the system usability, flexibility, and end-usersexperience, while maintaining the structure for run-time analysis and scheduling.
The solution presented in this paper is a graph-based graphical user interface that providesa set of user interfaces enabling the users to directly interact with the distributed GIPSYrun-time system. The main objectives (cf. Section 3) of this work consist of increasingthe usability of the run-time system and enabling the user to have full control over theGIPSY network with a minimum of detailed manual intervention. It should be notedthat, prior to this work, all the managerial and configuration tasks needed to bootstrapa GIPSY network required the user to manually execute shear number of commands andscripts. In this work, we designed the graphical GMT component that aims at allowingthe user to manage and operate the entire GIPSY network seamlessly by translatingsimple graphical user interactions into complex message passing between the underlyingdeployment components. Our solution enables the user to easily create, configure, andcontrol a GIPSY network through a graph-based interface. GIPSY tiers are illustrated asconnected graph nodes. Tiers’ properties are read from files and stored as
Configuration objects embedded in the graph nodes. We use graph element shapes to differentiateGIPSY instances and colors to differentiate GIPSY nodes. When the user adds a newtier to the network graph, the color assigned to the tier is associated to the node the tieris assigned to.According to the GIPSY multi-tier architecture, the DWT, DGT and DST exposesoftware interfaces to be used for their mutual interactions. Since the GMT plays a keyrole in the GIPSY network management, it provides a handy mechanism for startingand stopping nodes, and allocating and deallocating tiers. In the current run-time im-plementation, the interaction with the GMT is command-based and is done through a command-line console UI, with which the user manually bootstraps and controls the nodesand tiers by entering commands the corresponding. Additionally, a set of configurationfiles with the appropriate settings and properties for each tier type are needed. Beforeperforming any node or tier startup or registration, we assume that a set of configurationfiles with appropriate settings and properties for nodes each tier type have been created.Typically, in order to start a network, the following sequence of steps should normally beperformed: 1. At first, a GIPSY node process should be created; that prompts the user tostart a GMT tier. When a GMT is started, the GIPSY node is automatically registeredand a registration DST is allocated [7]. The registration DST enables the GMT to receivesystem demands for further node and tier allocations. This is the initial bootstrappingprocess that enables all further operations on a GIPSY network. 2. At any time the usercan expand the network by adding an additional node locally on the computer where theGMT is executing (and tiers on a remote computer). Upon successful node creation, theuser is prompted to register the node to an existing GMT using the register command.3. Then, on any registered node, DSTs are started to allow the propagation of demandsbetween generators and workers, DGTs are registered to generate demands, and DWTsare registered to process the generated demands.Based on this discussion, the following is a typical list of example commands that areused to interact with the run-time system in order to setup a manual GIPSY network:1. start GMT GMTConfigFile.config
This command starts the bootstrap process explained above, where GMT is thetype of the tier and
GMTConfigFile.config is the configuration file that containsthe settings and properties needed to instantiate a GMT tier instance.2. allocate NodeID TierType TierTypeConfigFile DSTIndex HowMany
This command allocates a DGT or a DWT.
NodeID is the numeric ID of the nodewhere the tier should be allocated,
TierType is the type of the tier ([DGT, DWT]),
DSTIndex is the index of the DST, to which the tier in question should connect toand the
TierTypeConfigFile is the tier-specific configuration file to use.3. allocate NodeID DST DSTConfigFile.config HowMany
This command sends a request to the GMT with the node ID where a DST instancewill be allocated, how many DST instances are needed, and a DST configurationfile name.4. deallocate NodeID TierType TierID1 TierID2 TierID n This command issues a demand to be processed by the GMT to deallocate tiers.
TierType is the type of the tierID[1..n] is tier instances IDs to deallocate in a nodespecified by its ID.The GIPSY network configuration process requires the user not only to know all thecommands and their exact syntax, but requires to keep track of the IDs of the nodesand tiers. It also requires the user to manually edit the related configuration files. Theconfiguration files contain many configuration elements that are not of importance in thenode/tier management process, thus leading to confusion and possible mistakes. Our newly designed graphical GMT assistant rather allows the user to abstractly manipulateicons and use menu options to effectuate these operations. These GUI operations initiatedby the user are then translated by the graphical GMT into the commands similar to thepresented earlier. As for the changes to the configuration files, the user is presentedthrough the GUI with only the configuration elements that are relevant in the contextof use, thus reducing the information load on the user and reducing the possibility ofconfiguration mistakes. Listing 1 shows the content of a configuration file for a DGT [7].It provides configuration information such as to which class implementation to instantiate,the number of instances to be created, the mode of communication to use, and a maximumnumber of demands that can be generated. These configuration parameters are readduring startup and will determine the behavior of the generator.
Listing 1: A Sample of DGT Configuration File
Our implementation relies on the graph-based visualization to illustrate a GIPSY network.We represent a GIPSY tiers network as interconnected graph nodes where each such nodecontains data/properties used in tier-to-tier communication configuration. Such proper-ties are assigned and configured by the user when creating a GIPSY network. The GMTGUI was implemented using the Java JFC/Swing library. The GIPSY’s
Configuration class is used to store different components’ configuration. We have selected the Java Uni-versal Network/Graph (JUNG) library to implement the visualization of the managementaspect of GIPSY nodes [9, 15]. JUNG is an open-source library for modeling data thatcan be represented as a graph or a network. JUNG provides many visualization featuresthat can be changed at runtime such as node color, shape, and size. Thus, graph nodescan be grouped together, which enables us to differentiate the nodes by their tier type(DST, GMT, or DWT). Through JUNG, GIPSY nodes are configured while creating aconnected graph of nodes and to visualize and manage their activities to alleviate manualcomplexity of such operations. The GMT GUI addresses the need of the automation ofthe managerial tasks of the GIPSY run-time system and the configuration of resources.The implemented features are: 1. create a new GIPSY network as a graph; 2. save/loada pre-configured GIPSY network to/from files; 3. start, register and stop GIPSY nodes by maintaining a color-differentiated list of nodes with their related commands and configu-rations available in a context menu; 4. allocate and deallocate DSTs, DGTs and DWTsby manipulating icons and context menus; 5. start/stop the demand-driven evaluationprocess on a DGT trough a contextual menu accessed on its icon.The process of node registration and tier allocation has been embedded into our tool,and only the most relevant configuration information is shown to the user. Graphicalobjects representing GIPSY nodes encapsulate their related commands and hold the nec-essary properties for user inspection or change at setup or run-time. As for GIPSY tiergraphical objects, in addition to allocate and deallocate commands, these objects providea drag-and-drop mechanism used to change the connectivity between tiers on the fly atrun-time (see Figure 2(a)). When a new tier or a GIPSY node is added to the network,it is automatically pre-configured and associated with a configuration file with the prop-erties entered by the user (see Figure 2(b)). The GMT GUI is arranged in a tabbed formand provides two main distinct editor and operator views.The network graph editor and resource configuration allow to create a GIPSY networkor load an existing one. As shown in Figure 2(b), GIPSY instances and nodes are arrangedin two lists while GIPSY tiers in a graph illustrating interconnected tiers. Instances,nodes and tiers can be easily added and configured separately. The configuration processis completely automated using dialog boxes allowing the user to fill in the configurationproperties of each entity. All data entered is validated allowing only valid values tobe accepted. In this editor, two GIPSY tiers could be connected together and theirconfiguration commands automatically generated by drawing a line to connect two graphnodes.The GMT operator lists context-menu-enabled GIPSY nodes allowing the user to startor stop GIPSY nodes and register them with the GMT by simple mouse clicks. As illus-trated in Figure 2(a), GIPSY tiers are shown as connected graph nodes. Tiers belongingto the same GIPSY instance are assigned the same shape. The tier’s color determines onwhich GIPSY node a given tier is hosted on. Moreover, inspection and visualization ofany element’s properties is possible at run-time. This enables the user, for instance, toknow which GIPSY tier is residing on which GIPSY node. The run-time system activitiessuch as the output of GMT, GIPSY nodes and GIPSY tiers, errors, and log messagesare displayed in a separate distinct views. This provides better failure traceability anderrors troubleshooting while, at the same time, providing useful information related tothe overall computation process.In Figure 3(a) is a set of JUNG-interfaced classes we produced to integrate withand visually represent, load, save, and manage GIPSY networks while in Figure 3(b)we detail the data structures used to internally represent the network graphs and mapthem to the GIPSY objects and the action items associated with them.
NodeConnection is a semantically central data structure that links graph elements representing GIPSYtiers (the instances of
GIPSYTier classes). These connections and tier properties arethe actual representation of the graphs that are saved to and loader from a name:valuepaired configuration files (e.g. see Appendix B) by
GraphDataManager . A collectionof
NodeConnection s is managed by the
GraphViewer , and both
NodeConnection and
GIPSYTier have action items attached to them that send the aforementioned GIPSYcommands to actually do the work via the visual
NodeMenu and
TierMenu . Every tier has (a) GMT Operator View (b) Network Graph Editor View
Figure 2: GMT Operator and Network Graph Editor Viewsa color and shape (
VertexColorTransformer , VertexShapeSizeAspect ) attached to itbased on the
GIPSYNode they belong to, so it is easier to differentiate and visualize thecomputing resource allocations. When each graph is loaded, mapping is made, and colorsdetermined, the data structures are handed over to JUNG to do the visual layout. (a) Visualization Classes (b) Graph-Related Data Structures
Figure 3: UML Class Diagrams of the Graph-Related Design Aspects
The results are encouraging since they demonstrate the ability of the proposed solutionto assist in automation of some management functions GIPSY run-time system. We havefirst tested with the simulator [18, 7] which allows to generate different types of demands to be computed. We have then performed some usability testing with another tool, thatwas recently adapted to be distributively executed over GIPSY – MARFCAT. It is oneof the realistic long-running distributed pattern recognition computation processes testcases (e.g. MARF’s pattern recognition pipeline [11] with very large data sets over GIPSYfor the static code analysis application for vulnerabilities and weaknesses detection andmalware classification [12, 14]. MARFCAT was made to run completely over GIPSYseparating the heavy and light work logic across the generator and worker tiers. The toolproperly starts up all the indicated components, the network of which were created andthe configurations loaded, begins the computation, logs the output to the console, andwhile computation proceeds, the tier state is properly reflected visually.While us we were the only users of the proposed PoC tool thus far, by making itpublic and released along with the GIPSY system and via the demonstration of the toolon the GIPSY simulator and MARFCAT, we hope to gather larger feedback on the toolto improve its usability further while weeding out known bugs.In Appendix A we summarize a complete demo procedure/manual for a creation of aspecific application to run over the GIPSY network for demonstration purposes.
Platforms Tested.
We tested the tool in various operating system platforms to ensurethe portability is maintained: Windows XP SP3 32-bit, Windows 7 32-bit and 64-bit;Scientific Linux 6.2 32-bit and 64-bit, and Ubuntu Linux 11.03 32-bit under VMware;MacOS X 10.5 32-bit and 64-bit; Oracle JDK 6 and 7; OpenJDK 6; Apple JDK 6.
Implications.
The implications of this work are multifold. First, the usability andmanagement aspects of the multi-tier GIPSY network are of obvious mention. Addition-ally, having the network represented and managed as a graph allows for further reasoningand automatic scheduling [6] and load-balancing of such a network through the graphanalysis. Thirdly, since Lucid is a data-flow language and was shown to have one-to-onecorrespondence with the data-flow graphs (DFGs) [16, 3, 13], the tool opens up morepossibilities for diagrammatic programming and program-graph-execution-network trans-lation model for detailed analysis and verification of Lucid-based programs with the addedvisualization benefit.
We have presented a graph-based GUI implementation for the simplification of the man-agement of the GIPSY run-time system components. The presented tool is proving to bean effective solution assisting with management automation of GIPSY software artifactsdistributed across multiple physical machines forming an overlay network. Our solutionrelies on graph-based programming and visualization to represent a GIPSY network. Eachgraph node represents a GIPSY tier and is pre-configured and loaded with the informationneeded at run-time. A GIPSY network can be created, configured and saved to a file. Theuser can establish a connection between pairs of GIPSY tiers by drawing a line to connecttwo graph nodes. A GIPSY network can be easily bootstrapped and managed on thefly. Many demand generators and workers can be allocated as computation is happening.
While aiming at increasing the usability of the run-time system, our solution allows theuser to seamlessly inspect the status and properties of GIPSY nodes and GIPSY tiers atrun-time.The work presented in this paper is to be extended, thus, additional features andimprovements are planned. Future work includes a better semantic definitions of thegraph manipulation actions, so that any operation on a graph can be translated moreeasily into the underlying system’s commands and be verifiable. We plan to add observersto any graph element, enabling for example to click on a graph link to observe the demandsflowing across this link at run-time. Among the planned future works is the continualextension of the current design to support more problem-specific tiers like MARFCAT,e.g. genome sequence alignment, and similar computation problems that need a lot ofmanual pre-setup to run. We further plan to allow intra-tool (peer) communication tofurther allow start up nodes on remote computers and not only tiers. Additionally, exposean OpenGL-to-Java remote interface to allow connecting to the tool from any OpenGL-enabled systems remotely, including mobile devices based on iOS and Android.
Acknowledgements
This work in part is supported by NSERC and the Faculty of Engineering and ComputerScience of Concordia University. We thank reviewers for their constructive reviews andfeedback.
References [1] Gerard Allwein and Jon Barwise, editors.
Logical reasoning with diagrams . Oxford Univer-sity Press, Inc., New York, NY, USA, 1996.[2] R. Bardohl, M. Minas, G. Taentzer, and A. Sch¨urr. Application of graph transformationto visual languages. In
Handbook of Graph Grammars and Computing by Graph Trans-formation: Applications, Languages, and Tools , volume 2, pages 105–180. World ScientificPublishing Co., Inc., River Edge, NJ, USA, 1999.[3] Yimin Ding. Automated translation between graphical and textual representationsof intensional programs in the GIPSY. Master’s thesis, Department of Com-puter Science and Software Engineering, Concordia University, Montreal, Canada,June 2004. http://newton.cs.concordia.ca/~paquet/filetransfer/publications/theses/DingYiminMSc2004.pdf .[4] Eric Freeman, Elisabeth Freeman, Kathy Sierra, and Bert Bates.
Head FirstDesign Patterns . O’Reilly, first edition, October 2004. , .[5] Dale Green. Trail: Java reflection API. [online], 2001–2012. http://docs.oracle.com/javase/tutorial/reflect/index.html .[6] Khaled M. Ben Hamed. Multidimensional Programs on Distributed Parallel Computers:Analysis and Implementation . PhD thesis, Computer Science, the University of NewBrunswick, February 2008.14raph-Based Tool To Manage GIPSY Networks Rabah, Mokhov, Paquet[7] Yi Ji. Scalability evaluation of the GIPSY runtime system. Master’s thesis, Departmentof Computer Science and Software Engineering, Concordia University, Montreal, Canada,March 2011.[8] Yi Ji, Serguei A. Mokhov, and Joey Paquet. Unifying and refactoring DMF to supportconcurrent Jini and JMS DMS in GIPSY. In Bipin C. Desai, Sudhir P. Mudur, and Emil I.Vassev, editors,
Proceedings of the Fifth International C* Conference on Computer Scienceand Software Engineering (C3S2E’12) , pages 36–44, New York, NY, USA, June 2010–2012.ACM. Online e-print http://arxiv.org/abs/1012.2860 .[9] JUNG Project. Java Universal Network/Graph Framework. [online], 2003–2012. http://jung.sourceforge.net/ , last viewed January 2012.[10] N. G. Miller.
A Diagrammatic Formal System for Euclidean Geometry . PhD thesis, CornellUniversity, U.S.A, 2001.[11] Serguei A. Mokhov. Study of best algorithm combinations for speech processing tasks inmachine learning using median vs. mean clusters in MARF. In Bipin C. Desai, editor,
Proceedings of C3S2E’08 , pages 29–43, Montreal, Quebec, Canada, May 2008. ACM.[12] Serguei A. Mokhov. The use of machine learning with signal- and NLP processing of sourcecode to fingerprint, detect, and classify vulnerabilities and weaknesses with MARFCAT.[online], October 2010. Online at http://arxiv.org/abs/1010.2511 .[13] Serguei A. Mokhov, Joey Paquet, and Mourad Debbabi. On the need for data flow graphvisualization of Forensic Lucid programs and forensic evidence, and their evaluation byGIPSY. In
Proceedings of the Ninth Annual International Conference on Privacy, Securityand Trust (PST), 2011 , pages 120–123. IEEE Computer Society, July 2011. Short paper;full version online at http://arxiv.org/abs/1009.5423 .[14] Serguei A. Mokhov, Joey Paquet, Mourad Debbabi, and Yankui Sun. MARFCAT: Transi-tioning to binary and larger data sets of SATE IV. [online], May 2012. Being finalized forNIST publication; online at http://arxiv.org/abs/1207.3718 .[15] J. O’Madadhain et al. The JUNG (Java Universal Network/Graph) framework. Tech-nical Report UCIICS-03-17, School of Information and Computer Science, University ofCalifornia, Irvine, 2003.[16] Joey Paquet.
Scientific Intensional Programming . PhD thesis, Department of ComputerScience, Laval University, Sainte-Foy, Canada, 1999.[17] Joey Paquet. Distributed eductive execution of hybrid intensional programs. In
Proceedingsof the 33rd Annual IEEE International Computer Software and Applications Conference(COMPSAC’09) , pages 218–224, Seattle, Washington, USA, July 2009. IEEE ComputerSociety.[18] Amir Hossein Pourteymour, Emil Vassev, and Joey Paquet. Towards a new demand-drivenmessage-oriented middleware in GIPSY. In
Proceedings of PDPTA 2007 , pages 91–97, LasVegas, USA, June 2007. PDPTA, CSREA Press.[19] Phan C. Vinh and Jonathan P. Bowen. On the visual representation of configuration inreconfigurable computing.
Electron. Notes Theor. Comput. Sci. , 109:3–15, 2004.[20] Chunfang Zheng and J. Robert Heath. Simulation and visualization of resource allocation,control, and load balancing procedures for a multiprocessor architecture. In
MS’06: Pro-ceedings of the 17th IASTED international conference on Modelling and simulation , pages382–387, Anaheim, CA, USA, 2006. ACTA Press. 15raph-Based Tool To Manage GIPSY Networks Rabah, Mokhov, Paquet
A Mini Demo User Manual / “Demo Paper”
In this section we give a brief overview on how to use the graphical PoC tool to createand manage a GIPSY network. We explain how to create and configure a network, howthe network is saved/loaded to/from a file, and finally, how the network is being managedin the GMT Operator view.This section is intended for the demonstration of the tool at the conference with amini-user manual instructions and operational description. We will show how to createand start a complete GIPSY network for the specific MARFCAT application and performa complete run of it. We will release the PoC tools, the application, and the source codefor the audience and community at large as well.
A.1 Using the Graph editor
The graph editor is used to create a new GIPSY network or to edit an existing one.I.
Creating/Editing a GIPSY instance
Figure 4(a) and Figure 4(b) show how to create a GIPSY instance and edit itsinformation. By clicking on the add button, the user enters a name for the newGIPSY instance to create and clicks save. Double-clicking on an instance in the listof instances allows to edit the instance name in an appropriate dialog.II.
Creating/Editing a GIPSY Node
To create a new GIPSY node, click on the “Add” button Figure 4(c), which popsup a dialog to fill in the new node’s properties such as the node name, IP addressand color, see Figure 5(a). Upon clicking “Save”, the new node will be added to thelist as shown in Figure 5(b). To edit an existing node’s properties, double-click onan item in the node list and a editing dialog will pop up Figure 5(c). (a) Creating new GIPSY In-stance (b) Editing GIPSY Instance (c) Add GIPSY Node
Figure 4: Adding a GIPSY Instance and a GIPSY Node (a) Create New GIPSY Node (b) New GIPSY NodeAdded (c) Editing GIPSY Node
Figure 5: Creating and Editing a GIPSY NodeIII.
Creating/Editing a GIPSY tier
While editing, a GIPSY tier is represented as a red graph node. To create a GIPSYtier, the user must double-click on the highlighted area as shown in Figure 6(a).Then, the tier properties such as the tier name, how many instances to create,GIPSY instance to which the tier belongs to, GIPSY node on which the tier will beallocated, and finally a configuration file should be specified, cf. Figure 6. To edit agiven tier’s properties, right-click on a graph node and select “Edit Tier Properties”,see Figure 7(b). (a) Creating a GIPSY Tier (b) Fill In Tier Configuration Properties
Figure 6: Creating and Configuring a GIPSY Tier
A.2 Saving/Loading a graph
To save/load a network to/form a file, use the save/load buttons located in the toolbar,Figure 8(a) and Figure 8. (a) Right Click to Edit Tier Properties (b) Edit Tier Properties
Figure 7: Editing Tier Properties
A.3 Using the GMT Operator
This feature is implemented in the “GMT Operator” tab and enabled upon loading avalid saved network graph. After loading is complete, the graph nodes (GIPSY Tiers)have the same color as the GIPSY node they belong to. Tiers’ shapes, as mentioned earlyin this paper, indicate what GIPSY Tier belongs to what GIPSY Instance. (a) Saving/Loading Graph (b) Load Graph (c) Loaded Graph Example
Figure 8: Saving and Loading GIPSY network GraphI.
Starting/Stopping a GIPSY node
To start a GIPSY node, right-click on a item in the nodes list and select “StartNode”, Figure 9(a).After starting the first GIPSY Node, the actions taken are logged in the log consolein “Messages” tab.When the GMT is first started, a new tab is added to the log console where itsactivities are logged, see Figure 9. (a) Starting Node (b) Starting Node Messages (c) Node Registered
Figure 9: Saving and Loading GIPSY network GraphII.
Allocation/Deallocating GIPSY tier
To allocate or deallocate a GIPSY Tier, right-click on a graph node and select theappropriate action, Figure 10(a). The messages and action triggered by the alloca-tion/deallocation process are logged and showed in the console tab, Figure 10(b),Figure 11. (a) Start Tier (b) Allocation/Startup Console Messages
Figure 10: Starting a Selected Tier
B Stored Graph Example
In the example below is a concrete on-disk representation of the GIPSY network graphfrom marfcat4Some.config that can be stored and retrieved and executed instantiatingthe designed configuration and its connectivity for the MARFCAT test case with thecorresponding graph in Figure 12. (a) Allocation of DST (b) Deallocation after a SystemDemand (c) Deallocation Completed
Figure 11: Allocation and Deallocation of a DSTFigure 12: MARFCAT GIPSY network Graph gipsy.tier.posx.a409cb6b-ad54-41f6-af69-f4ec78628ec6=405gipsy.tier.isgmt.89e6605e-5c81-4d95-bf51-8e7576c8dcd7=falsegipsy.tier.ID.1523569d-25aa-44a4-97d5-370b93790333=1523569d-25aa-44a4-97d5-370b93790333gipsy.tier.posx.89e6605e-5c81-4d95-bf51-8e7576c8dcd7=409gipsy.connection.to.7802414d-437f-4382-9162-15d9d8e735c3=77fd90ec-e49e-4977-a55b-0690e2e0cd08gipsy.tier.howmany.a409cb6b-ad54-41f6-af69-f4ec78628ec6=1gipsy.tier.isgmt.c341ab91-161e-419d-a7e4-6206e75ec097=falsegipsy.tier.howmany.89e6605e-5c81-4d95-bf51-8e7576c8dcd7=1gipsy.tier.node.1523569d-25aa-44a4-97d5-370b93790333=1gipsy.tier.posx.c341ab91-161e-419d-a7e4-6206e75ec097=74gipsy.tier.howmany.c341ab91-161e-419d-a7e4-6206e75ec097=1connection_key.0dd7156f-3b40-4df7-b9a9-d1b44eeb4da0=0dd7156f-3b40-4df7-b9a9-d1b44eeb4da0gipsy.node.name.3=WORKER COILgipsy.node.name.2=WORKER NETOgipsy.tier.posy.1523569d-25aa-44a4-97d5-370b93790333=55gipsy.node.name.1=WORKER GLEAMgipsy.tier.isgmt.77fd90ec-e49e-4977-a55b-0690e2e0cd08=falsegipsy.node.name.0=MAINgipsy.tier.posx.77fd90ec-e49e-4977-a55b-0690e2e0cd08=75gipsy.connection.to.0dd7156f-3b40-4df7-b9a9-d1b44eeb4da0=77fd90ec-e49e-4977-a55b-0690e2e0cd08gipsy.tier.howmany.77fd90ec-e49e-4977-a55b-0690e2e0cd08=1gipsy.tier.node.29310d89-fd7a-498c-8a47-f80d3b5b9865=0gipsy.connection.id.1eeea2b5-ec50-4990-a7fe-be48bb5b693e=1eeea2b5-ec50-4990-a7fe-be48bb5b693egipsy.tier.tiertype.a409cb6b-ad54-41f6-af69-f4ec78628ec6=DWT gipsy.tier.posy.29310d89-fd7a-498c-8a47-f80d3b5b9865=53gipsy.tier.ID.29310d89-fd7a-498c-8a47-f80d3b5b9865=29310d89-fd7a-498c-8a47-f80d3b5b9865gipsy.tier.isgmt.1523569d-25aa-44a4-97d5-370b93790333=falsegipsy.connection.id.6a9e123b-c375-4786-9d15-12faeee54c59=6a9e123b-c375-4786-9d15-12faeee54c59gipsy.tier.posx.1523569d-25aa-44a4-97d5-370b93790333=409gipsy.tier.instance.a409cb6b-ad54-41f6-af69-f4ec78628ec6=8f5d7614-49e9-4c8a-87fe-c8032a5c9009gipsy.tier.howmany.1523569d-25aa-44a4-97d5-370b93790333=1gipsy.connection.name.6a9e123b-c375-4786-9d15-12faeee54c59=[MARFCAT DGT,MAIN DST]gipsy.tier.tiertype.89e6605e-5c81-4d95-bf51-8e7576c8dcd7=DWTgipsy.tier.tiertype.77fd90ec-e49e-4977-a55b-0690e2e0cd08=DSTgipsy.connection.id.36485580-5acf-4c12-9110-47c60e23ddc9=36485580-5acf-4c12-9110-47c60e23ddc9gipsy.connection.name.1eeea2b5-ec50-4990-a7fe-be48bb5b693e=[MARFCAT DWT COIL,MAIN DST]gipsy.tier.tiertype.c341ab91-161e-419d-a7e4-6206e75ec097=DGTgipsy.tier.isgmt.29310d89-fd7a-498c-8a47-f80d3b5b9865=truegipsy.connection.name.36485580-5acf-4c12-9110-47c60e23ddc9=[MARFCAT DWT NETO,MAIN DST]gipsy.tier.posx.29310d89-fd7a-498c-8a47-f80d3b5b9865=74gipsy.tier.instance.89e6605e-5c81-4d95-bf51-8e7576c8dcd7=8f5d7614-49e9-4c8a-87fe-c8032a5c9009gipsy.connection.from.7802414d-437f-4382-9162-15d9d8e735c3=29310d89-fd7a-498c-8a47-f80d3b5b9865gipsy.tier.howmany.29310d89-fd7a-498c-8a47-f80d3b5b9865=1connection_key.6a9e123b-c375-4786-9d15-12faeee54c59=6a9e123b-c375-4786-9d15-12faeee54c59gipsy.tier.name.a409cb6b-ad54-41f6-af69-f4ec78628ec6=MARFCAT DWT COILgipsy.tier.instance.c341ab91-161e-419d-a7e4-6206e75ec097=8f5d7614-49e9-4c8a-87fe-c8032a5c9009gipsy.tier.tiertype.1523569d-25aa-44a4-97d5-370b93790333=DWTgipsy.tier.configfile.a409cb6b-ad54-41f6-af69-f4ec78628ec6=bin/multitier/DSTProfiles/marfcatDWT.configconnection_key.1eeea2b5-ec50-4990-a7fe-be48bb5b693e=1eeea2b5-ec50-4990-a7fe-be48bb5b693etier_key.a409cb6b-ad54-41f6-af69-f4ec78628ec6=a409cb6b-ad54-41f6-af69-f4ec78628ec6gipsy.connection.to.6a9e123b-c375-4786-9d15-12faeee54c59=77fd90ec-e49e-4977-a55b-0690e2e0cd08tier_key.89e6605e-5c81-4d95-bf51-8e7576c8dcd7=89e6605e-5c81-4d95-bf51-8e7576c8dcd7instance_key.8f5d7614-49e9-4c8a-87fe-c8032a5c9009=8f5d7614-49e9-4c8a-87fe-c8032a5c9009connection_key.36485580-5acf-4c12-9110-47c60e23ddc9=36485580-5acf-4c12-9110-47c60e23ddc9gipsy.tier.instance.77fd90ec-e49e-4977-a55b-0690e2e0cd08=8f5d7614-49e9-4c8a-87fe-c8032a5c9009gipsy.connection.to.1eeea2b5-ec50-4990-a7fe-be48bb5b693e=77fd90ec-e49e-4977-a55b-0690e2e0cd08gipsy.connection.from.0dd7156f-3b40-4df7-b9a9-d1b44eeb4da0=1523569d-25aa-44a4-97d5-370b93790333tier_key.c341ab91-161e-419d-a7e4-6206e75ec097=c341ab91-161e-419d-a7e4-6206e75ec097gipsy.tier.instance.1523569d-25aa-44a4-97d5-370b93790333=8f5d7614-49e9-4c8a-87fe-c8032a5c9009gipsy.connection.to.36485580-5acf-4c12-9110-47c60e23ddc9=77fd90ec-e49e-4977-a55b-0690e2e0cd08gipsy.node.ipaddress.3=132.205.8.235gipsy.node.ipaddress.2=132.205.8.235gipsy.tier.tiertype.29310d89-fd7a-498c-8a47-f80d3b5b9865=GMTgipsy.tier.name.89e6605e-5c81-4d95-bf51-8e7576c8dcd7=MARFCAT DWT NETOgipsy.node.ipaddress.1=132.205.8.235gipsy.tier.name.77fd90ec-e49e-4977-a55b-0690e2e0cd08=MAIN DSTgipsy.node.ipaddress.0=132.205.8.235gipsy.tier.configfile.89e6605e-5c81-4d95-bf51-8e7576c8dcd7=bin/multitier/DSTProfiles/marfcatDWT.configgipsy.tier.configfile.77fd90ec-e49e-4977-a55b-0690e2e0cd08=bin/multitier/DSTProfiles/p9.configtier_key.77fd90ec-e49e-4977-a55b-0690e2e0cd08=77fd90ec-e49e-4977-a55b-0690e2e0cd08gipsy.tier.name.c341ab91-161e-419d-a7e4-6206e75ec097=MARFCAT DGTgipsy.instance.name.8f5d7614-49e9-4c8a-87fe-c8032a5c9009=MARFCAT 4SOMEnode_key.3=3gipsy.tier.configfile.c341ab91-161e-419d-a7e4-6206e75ec097=/local/data/gipsy/cvscheckout/gipsy/gipsy/bin/multitier/marfcatDGT.configgipsy.node.ID.3=3node_key.2=2gipsy.node.ID.2=2node_key.1=1gipsy.instance.ID.8f5d7614-49e9-4c8a-87fe-c8032a5c9009=8f5d7614-49e9-4c8a-87fe-c8032a5c9009node_key.0=0gipsy.node.ID.1=1gipsy.node.ID.0=0gipsy.node.color.3=Lightbluegipsy.node.color.2=Tealgipsy.node.color.1=Bluegipsy.node.color.0=Greengipsy.tier.name.1523569d-25aa-44a4-97d5-370b93790333=MARFCAT DWT GLEAMgipsy.tier.configfile.1523569d-25aa-44a4-97d5-370b93790333=/local/data/gipsy/cvscheckout/gipsy/gipsy/bin/multitier/marfcatDWT.configtier_key.1523569d-25aa-44a4-97d5-370b93790333=1523569d-25aa-44a4-97d5-370b93790333gipsy.tier.ID.a409cb6b-ad54-41f6-af69-f4ec78628ec6=a409cb6b-ad54-41f6-af69-f4ec78628ec6gipsy.tier.instance.29310d89-fd7a-498c-8a47-f80d3b5b9865=8f5d7614-49e9-4c8a-87fe-c8032a5c9009gipsy.tier.node.a409cb6b-ad54-41f6-af69-f4ec78628ec6=3gipsy.connection.id.7802414d-437f-4382-9162-15d9d8e735c3=7802414d-437f-4382-9162-15d9d8e735c3gipsy.connection.name.7802414d-437f-4382-9162-15d9d8e735c3=[MAINGMT,MAIN DST]gipsy.tier.posy.a409cb6b-ad54-41f6-af69-f4ec78628ec6=398gipsy.tier.node.c341ab91-161e-419d-a7e4-6206e75ec097=0tier_key.29310d89-fd7a-498c-8a47-f80d3b5b9865=29310d89-fd7a-498c-8a47-f80d3b5b9865gipsy.connection.from.6a9e123b-c375-4786-9d15-12faeee54c59=c341ab91-161e-419d-a7e4-6206e75ec097gipsy.tier.ID.89e6605e-5c81-4d95-bf51-8e7576c8dcd7=89e6605e-5c81-4d95-bf51-8e7576c8dcd7gipsy.tier.ID.77fd90ec-e49e-4977-a55b-0690e2e0cd08=77fd90ec-e49e-4977-a55b-0690e2e0cd08gipsy.connection.from.1eeea2b5-ec50-4990-a7fe-be48bb5b693e=a409cb6b-ad54-41f6-af69-f4ec78628ec6gipsy.tier.posy.c341ab91-161e-419d-a7e4-6206e75ec097=406gipsy.connection.id.0dd7156f-3b40-4df7-b9a9-d1b44eeb4da0=0dd7156f-3b40-4df7-b9a9-d1b44eeb4da0gipsy.tier.ID.c341ab91-161e-419d-a7e4-6206e75ec097=c341ab91-161e-419d-a7e4-6206e75ec097gipsy.tier.node.89e6605e-5c81-4d95-bf51-8e7576c8dcd7=2gipsy.tier.node.77fd90ec-e49e-4977-a55b-0690e2e0cd08=0gipsy.tier.name.29310d89-fd7a-498c-8a47-f80d3b5b9865=MAINGMTgipsy.connection.from.36485580-5acf-4c12-9110-47c60e23ddc9=89e6605e-5c81-4d95-bf51-8e7576c8dcd7gipsy.tier.configfile.29310d89-fd7a-498c-8a47-f80d3b5b9865=/local/data/gipsy/cvscheckout/gipsy/gipsy/bin/multitiermarfcat/GMTNode.configgipsy.connection.name.0dd7156f-3b40-4df7-b9a9-d1b44eeb4da0=[MARFCAT DWT GLEAM,MAIN DST]connection_key.7802414d-437f-4382-9162-15d9d8e735c3=7802414d-437f-4382-9162-15d9d8e735c3gipsy.tier.posy.89e6605e-5c81-4d95-bf51-8e7576c8dcd7=224gipsy.tier.posy.77fd90ec-e49e-4977-a55b-0690e2e0cd08=222gipsy.tier.isgmt.a409cb6b-ad54-41f6-af69-f4ec78628ec6=falsegipsy.tier.posy.29310d89-fd7a-498c-8a47-f80d3b5b9865=53gipsy.tier.ID.29310d89-fd7a-498c-8a47-f80d3b5b9865=29310d89-fd7a-498c-8a47-f80d3b5b9865gipsy.tier.isgmt.1523569d-25aa-44a4-97d5-370b93790333=falsegipsy.connection.id.6a9e123b-c375-4786-9d15-12faeee54c59=6a9e123b-c375-4786-9d15-12faeee54c59gipsy.tier.posx.1523569d-25aa-44a4-97d5-370b93790333=409gipsy.tier.instance.a409cb6b-ad54-41f6-af69-f4ec78628ec6=8f5d7614-49e9-4c8a-87fe-c8032a5c9009gipsy.tier.howmany.1523569d-25aa-44a4-97d5-370b93790333=1gipsy.connection.name.6a9e123b-c375-4786-9d15-12faeee54c59=[MARFCAT DGT,MAIN DST]gipsy.tier.tiertype.89e6605e-5c81-4d95-bf51-8e7576c8dcd7=DWTgipsy.tier.tiertype.77fd90ec-e49e-4977-a55b-0690e2e0cd08=DSTgipsy.connection.id.36485580-5acf-4c12-9110-47c60e23ddc9=36485580-5acf-4c12-9110-47c60e23ddc9gipsy.connection.name.1eeea2b5-ec50-4990-a7fe-be48bb5b693e=[MARFCAT DWT COIL,MAIN DST]gipsy.tier.tiertype.c341ab91-161e-419d-a7e4-6206e75ec097=DGTgipsy.tier.isgmt.29310d89-fd7a-498c-8a47-f80d3b5b9865=truegipsy.connection.name.36485580-5acf-4c12-9110-47c60e23ddc9=[MARFCAT DWT NETO,MAIN DST]gipsy.tier.posx.29310d89-fd7a-498c-8a47-f80d3b5b9865=74gipsy.tier.instance.89e6605e-5c81-4d95-bf51-8e7576c8dcd7=8f5d7614-49e9-4c8a-87fe-c8032a5c9009gipsy.connection.from.7802414d-437f-4382-9162-15d9d8e735c3=29310d89-fd7a-498c-8a47-f80d3b5b9865gipsy.tier.howmany.29310d89-fd7a-498c-8a47-f80d3b5b9865=1connection_key.6a9e123b-c375-4786-9d15-12faeee54c59=6a9e123b-c375-4786-9d15-12faeee54c59gipsy.tier.name.a409cb6b-ad54-41f6-af69-f4ec78628ec6=MARFCAT DWT COILgipsy.tier.instance.c341ab91-161e-419d-a7e4-6206e75ec097=8f5d7614-49e9-4c8a-87fe-c8032a5c9009gipsy.tier.tiertype.1523569d-25aa-44a4-97d5-370b93790333=DWTgipsy.tier.configfile.a409cb6b-ad54-41f6-af69-f4ec78628ec6=bin/multitier/DSTProfiles/marfcatDWT.configconnection_key.1eeea2b5-ec50-4990-a7fe-be48bb5b693e=1eeea2b5-ec50-4990-a7fe-be48bb5b693etier_key.a409cb6b-ad54-41f6-af69-f4ec78628ec6=a409cb6b-ad54-41f6-af69-f4ec78628ec6gipsy.connection.to.6a9e123b-c375-4786-9d15-12faeee54c59=77fd90ec-e49e-4977-a55b-0690e2e0cd08tier_key.89e6605e-5c81-4d95-bf51-8e7576c8dcd7=89e6605e-5c81-4d95-bf51-8e7576c8dcd7instance_key.8f5d7614-49e9-4c8a-87fe-c8032a5c9009=8f5d7614-49e9-4c8a-87fe-c8032a5c9009connection_key.36485580-5acf-4c12-9110-47c60e23ddc9=36485580-5acf-4c12-9110-47c60e23ddc9gipsy.tier.instance.77fd90ec-e49e-4977-a55b-0690e2e0cd08=8f5d7614-49e9-4c8a-87fe-c8032a5c9009gipsy.connection.to.1eeea2b5-ec50-4990-a7fe-be48bb5b693e=77fd90ec-e49e-4977-a55b-0690e2e0cd08gipsy.connection.from.0dd7156f-3b40-4df7-b9a9-d1b44eeb4da0=1523569d-25aa-44a4-97d5-370b93790333tier_key.c341ab91-161e-419d-a7e4-6206e75ec097=c341ab91-161e-419d-a7e4-6206e75ec097gipsy.tier.instance.1523569d-25aa-44a4-97d5-370b93790333=8f5d7614-49e9-4c8a-87fe-c8032a5c9009gipsy.connection.to.36485580-5acf-4c12-9110-47c60e23ddc9=77fd90ec-e49e-4977-a55b-0690e2e0cd08gipsy.node.ipaddress.3=132.205.8.235gipsy.node.ipaddress.2=132.205.8.235gipsy.tier.tiertype.29310d89-fd7a-498c-8a47-f80d3b5b9865=GMTgipsy.tier.name.89e6605e-5c81-4d95-bf51-8e7576c8dcd7=MARFCAT DWT NETOgipsy.node.ipaddress.1=132.205.8.235gipsy.tier.name.77fd90ec-e49e-4977-a55b-0690e2e0cd08=MAIN DSTgipsy.node.ipaddress.0=132.205.8.235gipsy.tier.configfile.89e6605e-5c81-4d95-bf51-8e7576c8dcd7=bin/multitier/DSTProfiles/marfcatDWT.configgipsy.tier.configfile.77fd90ec-e49e-4977-a55b-0690e2e0cd08=bin/multitier/DSTProfiles/p9.configtier_key.77fd90ec-e49e-4977-a55b-0690e2e0cd08=77fd90ec-e49e-4977-a55b-0690e2e0cd08gipsy.tier.name.c341ab91-161e-419d-a7e4-6206e75ec097=MARFCAT DGTgipsy.instance.name.8f5d7614-49e9-4c8a-87fe-c8032a5c9009=MARFCAT 4SOMEnode_key.3=3gipsy.tier.configfile.c341ab91-161e-419d-a7e4-6206e75ec097=/local/data/gipsy/cvscheckout/gipsy/gipsy/bin/multitier/marfcatDGT.configgipsy.node.ID.3=3node_key.2=2gipsy.node.ID.2=2node_key.1=1gipsy.instance.ID.8f5d7614-49e9-4c8a-87fe-c8032a5c9009=8f5d7614-49e9-4c8a-87fe-c8032a5c9009node_key.0=0gipsy.node.ID.1=1gipsy.node.ID.0=0gipsy.node.color.3=Lightbluegipsy.node.color.2=Tealgipsy.node.color.1=Bluegipsy.node.color.0=Greengipsy.tier.name.1523569d-25aa-44a4-97d5-370b93790333=MARFCAT DWT GLEAMgipsy.tier.configfile.1523569d-25aa-44a4-97d5-370b93790333=/local/data/gipsy/cvscheckout/gipsy/gipsy/bin/multitier/marfcatDWT.configtier_key.1523569d-25aa-44a4-97d5-370b93790333=1523569d-25aa-44a4-97d5-370b93790333gipsy.tier.ID.a409cb6b-ad54-41f6-af69-f4ec78628ec6=a409cb6b-ad54-41f6-af69-f4ec78628ec6gipsy.tier.instance.29310d89-fd7a-498c-8a47-f80d3b5b9865=8f5d7614-49e9-4c8a-87fe-c8032a5c9009gipsy.tier.node.a409cb6b-ad54-41f6-af69-f4ec78628ec6=3gipsy.connection.id.7802414d-437f-4382-9162-15d9d8e735c3=7802414d-437f-4382-9162-15d9d8e735c3gipsy.connection.name.7802414d-437f-4382-9162-15d9d8e735c3=[MAINGMT,MAIN DST]gipsy.tier.posy.a409cb6b-ad54-41f6-af69-f4ec78628ec6=398gipsy.tier.node.c341ab91-161e-419d-a7e4-6206e75ec097=0tier_key.29310d89-fd7a-498c-8a47-f80d3b5b9865=29310d89-fd7a-498c-8a47-f80d3b5b9865gipsy.connection.from.6a9e123b-c375-4786-9d15-12faeee54c59=c341ab91-161e-419d-a7e4-6206e75ec097gipsy.tier.ID.89e6605e-5c81-4d95-bf51-8e7576c8dcd7=89e6605e-5c81-4d95-bf51-8e7576c8dcd7gipsy.tier.ID.77fd90ec-e49e-4977-a55b-0690e2e0cd08=77fd90ec-e49e-4977-a55b-0690e2e0cd08gipsy.connection.from.1eeea2b5-ec50-4990-a7fe-be48bb5b693e=a409cb6b-ad54-41f6-af69-f4ec78628ec6gipsy.tier.posy.c341ab91-161e-419d-a7e4-6206e75ec097=406gipsy.connection.id.0dd7156f-3b40-4df7-b9a9-d1b44eeb4da0=0dd7156f-3b40-4df7-b9a9-d1b44eeb4da0gipsy.tier.ID.c341ab91-161e-419d-a7e4-6206e75ec097=c341ab91-161e-419d-a7e4-6206e75ec097gipsy.tier.node.89e6605e-5c81-4d95-bf51-8e7576c8dcd7=2gipsy.tier.node.77fd90ec-e49e-4977-a55b-0690e2e0cd08=0gipsy.tier.name.29310d89-fd7a-498c-8a47-f80d3b5b9865=MAINGMTgipsy.connection.from.36485580-5acf-4c12-9110-47c60e23ddc9=89e6605e-5c81-4d95-bf51-8e7576c8dcd7gipsy.tier.configfile.29310d89-fd7a-498c-8a47-f80d3b5b9865=/local/data/gipsy/cvscheckout/gipsy/gipsy/bin/multitiermarfcat/GMTNode.configgipsy.connection.name.0dd7156f-3b40-4df7-b9a9-d1b44eeb4da0=[MARFCAT DWT GLEAM,MAIN DST]connection_key.7802414d-437f-4382-9162-15d9d8e735c3=7802414d-437f-4382-9162-15d9d8e735c3gipsy.tier.posy.89e6605e-5c81-4d95-bf51-8e7576c8dcd7=224gipsy.tier.posy.77fd90ec-e49e-4977-a55b-0690e2e0cd08=222gipsy.tier.isgmt.a409cb6b-ad54-41f6-af69-f4ec78628ec6=false