DirkReske.de

Overview

After I looked around the web, I’ve found a few good howto’s about glassfish cluster configuration, but either they use only single machine clusters or they have some other disadvantages in my eyes. So I’ve decided to write my own article about this.

This article will describes how to set up a two machine cluster which consists of the domain administration server (DAS) and a “normal” node. Thereby the DAS also works as such a normal node.

This article uses Glassfish v2.1.

Before the installation

You have to ensure, that your network is configured properly, especially the dns system. If there are problems, there will be curious problems while setting all up. I’ve done this using the hosts file.

10.0.0.1   das-host
10.0.0.2   node2-host
10.0.0.x   nodex-host

The next thing is the firewall. The nodes communicating using a couple of ports. For setup and testing I’ve configured my firewalls to accept everything from all the other nodes, so there are no problems for the nodes to communicate with each other.

Setting up the DAS

Because the DAS server needs cluster support, we have to configure this first.
There are two ways to do this.

• install the glassfish server using:

  ant -f setup-cluster.xml

• activate cluster support using the admin console
  1. go the the admin console (e.g. http://localhost:4848)
  2. select from the common task: Enable Cluster Support

Now start up the server using:

asadmin start-domain domain1

In the next steps, I will create the cluster, then a node-agent and one instance running on the DAS server using the cli.

In most cases you have to specifiy your admin username and password. This can be done using the –user and –passwordfile parameters, but for simpler reading I will omit this. The server will ask you in this case.

1. Create the cluster:

   asadmin create-cluster cluster1

   This creates a cluster on the local server (the DAS) with the name cluster1.

2. Create the node agent:

   asadmin create-node-agent das-agent

   This will create the node agent for the current node.

3. Create the instance for the current node:

   asadmin create-instance --nodeagent das-agent --cluster cluster1 instance1

   This will create the instance instance1 associated with the node agent das-agent and the cluster cluster1.

4. Now start up the node agent and the associated instance:

   asadmin start-node-agent --syncinstances=true --startinstances=true das-agent

   • –syncinstances=true says that the node agent should synchronize its instances with the central repository of the DAS
   • –startinstances=true says the the node agent should start all its instances (instance1 in our case)

Now the domain administration server is up and running.
The first node is also running.

Setting up the second node

Now come to setup the second node.
Because the second node should only work a “computing” node, we do not need to install the whole application server, just a node agent.
I omit user and password parameters here too. You have to enter the DAS login informations when asked for.

1. Install the node agent:

   ant -f setup-cluster.xml create-node-agent -Ddas.host=das-host -Dnodeagent.name=node2-agent

   • -Ddas.host=das-host sets the hostname of the domain administration server
   • -Dnodeagent.name=node2-agent sets the name of the local node agent
2. Create the new instance:

   asadmin create-instance --host das-host --nodeagent node2-agent --cluster cluster1 instance2

   This will create the new instance associated with the node agent node2-agent and the cluster cluster1. The –host parameter specifies the hostname of the domain administration server.

3. Start the instance:

   asadmin start-node-agent --syncinstances=true --startinstances=true node2-agent

   Now the local node agent starts, synchronizes with the das server and starts all local instances (only instance2 in our case)

Now your cluster is running with two nodes. To add more nodes, just repeat the three above steps as much as you want.

Deploying applications to the cluster

For deploying applications to the cluster, just type on the das server

asadmin deploy --user admin --target cluster1 MyApplication.ear

This will deploy the application to the whole cluster.

For further reading

• Enable glassfish session replication
• create-cluster command
• create-node-agent command
• create-instance command
• start-node-agent command

The Workflow Editor is a part of the net-linx application nxApex. The users of this application are phone directory publishers. Service order is a process to import customer information like address, phone number, placement information, etc and to create and update the existing information in the customer database by creating, deleting or updating this information.

This is a rather complex process and it is different from publisher to publisher. In the past the service order module has been customized for each publisher.

The new workflow editor is used to edit flexible workflows that can be adopted easily by configuration personnel. On the development of this module external student apprentices took part together with experienced internal Java developers.

Workflow Overview

The Workflow Editor is meant for system administrator use only. The information provided in this module is technical and not meant for end user’s view.

The workflow for service order and other DAQ processes is specified in workflow configuration file.
The workflow configuration file contains all workflows. A workflow is always bound to a record type. You can define more than one workflow for a record type. The workflow which should be used must be marked as default.

A workflow can contain the following items: transformation items, validation items, search items and processing items, process flow items, and actions.

All changes made to the record data during the processing of the workflow are discarded after the workflow is finished if not otherwise specified. (See transformation item). Changes made to the administrative data (status, status messages) are saved to the database.

A workflow defines the sequence in which the rules should be processed and the actions depending on the output value of one rule. Rules are for example matching rules.

A workflow consists of a list of workflow items. These workflow items define the rules which should be used and the actions which should be taken on a specific rule output.
If no action is defined for a specific output value is defined, a default action will be used.
The default action for the output values ‘NotUsed’ and ‘Ok’ is ‘Goto Next Item’. The default action for ‘Error’ is ‘Reject Immediate’.
Every action is defined by an action code and a number of parameters.

PathFinder is an application for visualizing path finding algorithms written in by Armin and me.

The source code of pathfinder was published at sourceforge.net (project page).

The application can visualize the whole calculation of the implemented path finding algorithms.
These algorithms are:

• A*
• Depth first
• Breadth first
• Hill climbing
• Beam search
• British museum
• Branch and bound
• Dijkstra
• Depth limited
• Great deluge

Because of a very generic and abstract application design it is very simple to add new algorithms to the repository.

The core data model of PathFinder is a more or less simple graph (nodes connected by edges), that can be overlayed by an image for better visualization (e.g. a map like in the upper picture).
The algorithms try to find a path from a start node to a destination nodes. Depending on the choosen algorithm this path should be the shortest path or just one path. Using the build in graph editor (picture below), the user is able to simply create own graphs.

The most of these algorithms can be heavily parameterized to control the way the algorithm works.
While working, the algorithm notifies the application about each calculation step. So, after the algorithm completes, the user is able to re-run the calculation in every speed or just step by step.
This is great for understandig how a algorithm works or to look for weaknesses in a new algorithm.

After a calculation completes, also some statistics are stored in a history.
Some of these values are:

• Time for calculation
• Steps in the graph model
• Length of the path (and the air distance between start and destination for comparison)
• Count of backtracking nodes (this are nodes visited by the algorithm for calculation but not used in the path)
• The parameters given to the algorithm

Using the history, it is possible to compare differend algorithms or different parameters with each other.
Therefore the pure statistic values can be compared, or the paths can be viewed together on the same graph. So it is very easy to see the differences of algorithms or the impacts of parameters.

The application is written completely in Java (1.6 standard edition) and was part of a projekt at our university.