DirkReske.de » javaee

Glassfish load balancing using mod_proxy_balancer

Dirk Reske — Sun, 26 Sep 2010 15:28:06 +0000

Overview

In my previous article about configuring a glassfish load balancer, I’ve used the mod_jk connector for the apache webserver.
These time I’m going to show, how to solve this using the mod proxy balancer plugin shipped with the most apache installations. (A “cleaner” way in my oppinion)

A couple of times I’ve tried to get the Sun load balancing plugin working, but without success. This was because of some operating system issues or other problems.
So after looking around the web, I’ve found some good solutions using apache and the mod_jk connector from the apache tomcat project.

Requirements

Recent glassfish installation (I use v2.1.1).
mod_jk tomcat connector.
Apache tomcat server to get some files from (Use version 5.5.23, others won’t work).
Apache commons logging
Apache commons modeler

Installation

Configuring the glassfish cluster
1. Copy the $CATALINA_HOME/server/lib/tomcat-ajp.jar to your $GLASSFISH_HOME/lib directory on each glassfish installation in your cluster.
2. Also copy the commons-logging.jar and commons-modeler.jar to your $GLASSFISH_HOME/lib directory on each glassfish installation in your cluster.
3. Now you have to define jvmRoute and com.sun.enterprise.web.connector.enableJK system properties for the cluster (this can be done from the domain administration server)
```
asadmin create-jvm-options --target cluster1 "-DjvmRoute=\${AJP_INSTANCE_NAME}"
asadmin create-jvm-options --target cluster1 "-Dcom.sun.enterprise.web.connector.enableJK=\${AJP_PORT}"
```
4. Now you have to define the values for these properties for each instance running in the cluster (this can also be done from the domain administration server).
  This is needed, because the instance name, the user is working on has to be appended to the session id.
```
asadmin create-system-properties --target instance1 AJP_INSTANCE_NAME=instance1
asadmin create-system-properties --target instance1 AJP_PORT=8020
```
Configuring the apache web server
1. Enable mod_proxy, mod_proxy_http and mod_proxy_balancer on your apache installation.
2. Create a virtual-host (or use your main server), and copy the following lines to i.
  Be aware, that the route parameters matches the instance names assigned in the previous steps.
```
ProxyRequests       Off
ProxyPreserveHost   On


  Order deny,allow
  Allow from all


    
  SetHandler balancer-manager 
  ProxyPass !  
  Order deny,allow
  Allow from all



  BalancerMember http://192.168.0.10:38080 route=instance1
  BalancerMember http://192.168.0.11:38080 route=instance2
  BalancerMember http://192.168.0.12:38080 route=instance3



  ProxyPass balancer://cluster/ lbmethod=byrequests stickysession=JSESSIONID|jsessionid
```
3. Restart all cluster instances and the web server. Your load balancing should be working now.
  Each time a new session is creted by the glassfish, it appends its instance name to the JSESSIONID, so the load balancer can determine on which instance to route the request.
  If one instance crashes, the load balancer will notice this and redirects all requests to another instance. If you have enabled session replication, your old session will be resumed there.
Further reading

Designer friendly JSF using jsfc attribute

Dirk Reske — Tue, 13 Apr 2010 16:47:35 +0000

Have you ever tried to edit your jsf code using a visual designer like dreamweaver? Or do you get your html layout from a professional designer and have to “translate” it to jsf?

In the first case, most times it will be look very strange, because the designer doesn’t understand the jsf tags and so it don’t know how to display it.

If you want to create a fast jsf prototype of your html layout you can use the jsfc attribute provided by the facelets compiler. By adding this attribute to standard html tags, you can tell the compiler, in which jsf component it has to “translate” the html component.

See the following simple html example:

1
2
3
4
5
6
7
8
9
10
<table>

  <tr>

    <td><strong>Name</strong></td>

    <td><strong>eMail</strong></td>

  </tr>

  <tr>

    <td>John Doe</td>

    <td>jon@doe.de</td>

  </tr>

</table>

You can convert this by replacing all with a h:dataTable tag, or you can use the jsfc attribute in several ways.
One way could be:

1
2
3
4
5
6
7
8
9
10
<table>

  <tr>

    <td><b>Name</b></td>

    <td><b>eMail</b></td>

  </tr>

  <tr jsfc="ui:repeat" value="#{userListBean.users}" var="user">

    <td>#{user.name}</td>

    <td>#{user.email}</td>

  </tr>

</table>

You see, there is no jsf tag in this code. Sou you can edit this html using your favorite designer, it will simply ignore the unknown attributes.

Another way would be, telling the facelets compiler to render the table as a h:dataTable, but because of the header row, you’ll have to use the f:facet tag.

1
2
3
4
5
6
7
8
9
10
11
12
<table jsfc="h:dataTable" value="#{userListBean.users}" var="user">

  <tr>

    <td jsfc="h:column">

      name="header">Username</f:facet>

      #{user.name}

    </td>

    <td jsfc="h:column">

      name="header">eMail</f:facet>

      #{user.email}

    </td>

  </tr>

</table>

So this way you still have to use jsf tags and so the visual designer can’t interpret it correctly.

Load balancing glassfish using apache

Dirk Reske — Sat, 31 Oct 2009 23:19:48 +0000

Overview

After my articles about setting up a glassfish cluster and enable session replication, its now time to put a load balancer in front of it.

Requirements

Recent glassfish installation (I use v2.1.1).
mod_jk tomcat connector.
Apache tomcat server to get some files from (Use version 5.5.23, others won’t work).
Apache commons logging
Apache commons modeler

Installation

Configuring the glassfish cluster
1. Copy the $CATALINA_HOME/server/lib/tomcat-ajp.jar to your $GLASSFISH_HOME/lib directory on each glassfish installation in your cluster.
2. Also copy the commons-logging.jar and commons-modeler.jar to your $GLASSFISH_HOME/lib directory on each glassfish installation in your cluster.
3. Now you have to define jvmRoute and com.sun.enterprise.web.connector.enableJK system properties for the cluster (this can be done from the domain administration server)
```
asadmin create-jvm-options --target cluster1 "-DjvmRoute=\${AJP_INSTANCE_NAME}"
asadmin create-jvm-options --target cluster1 "-Dcom.sun.enterprise.web.connector.enableJK=\${AJP_PORT}"
```
4. Now you have to define the values for these properties for each instance running in the cluster (this can also be done from the domain administration server)
```
asadmin create-system-properties --target instance1 AJP_INSTANCE_NAME=instance1
asadmin create-system-properties --target instance1 AJP_PORT=8020
```
Configuring the apache web server
1. Copy the mod_jk.so to a apache accessible directory.
2. Copy the following lines to your apache main config file.
```
LoadModule jk_module 
JkWorkersFile 
JkLogFile 
JkLogLevel debug
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
JkOptions +ForwardURICompat -ForwardDirectories
JkRequestLogFormat "%w %V %T"
```
3. Copy the following lines to your virtual host configuration (or into the main config, if you don’t use virtual hosts).
```
JkMount /* loadbalancer
```
4. This will redirect all requests to your load balancer. (You can also use patterns like /*.jsp for only redirecting jsp file request to the load balancer or just any other sensefull pattern).

Writing your worker.properties configuration file.

worker.list=loadbalancer

# Set properties for instance1
worker.instance1.type=ajp13
worker.instance1.host=
worker.instance1.port=
worker.instance1.lbfactor=50
worker.instance1.connection_pool_size=10
worker.instance1.connection_pool_timeout=600
worker.instance1.socket_keepalive=1
worker.instance1.socket_timeout=300

# Set properties for instance2
worker.instance2.type=ajp13
worker.instance2.host=
worker.instance2.port=
worker.instance2.lbfactor=50
worker.instance2.connection_pool_size=10
worker.instance2.connection_pool_timeout=600
worker.instance2.socket_keepalive=1
worker.instance2.socket_timeout=300

worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=instance1,instance2

Restart all cluster instances and the web server. Your load balancing should be working now.
Each time a new session is creted by the glassfish, it appends its instance name to the JSESSIONID, so the load balancer can determine on which instance to route the request.
If one instance crashes, the load balancer will notice this and redirects all requests to another instance. If you have enabled session replication, your old session will be resumed there.

Enable glassfish session replication

Dirk Reske — Sat, 31 Oct 2009 00:31:47 +0000

Overview

One of the high availability methods provided by glassfish, is session replication.
With session replication enabled, the server distributes session data across the cluster. If one cluster instances crashes, the session is still available on the other instances.

Requirements

A recent glassfish installation (versions prior to 2.1.1 had some bugs).
A configured cluster (Look here who to install a glassfish cluster).
All cluster instances located in the same subnet. (later glassfish version should support different subnets)

Configure session replication

Add a tag to your web.xml
```
  
  ...
```
Add following lines to your sun-web.xml
```
  
    
      
    
    
      
    
  
```
- persistenceType=”replicated” says, that the session should be replicated along the cluster.
- persistenceFrequency=”web-method” says that the session state should be stored after processing a request, but before sending the response. (other values: time-based)
- persistenceScope=”session” says that the whole session state should be stored. (other values: modified-session, modified-attribute)
Deploy application
- using the web-interface: check the Availability checkbox.
- using the cli: add –availabilityenabled=true parameter.

Notes

Be sure that all classes that are going to be stored in a session implements the Serializable interface.
If not, the server can’t serialize it and replication won’t work.
As already mentioned, the instances have to be on the same subnet, otherwise session replication will not work.

Glassfish cluster configuration

Dirk Reske — Sun, 25 Oct 2009 23:00:13 +0000

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.

Create the cluster:
```
asadmin create-cluster cluster1
```
This creates a cluster on the local server (the DAS) with the name cluster1.
Create the node agent:
```
asadmin create-node-agent das-agent
```
This will create the node agent for the current node.
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.
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.

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
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.
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

nxApex Workflow Editor

Dirk Reske — Sun, 25 Oct 2009 19:04:10 +0000

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.

DirkReske.de » javaee

Glassfish load balancing using mod_proxy_balancer

Overview

Requirements

Installation

Further reading

Designer friendly JSF using jsfc attribute

Load balancing glassfish using apache

Overview

Requirements

Installation

Further reading

Enable glassfish session replication

Overview

Requirements

Configure session replication

Notes

Further reading

Glassfish cluster configuration

Overview

Before the installation

Setting up the DAS

Setting up the second node

Deploying applications to the cluster

For further reading

nxApex Workflow Editor

Workflow Overview