Monday Feb 15, 2010

GlassFish v2 Offline Configuration

Review of Clustering Features in GlassFish v2

A typical GlassFish v2 enterprise installation consists of one administration domain controlled by the Domain Administration Server (DAS) which handles all of the administration duties of the domain.  The  domain provides a common  authentication and administration point for a collection of Java EE server instances.

Each JavaEE server instance gets it's configuration from DAS and has its lifecycle controlled by a Node Agent.  A Node Agent is a very light-weight process that DAS interacts with.  Node Agents and remote Java EE server instances synchronize with DAS during startup to get the latest configuration from the central repository managed by DAS.

GlassFish v2 supports the concept of cluster where multiple Java EE server instances can be grouped for horizontal scalability. Each Java EE server instance in a cluster shares the same set of applications and configuration information.

Typical Configuration

Say you have a running DAS (Domain Administration Server) and you wish to add a cluster, a few instances and a Node Agent running on a separate machine.  Here is how you would do an online configuration:

  1. Login to the new Node Agent machine
  2. asadmin create-node-agent NA-Name
  3. asadmin create-cluster
  4. asadmin create-instance (probably need to run this command a few times)
  5. asadmin start-node-agent

 You can see how if you have a lot of machines this can become a headache.  Note that create-instance has many required parameters that I'm not showing here.

Offline Configuration

Offline Configuration lets you do all of the configuration right from the DAS machine.  On each Node Machine you run two very simple commands:

  • asadmin create-node-agent NA-Name
  • asadmin start-node-agent NA-Name

There are several good reasons for developing scripts for offline configuration of complex GlassFish installations:

  • You can develop scripts that will exactly recreate your system from scratch.  I'm talking about deploying your applications, setting complicated jvm-options, configuring database connections, setting up multiple clusters and instances -- the works!  This is very powerful.  I have a personal website that has been running v2 for 4 years or so.  I can recreate the entire site anytime I like on any new machine that has v2 installed.  It has a ton of applications, a database, etc.
  • You need the complicated configuration information to be used on just one machine, DAS, in a multiple machine installation.
  • You can replace a Node easily at any time
  • No restarts are needed during the creation of the instance, cluster and node-agent configuration since it is all being done offline.  Once ALL of the configuration is complete everything is started at once and no restarts will be needed.  This is a key difference with online configuration.
  • Faster to automate a multi-node GlassFish cluster setup with desired configuration.
  • It works!

Example Offline Configuration Session

Generally one would want to edit a script and run the script.  Here is a an example session to show you how to do it from a command line:

(For clarity the credentials such as --user and --passwordfile are left out of the commands)

  • asadmin start-domain
  • asadmin create-cluster c1
  • asadmin create-node-agent-config na1
  • asadmin create-node-agent-config na2
  • asadmin create-instance --cluster c1 --node-agent na1 i1_1
  • asadmin create-instance --cluster c1 --node-agent na2 i2_1
  • asadmin create-instance --cluster c1 --node-agent na2 i2_2

We didn't start anything.  All of the commands changed the configuration in the domain.xml.  Namely it created 1 new cluster with 2 node agents and a total of 3 instances.

To get everything running we do this:

  • For each machine (in this case 2 separate remote machines with v2 binaries installed)
    • asadmin create-node-agent na1 or na2
    • asadmin start-node-agent na1 or na2
    • note: the Node Agent name must match exactly the name in create-node-agent-config above.  Otherwise you will get a new Node Agent created!

Example Script

Kedar Mhaswade created  the attached example shell script.  The script demonstrates how you can automate building a four-machine Enterprise GlassFish v2 Installation.


Tuesday Apr 24, 2007

Tip #-3 How to Debug Clustered AppServer Instances

There used to be a big problem in trying to attach a debugger to a clustered server instance in Glassfish.  As of today (build 45), it is a snap to do it!

The problem was that a cluster config could only specify one debugging port.  This would work if you started one and only one server instance.  As soon as you tried to start a second instance it would try to use the same jdwp port and it would fail to launch.  It was (almost) impossible to debug 2 instances on the same machine at the same time.

The solution is to defer the actual port number selection.  I.e. the instance needs to choose its own port.  Each instance specifies a different port and, voila, problem solved.

Here is how to do it:

1. Enable debugging support for the cluster
We are using a cluster named c1.  First make sure that debugging is enabled for the cluster:

asadmin set

2. Set a variable debugging port

The syntax is ugly.  Don't bother memorizing just do a get to see it, edit it and then do a set on the result like so: 

asadmin get = -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=9009
asadmin set"-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=${DEBUG_PORT}"
Don't forget the double quotes, and no spaces around the equals sign!

 Another Tip:  asadmin get "\*" > afile is handy.  You can then grep for 'debug' in the file.  I use this technique all the time.  What human being wants to memorize this sort of crushing detail?

3. Set the instances' debugging ports

 In this case we have 2 instances, i1 and i2.  We will make the debugging ports 11111 and 22222 respectively:

GlassFish v2.x:

asadmin set i1.system-property.DEBUG_PORT=11111
i1.system-property.DEBUG_PORT = 11111
asadmin set i2.system-property.DEBUG_PORT=22222
i2.system-property.DEBUG_PORT = 22222

The above does NOT work in GlassFish 3.X.  Instead use the following commands:

asadmin create-system-properties --target i1 DEBUG_PORT=11111
asadmin create-system-properties --target i2 DEBUG_PORT=22222

That's it.  You're ready to debug multiple instances.




« July 2016