Skip to main content

Glassfish 4, cluster + sticky sessions

2 replies [Last post]
markbto
Offline
Joined: 2013-04-16
Points: 0

Hello,

Trying to set up (in a test environment) a two-server Glassfish 4 cluster in readiness from migrating from our existing single-instance Glassfish 3.1 webserver to one that supported load balancing and failover.

Primarily an application writer, the noddy-GUI interface of Glassfish looked enticing to me. In practice I have been unable to get a Glassfish 4 cluster working correct and wondered if someone could give me the configuration that I needed. There are many blogs and guides describing the process, but they are all slightly different, for different versions of Glassfish, and none of them appear to work on GF4.

The setup:

Server 1: app01
To house DAS, and NODE01->INSTANCE0101(SSH)

Server 2: app02
To house NODE02-INSTANCE0102(SSH)

Cluster: CLUSTER01, involving NODE01->INSTANCE0101 and NODE02->INSTANCE0102

Having set up the two servers, java, and installed Glassfish 4 on app01. Have installed Apache on app01.
Our old server used Apache and mod_jk to forward appropriate requests to Glassfish. I had made the appropriate change in /etc/httpd/conf/httpd.conf to forward requests to jk-connector: (pulled from appropriate sections)

LoadModule jk_module modules/mod_jk.so

JkWorkersFile /etc/httpd/conf/workers.properties
JkLogFile /var/log/httpd/mod_jk.log
JkLogLevel error
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
JkOptions +ForwardKeySize +ForwardURICompat "ForwardDirectories

JkMount /* loadbalancer

This is what I "thought- was appropriate for workers.properties from all of the blog posts.

worker.list=loadbalancer

# default properties for workers
worker.template.type=ajp13
worker.template.lbfactor=50
worker.template.connection_pool_timeout=600
worker.template.socket_keepalive=1
worker.template.socket_timeout=300

# properties for worker1
worker.worker1.reference=worker.template
worker.worker1.host=app01.btodomain.bto.org
worker.worker1.port=8009

# properties for worker2
worker.worker2.reference=worker.template
worker.worker2.host=app02.btodomain.bto.org
worker.worker2.port=8010

# properties for loadbalancer
worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=worker1,worker2

Glassfish configuration I believed appropriate:

create-jvm-options --target cluster01 "-DjvmRoute=\\${AJP_INSTANCE_NAME}"
create-jvm-options --target cluster01 "-Dcom.sun.enterprise.web.connector.enableJK=\\${AJP_PORT}"
create-system-properties --target instance0101 AJP_INSTANCE_NAME=instance0101
create-system-properties --target instance0102 AJP_INSTANCE_NAME=instance0102
create-system-properties --target instance0101 AJP_PORT=8009
create-system-properties --target instance0102 AJP_PORT=8010
create-network-listener --protocol http-listener-1 --listenerport “${AJP_PORT}” --jkenabled true --target cluster01 jk-connector

In addition to the configuration not working, when fiddling with the settings, I’ve twice ended up in a situation where test applications will not redeploy or un-deploy/deploy with Glassfish claiming that an application by the same name already existing (when it doesn’t)

Any help would be appreciated.

Mark

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
elioengcomp
Offline
Joined: 2010-07-01
Points: 0

Hi Mark,

For session afinity to work, you have to use the same name of your workers to set jvmRoute parameter on your instances.

Look for a comment done at October 7, 2011 at 10:56 PM at this url: http://tiainen.sertik.net/2011/03/load-balancing-with-glassfish-31-and.html

I hope it helps you!

markbto
Offline
Joined: 2013-04-16
Points: 0

Hi,

I had seen the URL you mentioned previously. The configuration in the body of the document, and the configuration mentioned in the comments are completely different, but have one thing in common: neither are Glassfish 4 specific, and neither work