A simple approach for Sun Message Queue Clustering

Introduction on Clustering

Today's enterprise depends on the availability of mail and web services. Failure is never far away, whether it be a hardware failure or a human error. We have to try to make an infrastructure as highly available as possible. No company would afford to lose a customer when the services they offer to be unreachable, especially since that downtime will almost undoubtedly cost them money. Clustering is the approach towards maintaining highly available Customer service.

What is Clustering & High Availability?

A cluster is two or more interconnected servers (sometimes called nodes) that create a solution to provide higher availability, higher scalability or both. The advantage of clustering servers for high availability is seen if one node fails, another node in the cluster can assume the workload of the failed node, and users see no interruption of access. The advantages of clustering servers for scalability include increased application performance and a greater number of users that can be supported. You can think of a cluster of servers as if they were a single, unified computing resource. With the total redundancy of multiple servers, the cluster can help achieve greater system uptime.

Clustering can be implemented at different levels of the system, including hardware, operating systems, middleware, systems management and applications. The more layers that incorporate clustering technology, the more reliable, scalable and manageable the cluster.

Sun MQ Introduction

Sun Message Queue is a messaging middleware product that implements the Java Message Service (JMS) standard.

Connects legacy and new applications, extending current IT assets

Minimizes application downtime through failover capabilities and high availability with Sun Cluster software.

Message server clusters enables the system to optimize network performance and throughput, providing performance that meets large-scale enterprise needs

Ensures only authorized individuals have access; messages are tamper-proof and confidential

Includes broker clustering as well as load distribution and scaling

Sun MQ Broker Introduction

In order to send or receive messages, a JMS(Java Messaging Service) client must first connect to a JMS message server (most often called a broker): the connection opens a channel of communication between the client and the broker. Next, the client must set up a session for creating, producing, and consuming messages. You can think of the session as a stream of messages defining a particular conversation between the client and the broker. The client itself is a message producer and/or a message consumer. The message producer sends a message to a destination that the broker manages. The message consumer accesses that destination to consume the message. The message includes a header, optional properties, and a body. The body holds the data; the header contains information the broker needs to route and manage the message; and the properties can be defined by client applications or by a provider to serve their own needs in processing messages. Connections, sessions, destinations, messages, producers, and consumers are the basic objects that make up a JMS application.

Using these basic objects, a client application can use two messaging patterns (or domains) to send and receive messages

Sun MQ Broker Architecture

Sun MQ Broker Architecture Explanation

Clients A and B are message producers, sending messages to clients C, D, E, and F by way of two different kinds of destinations.

Messaging between clients A, C, and D illustrates the point-to-point domain. Using this pattern, a client sends a message to a queue destination from which only one receiver may get it. No other receiver accessing that destination can get that specific message.

Messaging between clients B, E, and F illustrates the publish/subscribe domain. Using this broadcast pattern, a client sends a message to a topic destination from which any number of consuming subscribers can retrieve it. Each subscriber gets its own copy of the message.

Message consumers in either domain can choose to receive messages synchronously or asynchronously. Synchronous consumers make an explicit call to retrieve a message; asynchronous consumers specify a callback method that is invoked to pass a pending message. Consumers can also filter out messages by specifying selection criteria for incoming messages

Steps to Achieve SunMQ clustering

Pre-Requisites

Two Windows Machines running either Windows Xp or Windows 2000/2003 series Operating system.

Two machines should be in network and ping-able to each other.

MySQL is installed on these two machines and are highly available to each other

Note

Machine 1 IP address x.x.x.x and Machine 2 IP address y.y.y.y

Details regarding MySQL clustering can be found in the KM site. Document name is “MySQL Clustering”

1) Download "mq4_1-installer“

2) Click on "installer.vbs“

3) It will open an installation window .Stick to all default values and install SUN MQ.

4) Go to path "C:\Program Files\Sun\MessageQueue\mq\lib\ext". Place JdbcOdbc.dll and mysql-connector-java-3.1.14-bin.jar file.

5) Go to path "C:\Program Files\Sun\MessageQueue\mq\ var\instances\imqbroker\props". Open config.properties in Machine1 and Machine 2 and copy the configuration in the next slides at the end of file in Machine 1 and Machine 2 respectively. Modify the values according to the required setup in the systems required

Machine 1 Configuration. Machine 1 IP address :x.x.x.x

imq.instanceconfig.version=300
imq.persist.jdbc.dbVendor=mysql
imq.persist.jdbc.mysql.user=root
imq.cluster.ha=true
imq.persist.jdbc.mysql.password=database
imq.cluster.brokerlist=x.x.x.x\:7676,y.y.y.y\:7676
imq.cluster.heartbeat.interval=60
imq.cluster.heartbeat.port=7676
imq.persist.store=jdbc
imq.cluter.heartbeat.hostname=y.y.y.y\:7676
imq.persist.jdbc.mysql.property.url=jdbc\:mysql\://localhost\:3306/HDA3?
autoReconnect\=true&jdbcCompliantTruncation\=false&elideSetAutoCommits\=true&
useLocalSessionState\=true&maintainTimeStats\=false&
zeroDateTimeBehavior\=convertToNull
imq.instancename=imqbroker
imq.cluster.heartbeat.threshold=2
imq.cluster.hostname=x.x.x.x
imq.cluster.clusterid=mycluster
imq.persist.jdbc.hadb.property.serverList=x.x.x.x,y.y.y.y
imq.brokerid=ravi
imq.cluster_discovery.tcp=50004
imq.cluster.monitor.threshold=20
imq.cluster.monitor.interval=5
imq.portmapper.port=7676
imq.cluster.port=x.x.x.x\:7676
imq.persist.jdbc.mysql.tableoption=ENGINE\=NDBCLUSTER

Machine 2 Configuration. Machine 2 IP address :y.y.y.y

imq.instanceconfig.version=300
imq.persist.jdbc.dbVendor=mysql
imq.persist.jdbc.mysql.user=root
imq.cluster.ha=true
imq.persist.jdbc.mysql.password=database
imq.cluster.brokerlist=,y.y.y.y\:7676,x.x.x.x\:7676
imq.cluster.heartbeat.interval=60
imq.cluster.heartbeat.port=7676
imq.persist.store=jdbc
imq.cluter.heartbeat.hostname=x.x.x.x\:7676
imq.persist.jdbc.mysql.property.url=jdbc\:mysql\://localhost\:3306/HDA3?
autoReconnect\=true&jdbcCompliantTruncation\=false&elideSetAutoCommits\=true&
useLocalSessionState\=true&maintainTimeStats\=false&
zeroDateTimeBehavior\=convertToNull
imq.instancename=imqbroker
imq.cluster.heartbeat.threshold=2
imq.cluster.hostname=y.y.y.y
imq.cluster.clusterid=mycluster
imq.persist.jdbc.hadb.property.serverList=y.y.y.y,x.x.x.x
imq.brokerid=priya
imq.cluster_discovery.tcp=50004
imq.cluster.monitor.threshold=20
imq.cluster.monitor.interval=5
imq.portmapper.port=7676
imq.cluster.port=y.y.y.y\:7676
imq.persist.jdbc.mysql.tableoption=ENGINE\=NDBCLUSTER

Configuration Parameters Explained

• Broker list specifies the IP address of the Machines to be added for SUN MQ high availability.



• Heartbeat interval specifies interval in seconds for checking the other system status



• Heartbeat port specifies the port on which heart beat functionality needs to be checked.



• Heartbeat hostname specifies the hostname for which heartbeat functionality needs to be checked.



• Mysql.property.url specifies the database which is used with their relevant details. In this case we are using clustered Mysql setup with HDA3 database.



• Imq.brokerid specifies the Idname for the broker. This will be different for different systems that are being clustered. In the above configuration Machine 1 broker id is “tom” and Machine 2 broker id is “david”.



• Imq.cluster.hostname specifies the hostip of the system.

6) Start Sun MQ by typing “Imqbrokerd” from command prompt in the path "C:\Program Files\Sun\MessageQueue\mq\bin" in both the machines. Message in next slide shows the establishment of clustered connection on machine x.x.x.x. Similar output will be generated on the other machine with IP address y.y.y.y.

Imqbrokerd command output on Machine x.x.x.x.

C:\Program Files\Sun\MessageQueue\mq\bin >imqbrokerd
[06/Oct/2009:12:19:10 IST]
================================================================================
Sun Java(tm) System Message Queue 4.1
Sun Microsystems, Inc.
Version:  4.1  (Build 36-e)
Compile:  Thu 07/26/2007
Copyright (c) 2007 Sun Microsystems, Inc.  All rights reserved.
Use is subject to license terms.
================================================================================
Java Runtime: 1.5.0_15 Sun Microsystems Inc. C:\Program Files\Java\jdk1.5.0_15\jre
[06/Oct/2009:12:19:10 IST]    IMQ_HOME=C:\mq\mq
[06/Oct/2009:12:19:10 IST] IMQ_VARHOME=C:\mq\mq\var
[06/Oct/2009:12:19:10 IST] Windows XP 5.1 x86 host1 (2 cpu) tom
[06/Oct/2009:12:19:10 IST] Java Heap Size: max=194432k, current=16256k
[06/Oct/2009:12:19:10 IST] Arguments:
[06/Oct/2009:12:19:10 IST] [B1060]: Loading persistent data...
[06/Oct/2009:12:19:10 IST] Using plugged-in persistent store:
        version=410
        brokerid=tom
database connection url=jdbc:mysql://localhost:3306/HDA3?autoReconnect=true&jdbcCompliantTruncation=false&am
p;elideSetAutoCommits=true&useLocalSessionState=true&maintainTimeStats=false&zeroDateTimeBehavior=convertToN
ull database user=root
[06/Oct/2009:12:19:18 IST] [B1039]: Broker "imqbroker@host1:7676" ready.
[06/Oct/2009:12:19:31 IST] [B1071]: Established cluster connection to broker mq://y.y.y.y:7676/?instName=imqbroker
&brokerID=david&brokerSessionUID=7928908375671418112&ha=true&storeSessionUID=7928908375671418112[/y.y.y.y:2989]
[06/Oct/2009:14:22:07 IST] [B1072]: Closed cluster connection to broker mq://y.y.y.y:7676/?instName=imqbroker&brok
erID=david&brokerSessionUID=7928908375671418112&ha=true&storeSessionUID=7928908375671418112
[06/Oct/2009:14:22:13 IST] WARNING [B2105]: Attempting to initiate a cluster connection to mq://y.y.y.y:7676/?inst
Name=imqbroker&brokerID=david&brokerSessionUID=7928908375671418112&ha=true&storeSessionUID=7928908375671418112 failed: [
B4256]: Unable to get cluster service port from broker mq://y.y.y.y:7676/?instName=imqbroker&brokerID=david&broker
SessionUID=7928908375671418112&ha=true&storeSessionUID=7928908375671418112
[06/Oct/2009:14:22:25 IST] [B1071]: Established cluster connection to broker mq://y.y.y.y:7676/?instName=imqbroker
&brokerID=david&brokerSessionUID=2593831668997720320&ha=true&storeSessionUID=7928908375671418112[/y.y.y.y:4448]      

Working with IMQ Admin for Creating Brokers

1)Type imqadmin in command prompt at “C:\Program Files\Sun\MessageQueue\mq\bin”.

2)Window as shown below will be opened

Right click on Broker and give "Add Broker". It gives a window as shown below. Give password as "admin " .Click "OK"

Right click on the broker added and select option "Connect to Broker"

After the broker got connected, six elements in the Service could be seen (refer to the picture below)

Right click on the destination and select option "Add New Broker Destination".  A new window will open up as shown below

6) Choose the destination type as topic or a Queue and give the destination Name

7) Generate Message using pre configured application.

8) Make any one of the Sun MQ machine down. The other working Sun MQ machine will show the messages that were there in the Sun MQ which went down. This happens after predefined interval of time. This interval can be set in configuration file.

Conclusion

When a Non-clustered Sun MQ goes down, the entire Message stored is unavailable until the server is brought back up. Any Message that is stored is lost and will have high impact on business performance. The clustered configuration provides uninterrupted service and Message data persistence by providing failover

Following sites can be referred for further information.

http://docs.sun.com/app/docs/doc/820-4917/aerap?a=view

http://docs.sun.com/app/docs/doc/820-4916/geciv?a=view

http://docs.sun.com/source/819-2571/quick-start.html

Read More

A simple approach for Sun Message Queue Clustering

Introduction on Clustering

Today's enterprise depends on the availability of mail and web services. Failure is never far away, whether it be a hardware failure or a human error. We have to try to make an infrastructure as highly available as possible. No company would afford to lose a customer when the services they offer to be unreachable, especially since that downtime will almost undoubtedly cost them money. Clustering is the approach towards maintaining highly available Customer service.

What is Clustering & High Availability?

A cluster is two or more interconnected servers (sometimes called nodes) that create a solution to provide higher availability, higher scalability or both. The advantage of clustering servers for high availability is seen if one node fails, another node in the cluster can assume the workload of the failed node, and users see no interruption of access. The advantages of clustering servers for scalability include increased application performance and a greater number of users that can be supported. You can think of a cluster of servers as if they were a single, unified computing resource. With the total redundancy of multiple servers, the cluster can help achieve greater system uptime.

Clustering can be implemented at different levels of the system, including hardware, operating systems, middleware, systems management and applications. The more layers that incorporate clustering technology, the more reliable, scalable and manageable the cluster.

Sun MQ Introduction

Sun Message Queue is a messaging middleware product that implements the Java Message Service (JMS) standard.

Connects legacy and new applications, extending current IT assets

Minimizes application downtime through failover capabilities and high availability with Sun Cluster software.

Message server clusters enables the system to optimize network performance and throughput, providing performance that meets large-scale enterprise needs

Ensures only authorized individuals have access; messages are tamper-proof and confidential

Includes broker clustering as well as load distribution and scaling

Sun MQ Broker Introduction

In order to send or receive messages, a JMS(Java Messaging Service) client must first connect to a JMS message server (most often called a broker): the connection opens a channel of communication between the client and the broker. Next, the client must set up a session for creating, producing, and consuming messages. You can think of the session as a stream of messages defining a particular conversation between the client and the broker. The client itself is a message producer and/or a message consumer. The message producer sends a message to a destination that the broker manages. The message consumer accesses that destination to consume the message. The message includes a header, optional properties, and a body. The body holds the data; the header contains information the broker needs to route and manage the message; and the properties can be defined by client applications or by a provider to serve their own needs in processing messages. Connections, sessions, destinations, messages, producers, and consumers are the basic objects that make up a JMS application.

Using these basic objects, a client application can use two messaging patterns (or domains) to send and receive messages

Sun MQ Broker Architecture

Sun MQ Broker Architecture Explanation

Clients A and B are message producers, sending messages to clients C, D, E, and F by way of two different kinds of destinations.

Messaging between clients A, C, and D illustrates the point-to-point domain. Using this pattern, a client sends a message to a queue destination from which only one receiver may get it. No other receiver accessing that destination can get that specific message.

Messaging between clients B, E, and F illustrates the publish/subscribe domain. Using this broadcast pattern, a client sends a message to a topic destination from which any number of consuming subscribers can retrieve it. Each subscriber gets its own copy of the message.

Message consumers in either domain can choose to receive messages synchronously or asynchronously. Synchronous consumers make an explicit call to retrieve a message; asynchronous consumers specify a callback method that is invoked to pass a pending message. Consumers can also filter out messages by specifying selection criteria for incoming messages

Steps to Achieve SunMQ clustering

Pre-Requisites

Two Windows Machines running either Windows Xp or Windows 2000/2003 series Operating system.

Two machines should be in network and ping-able to each other.

MySQL is installed on these two machines and are highly available to each other

Note

Machine 1 IP address x.x.x.x and Machine 2 IP address y.y.y.y

Details regarding MySQL clustering can be found in the KM site. Document name is “MySQL Clustering”

1) Download "mq4_1-installer“

2) Click on "installer.vbs“

3) It will open an installation window .Stick to all default values and install SUN MQ.

4) Go to path "C:\Program Files\Sun\MessageQueue\mq\lib\ext". Place JdbcOdbc.dll and mysql-connector-java-3.1.14-bin.jar file.

5) Go to path "C:\Program Files\Sun\MessageQueue\mq\ var\instances\imqbroker\props". Open config.properties in Machine1 and Machine 2 and copy the configuration in the next slides at the end of file in Machine 1 and Machine 2 respectively. Modify the values according to the required setup in the systems required

Machine 1 Configuration. Machine 1 IP address :x.x.x.x

imq.instanceconfig.version=300
imq.persist.jdbc.dbVendor=mysql
imq.persist.jdbc.mysql.user=root
imq.cluster.ha=true
imq.persist.jdbc.mysql.password=database
imq.cluster.brokerlist=x.x.x.x\:7676,y.y.y.y\:7676
imq.cluster.heartbeat.interval=60
imq.cluster.heartbeat.port=7676
imq.persist.store=jdbc
imq.cluter.heartbeat.hostname=y.y.y.y\:7676
imq.persist.jdbc.mysql.property.url=jdbc\:mysql\://localhost\:3306/HDA3?
autoReconnect\=true&jdbcCompliantTruncation\=false&elideSetAutoCommits\=true&
useLocalSessionState\=true&maintainTimeStats\=false&
zeroDateTimeBehavior\=convertToNull
imq.instancename=imqbroker
imq.cluster.heartbeat.threshold=2
imq.cluster.hostname=x.x.x.x
imq.cluster.clusterid=mycluster
imq.persist.jdbc.hadb.property.serverList=x.x.x.x,y.y.y.y
imq.brokerid=ravi
imq.cluster_discovery.tcp=50004
imq.cluster.monitor.threshold=20
imq.cluster.monitor.interval=5
imq.portmapper.port=7676
imq.cluster.port=x.x.x.x\:7676
imq.persist.jdbc.mysql.tableoption=ENGINE\=NDBCLUSTER

Machine 2 Configuration. Machine 2 IP address :y.y.y.y

imq.instanceconfig.version=300
imq.persist.jdbc.dbVendor=mysql
imq.persist.jdbc.mysql.user=root
imq.cluster.ha=true
imq.persist.jdbc.mysql.password=database
imq.cluster.brokerlist=,y.y.y.y\:7676,x.x.x.x\:7676
imq.cluster.heartbeat.interval=60
imq.cluster.heartbeat.port=7676
imq.persist.store=jdbc
imq.cluter.heartbeat.hostname=x.x.x.x\:7676
imq.persist.jdbc.mysql.property.url=jdbc\:mysql\://localhost\:3306/HDA3?
autoReconnect\=true&jdbcCompliantTruncation\=false&elideSetAutoCommits\=true&
useLocalSessionState\=true&maintainTimeStats\=false&
zeroDateTimeBehavior\=convertToNull
imq.instancename=imqbroker
imq.cluster.heartbeat.threshold=2
imq.cluster.hostname=y.y.y.y
imq.cluster.clusterid=mycluster
imq.persist.jdbc.hadb.property.serverList=y.y.y.y,x.x.x.x
imq.brokerid=priya
imq.cluster_discovery.tcp=50004
imq.cluster.monitor.threshold=20
imq.cluster.monitor.interval=5
imq.portmapper.port=7676
imq.cluster.port=y.y.y.y\:7676
imq.persist.jdbc.mysql.tableoption=ENGINE\=NDBCLUSTER

Configuration Parameters Explained

• Broker list specifies the IP address of the Machines to be added for SUN MQ high availability.



• Heartbeat interval specifies interval in seconds for checking the other system status



• Heartbeat port specifies the port on which heart beat functionality needs to be checked.



• Heartbeat hostname specifies the hostname for which heartbeat functionality needs to be checked.



• Mysql.property.url specifies the database which is used with their relevant details. In this case we are using clustered Mysql setup with HDA3 database.



• Imq.brokerid specifies the Idname for the broker. This will be different for different systems that are being clustered. In the above configuration Machine 1 broker id is “tom” and Machine 2 broker id is “david”.



• Imq.cluster.hostname specifies the hostip of the system.

6) Start Sun MQ by typing “Imqbrokerd” from command prompt in the path "C:\Program Files\Sun\MessageQueue\mq\bin" in both the machines. Message in next slide shows the establishment of clustered connection on machine x.x.x.x. Similar output will be generated on the other machine with IP address y.y.y.y.

Imqbrokerd command output on Machine x.x.x.x.

C:\Program Files\Sun\MessageQueue\mq\bin >imqbrokerd
[06/Oct/2009:12:19:10 IST]
================================================================================
Sun Java(tm) System Message Queue 4.1
Sun Microsystems, Inc.
Version:  4.1  (Build 36-e)
Compile:  Thu 07/26/2007
Copyright (c) 2007 Sun Microsystems, Inc.  All rights reserved.
Use is subject to license terms.
================================================================================
Java Runtime: 1.5.0_15 Sun Microsystems Inc. C:\Program Files\Java\jdk1.5.0_15\jre
[06/Oct/2009:12:19:10 IST]    IMQ_HOME=C:\mq\mq
[06/Oct/2009:12:19:10 IST] IMQ_VARHOME=C:\mq\mq\var
[06/Oct/2009:12:19:10 IST] Windows XP 5.1 x86 host1 (2 cpu) tom
[06/Oct/2009:12:19:10 IST] Java Heap Size: max=194432k, current=16256k
[06/Oct/2009:12:19:10 IST] Arguments:
[06/Oct/2009:12:19:10 IST] [B1060]: Loading persistent data...
[06/Oct/2009:12:19:10 IST] Using plugged-in persistent store:
        version=410
        brokerid=tom
database connection url=jdbc:mysql://localhost:3306/HDA3?autoReconnect=true&jdbcCompliantTruncation=false&am
p;elideSetAutoCommits=true&useLocalSessionState=true&maintainTimeStats=false&zeroDateTimeBehavior=convertToN
ull database user=root
[06/Oct/2009:12:19:18 IST] [B1039]: Broker "imqbroker@host1:7676" ready.
[06/Oct/2009:12:19:31 IST] [B1071]: Established cluster connection to broker mq://y.y.y.y:7676/?instName=imqbroker
&brokerID=david&brokerSessionUID=7928908375671418112&ha=true&storeSessionUID=7928908375671418112[/y.y.y.y:2989]
[06/Oct/2009:14:22:07 IST] [B1072]: Closed cluster connection to broker mq://y.y.y.y:7676/?instName=imqbroker&brok
erID=david&brokerSessionUID=7928908375671418112&ha=true&storeSessionUID=7928908375671418112
[06/Oct/2009:14:22:13 IST] WARNING [B2105]: Attempting to initiate a cluster connection to mq://y.y.y.y:7676/?inst
Name=imqbroker&brokerID=david&brokerSessionUID=7928908375671418112&ha=true&storeSessionUID=7928908375671418112 failed: [
B4256]: Unable to get cluster service port from broker mq://y.y.y.y:7676/?instName=imqbroker&brokerID=david&broker
SessionUID=7928908375671418112&ha=true&storeSessionUID=7928908375671418112
[06/Oct/2009:14:22:25 IST] [B1071]: Established cluster connection to broker mq://y.y.y.y:7676/?instName=imqbroker
&brokerID=david&brokerSessionUID=2593831668997720320&ha=true&storeSessionUID=7928908375671418112[/y.y.y.y:4448]      

Working with IMQ Admin for Creating Brokers

1)Type imqadmin in command prompt at “C:\Program Files\Sun\MessageQueue\mq\bin”.

2)Window as shown below will be opened

Right click on Broker and give "Add Broker". It gives a window as shown below. Give password as "admin " .Click "OK"

Right click on the broker added and select option "Connect to Broker"

After the broker got connected, six elements in the Service could be seen (refer to the picture below)

Right click on the destination and select option "Add New Broker Destination".  A new window will open up as shown below

6) Choose the destination type as topic or a Queue and give the destination Name

7) Generate Message using pre configured application.

8) Make any one of the Sun MQ machine down. The other working Sun MQ machine will show the messages that were there in the Sun MQ which went down. This happens after predefined interval of time. This interval can be set in configuration file.

Conclusion

When a Non-clustered Sun MQ goes down, the entire Message stored is unavailable until the server is brought back up. Any Message that is stored is lost and will have high impact on business performance. The clustered configuration provides uninterrupted service and Message data persistence by providing failover

Following sites can be referred for further information.

http://docs.sun.com/app/docs/doc/820-4917/aerap?a=view

http://docs.sun.com/app/docs/doc/820-4916/geciv?a=view

http://docs.sun.com/source/819-2571/quick-start.html

Read More

Load Balancing & Clustering with Tomcat, Apache web server & JK Connector

Clustering allows us to run an application on several parallel servers (i.e. cluster nodes). The load is distributed across different servers, and even if any of the servers fails the application is still accessible via other cluster nodes. Clustering is crucial for scalable enterprise applications, as you can improve performance by simply adding more nodes to the cluster.

This document provides step by step instructions for configuring Apache server which handles  
request for static contents and delegates request for dynamic pages (i.e. JSP or Servlet) to two  instances of Tomcat server using JK Connectors.

• Installation of Apache Server
• Setting up tomcat instances 
• Configuration of Clustering for tomcat instances with JK Connectors 

Installation of Apache Server

Download windows installer for Apache Server 2.0.63 from http://httpd.apache.org/download.cgi and install the same into C:\Program Files\Apache 
Software Foundation.

Setting up tomcat instances

Download apache-tomcat-6.0.20 from http://tomcat.apache.org. Create 3 instances of tomcat named tomcatA, tomcatB with following configuration in conf/server.xml.

Uncomment the following entry in server.xml in all the instances of tomcat.

<!--
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>
-->

Define the HTTP, AJP Connector, Shutdown ports for all the tomcat instances as below,

tomcatA

HTTP	8081
Shutdown	8105
AJP Connector	8109
jvmRoute	tomcatA

tomcatB

HTTP	8082
Shutdown	8205
AJP Connector	8209
jvmRoute	tomcatB

Deploying web application in all tomcat instances:

Deploy the Hello world JSP web application into all the tomcat instances, Make your HelloWorld.jsp with following content to feel the load balancing and session replication,

tomcatA – hello.jsp

<%
session.setAttribute(“name” , “bala”);
%>
From tomcatA - Name from session - <%= session.getAttribute(“name”); %>
Session ID - <%= session.getID() %>

tomcatB – hello.jsp

From tomcatB - Name from session - <%= session.getAttribute(“name”); %>
Session ID - <%= session.getID() %>

<distributable/> tag should be defined in web.xml of your application, so that session replication will be supported by the web container.

web.xml

<webapp>
…
..
<distributable/>
..
..
</webapp>

Configuring JK Connector for routing request to Tomcat from Apache Server:

Download JK connector 1.2.8 from http://tomcat.apache.org/connectors-doc and place mod_jk-1.2.28-httpd-2.2.3.so in modules/ directory of Apache server.

Add following configuration to httpd.conf file of Apache server,

LoadModule jk_module modules/mod_jk-1.2.28-httpd-2.2.3.so
JkWorkersFile C:\cluster\workers.properties
JkLogFile "logs/mod_jk.log"
JkLogLevel trace
JkMount /cluster loadbalancer
JkMount /cluster/* loadbalancer

workers.properties should have the details about the tomcat instances which we have created as below,

workers.tomcat_home=/tomcatA
workers.java_home=$JAVA_HOME
ps=/
worker.list=tomcatA,tomcatB,loadbalancer
worker.tomcatA.port=8109
worker.tomcatA.host=localhost
worker.tomcatA.type=ajp13
worker.tomcatA.lbfactor=1
worker.tomcatB.port=8209
worker.tomcatB.host=localhost
worker.tomcatB.type=ajp13
worker.tomcatB.lbfactor=1
worker.loadbalancer.type=lb
worker.loadbalancer.balanced_workers=tomcatA,tomcatB
worker.loadbalancer.sticky_session=1

Now restart the Apache Server, TomcatA and TomcatB instances and access the HelloWorld application via URL, http://localhost/Helloworld/hello.jsp.

Now you can see the session created by tomcatA will available in tomcatB also when accessing

the above URL repeatedly.

Read More

Load Balancing & Clustering with Tomcat, Apache web server & JK Connector

Clustering allows us to run an application on several parallel servers (i.e. cluster nodes). The load is distributed across different servers, and even if any of the servers fails the application is still accessible via other cluster nodes. Clustering is crucial for scalable enterprise applications, as you can improve performance by simply adding more nodes to the cluster.

This document provides step by step instructions for configuring Apache server which handles  
request for static contents and delegates request for dynamic pages (i.e. JSP or Servlet) to two  instances of Tomcat server using JK Connectors.

• Installation of Apache Server
• Setting up tomcat instances 
• Configuration of Clustering for tomcat instances with JK Connectors 

Installation of Apache Server

Download windows installer for Apache Server 2.0.63 from http://httpd.apache.org/download.cgi and install the same into C:\Program Files\Apache 
Software Foundation.

Setting up tomcat instances

Download apache-tomcat-6.0.20 from http://tomcat.apache.org. Create 3 instances of tomcat named tomcatA, tomcatB with following configuration in conf/server.xml.

Uncomment the following entry in server.xml in all the instances of tomcat.

<!--
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>
-->

Define the HTTP, AJP Connector, Shutdown ports for all the tomcat instances as below,

tomcatA

HTTP	8081
Shutdown	8105
AJP Connector	8109
jvmRoute	tomcatA

tomcatB

HTTP	8082
Shutdown	8205
AJP Connector	8209
jvmRoute	tomcatB

Deploying web application in all tomcat instances:

Deploy the Hello world JSP web application into all the tomcat instances, Make your HelloWorld.jsp with following content to feel the load balancing and session replication,

tomcatA – hello.jsp

<%
session.setAttribute(“name” , “bala”);
%>
From tomcatA - Name from session - <%= session.getAttribute(“name”); %>
Session ID - <%= session.getID() %>

tomcatB – hello.jsp

From tomcatB - Name from session - <%= session.getAttribute(“name”); %>
Session ID - <%= session.getID() %>

<distributable/> tag should be defined in web.xml of your application, so that session replication will be supported by the web container.

web.xml

<webapp>
…
..
<distributable/>
..
..
</webapp>

Configuring JK Connector for routing request to Tomcat from Apache Server:

Download JK connector 1.2.8 from http://tomcat.apache.org/connectors-doc and place mod_jk-1.2.28-httpd-2.2.3.so in modules/ directory of Apache server.

Add following configuration to httpd.conf file of Apache server,

LoadModule jk_module modules/mod_jk-1.2.28-httpd-2.2.3.so
JkWorkersFile C:\cluster\workers.properties
JkLogFile "logs/mod_jk.log"
JkLogLevel trace
JkMount /cluster loadbalancer
JkMount /cluster/* loadbalancer

workers.properties should have the details about the tomcat instances which we have created as below,

workers.tomcat_home=/tomcatA
workers.java_home=$JAVA_HOME
ps=/
worker.list=tomcatA,tomcatB,loadbalancer
worker.tomcatA.port=8109
worker.tomcatA.host=localhost
worker.tomcatA.type=ajp13
worker.tomcatA.lbfactor=1
worker.tomcatB.port=8209
worker.tomcatB.host=localhost
worker.tomcatB.type=ajp13
worker.tomcatB.lbfactor=1
worker.loadbalancer.type=lb
worker.loadbalancer.balanced_workers=tomcatA,tomcatB
worker.loadbalancer.sticky_session=1

Now restart the Apache Server, TomcatA and TomcatB instances and access the HelloWorld application via URL, http://localhost/Helloworld/hello.jsp.

Now you can see the session created by tomcatA will available in tomcatB also when accessing

the above URL repeatedly.

Read More

Cluster Analysis

Cluster analysis is an exploratory data analysis tool for solving classification problems.  Its object is to sort cases (people, things, events, etc) into groups, or clusters, so that the degree of association is strong between members of the same cluster and weak between members of different clusters.  Each cluster thus describes, in terms of the data collected, the class to which its members belong; and this description may be abstracted through use from the particular to the general class or type.

When do we Do cluster Analysis

Cluster analysis simply discovers structures in data without explaining why they exist. We deal with clustering in almost every aspect of daily life. For example, a group of diners sharing the same table in a restaurant may be regarded as a cluster of people. In food stores items of similar nature, such as different types of meat or vegetables are displayed in the same or nearby locations.

Cluster analysis was done for a Process which had three metrics which had no correlation with each other. The Client was of the belief that the advisor population based on the three metrics remains the same week on week and identification of outliers can easily be done. The Objective of the exercise was to identify a common rank for the entire agent population of the process based on cumulative performance of the three metrics.

Introduction

The three metrics that were being considered for the process improvement were

• Average Handle Time ( A) – Lower the better
• Resolution scores ( R ) – Higher the better
• Case Logging (C) – Higher the better.

The Need for Doing a Cluster Analysis arose from the following issue.

• It was identified that None of the above three metrics bore any Correlation with each other.
• The client was of perception that the agent populations with High resolution scores have high Case logging and have low AHT.
• The client wanted to have an outlier management program in place based on weekly Quartile wise outliers as they perceived that Quartile 4 agents were constant week on week and hence it was the same set of agents who were responsible for lowering the performance of the site.

The Analysis was done with the Hypothesis: The agent population keeps on changing every week

Phase – I- Data Collection

Resolution score (R) as a metric was a 4 week Lag data point. Case logging scores (C) was sent across by client from the month of Jan’09 onwards. Hence Baseline data is considered for WE 2nd Jan’09 (C, R, A Details). Since Resolution data is lagged by 4 weeks, Resolution data has been considered for WE 30th Jan’09.

Based on the baseline week the movement of the agents would be tracked for the next 8 weeks.

Data set has been considered for Resolution, Average Handle Time and Case Logging for 233 agents who have 8 weeks of data from WE 2nd Jan’09 – WE 20th Feb’09.

Data points considered are:

Resolution scores – WE 30th Jan’09

Case Logging – WE 2nd Jan’09

Average handle Time – WE 2nd Jan’09

Phase – II- Creation of Grid.

Grid for different buckets of Case Logging, Resolution scores & Average Handle Time has been considered.

Agent population across all 7 weeks ( WE 2nd Jan’09 – WE 20th Feb ’09 ) have been ranked in each of the parameters as per the Gridline.

Rank 1- 6 are formed based on the three metrics groups and With Base line rank kept as constant the movement of the same set of agents are tracked week on week.

Movement of overall rank and as well as movement of each metrics group wise is tracked.

The Grid that has been considered for grouping Case Logging , Resolution Scores & Average Handle Time are :

Based on the 5 groups formed rank from 1 – 6 are assigned.

Rank: 1 – Outliers

Rank: 2 – Extremely Poor performance

Rank: 3 – Poor Performance

Rank: 4 – Average Performance

Rank: 5 – Good Performance

Rank: 6 – Excellent performance

Problems/Challenges Faced

The Challenges were:

• Handling huge data base for 253 agents who had rolling 8 weeks data on all three metrics.
• Creating a grid for the entire population based on three metrics week on week.
• Creation of a Rank for Baseline week and tracking the same rank of agents for the next set of 7 weeks.

Movement of Ranks tracked for each week (Overall and individual).

Details of the proposed solution

Creation of a Grid based and Ranking based on individual metric:

The data Points on all three metrics for 253 agents were for the baseline week (WE 2^nd Jan’09).With the help of Minitab the ranks for the individual metrics were obtained. The steps that were followed in Minitab are

Data > Code > Numeric to Text

The Snapshot above shows the Rank Creation for C.The same was used for Rank Creation for R and A.

The Snapshot of agent wise / Metric wise rank created is

To obtain the overall Rank on based of three metrics the Rank of three metrics were concatenated. Snapshot attached for the step and the Result obtained.

The Column Total specifies the Concatenated value. The Entire Column C10-T was copied into an excel to find out the number of possible combinations of the racks post concatenating.

Creation of an overall rank.

A total of 53 combinations were found from the “Total” field. Based on Individual Combinations a Rank was made post discussion with the team.

For Example :

• Agent in rank 1 in Case logging is within a score of 12.28% to 28.89%, Rank 1 in Resolution 51.28% - 61.03% , Rank 1 in Average Handle time ( 412 sec – 706 sec ).Hence the agent is good in Average Handle Time but outlier in Resolution and Case Logging.Hence the overall performance would be in rank 1 ( Outlier).
• Agent in Rank 4 in Case Logging( 62.41% - 79.12% ) , Rank 1 in Average Handle time ( 412 sec – 706 sec ) , rank 5 in Resolution ( 90.26% - 100.00%).This Agent is an excellent performer hence overall rank would be rank 6.

Based on these data points for all 53 combinations an Overall rank ( 1 – 6) were defined. A snapshot of the Overall Rank provided is shown below.

A Matrix plot was then made to see the movement of the agents in each cluster. The Observations are below. Post having the Matrix plot in place for the baseline week the Movement of these ranks was mapped for the next 7 weeks.

Movement of Rank 1 and Rank 2 agents in each of the metric

The Observations were for Rank 1 & Rank 2 agents.

• Average Handling Time for Rank 1 and Rank 2 agents have moved to group 2 on an average. For A lower the group the better the performance is.
• Rank 1 and Rank 2 agents have moved to group 2 & 3 for Case Logging
• Resolution scores for rank 1 and rank 2 agents have moved to group 4.

Observations : - Overall rank – 1

Resolution scores : Baseline Resolution was at 73.03% with variance from 58% - 85%.Over 7 weeks the mean has improved and so is the variation between the same set of agents.

Case Logging : Baseline was at 44% with Huge variation between agent sets. The variation has reduced and mean has improved by 10.00%.

Average Handle Time : Baseline mean was at 1491 which has shown a reducing trend for all 7 weeks and has come down to 1023.31.

Scope : Improvement of variation of this population set in R , C would help in improvement of the overall scores.

Observations Overall: rank 2

Resolution Scores : Resolution scores have improved from 73% to 85% over weeks. The population has been trending at 81% RFT for three weeks.

Case Logging: Baseline agents had a few outliers among them though the variation within the agents was less. Though there has been an improvement in Case Logging for the entire population by 13% there is still scope of improvement for this population.

Average Handle Time : Average handle Time of Rank 2 agents over the week are performing at an optimum level.Average Handle Time reduction has been steady over the weeks.

Scope : Improvement opportunity in Case Logging.

The same exercise was done for Rank 3 , rank 4 , rank 5 & 6 agents.

Rank 3 and Rank 4 agents :

• Rank 3 agents have remained in group 3 over weeks in Case Logging .Rank 4 agents in Case Logging have come down to group 3.
• Rank 3 agents in Resolution scores have moved in group 4 while rank 4 agents have stayed constant in group 4.
• In Average Handle Time rank 3 and rank 4 agents have stayed constant in group 3.

Observations :rank 3

For agents in rank 3 there has been no substantial improvement in Resolution scores and Case Logging.

Resolution scores have improved has improved from 81%-83%, Case Logging has improved from 49% - 55% Average handle time improvement of 200 sec from the baseline data.

Scope : Improvement of this population in R and C.Scrubbing cases of this population to find out areas of opportunity.

Observations :rank 4

Average performers have their Resolution scores decreased over weeks. The Resolution score for 87% has reduced from 87% - 83% on an average.

Improvements observed in Average Handle Time and Case Logging.

Scope : Improvement of this population in Resolution Scores.Training and one on one sessions would help in improving the scores.

Rank 5 & Rank 6 agents

• Case Logging for rank 5 agents have been in group 3 while rank 6 agents have moved to group 4.
• Average Handle Time of rank 5 and 6 agents have been in group 3.
• Resolution scores for rank 5 and rank 6 agents have moved to group 4 and 5.

Observations : rank 5

Rank 5 agents have maintained their scores in all three metrics.

Case Logging has constant through out the weeks.

Average Handle Time variation though high between the agent population the mean Average Handle Time of the population has been constant between 900 – 1000 secs.

Resolution scores – There has been huge fluctuation in the Resolution scores of this population. For We 9th and 16th Jan the population has been trending < 83% Resolution scores, but thereafter the Resolution scores has been consistently > 85%.

Scope : Reduction in Variation in Average Handle Time.

Maintaining the Resolution scores focus drive among this agent set.

Observations : rank 6

Case Logging score of this population has been >60% except for two weeks 30th Jan’09 and 6th Feb’09.

Average Handle Time of this population has been maintained between 800 – 900 sec.

Resolution scores for this population has been at lowest of 79% for WE 23rd Jan.

Scope : Reduction in Variation in Average Handle Time and Case logging.

Weekly Sharing of major call drivers for this set to ensure no major fluctuation of scores in Resolution scoresfor this group.

Movement of Ranks with Baseline Rank

Note :

The Graph represents the movement of the baseline ranks from WE 9th Jan’09 – WE 20th Feb’09.

Inference : Overall population actually moves in Rank – 1 status over the weeks except for the best performers or Rank 6 which has been hovering over Rank 4 & 5.

% Population in each category

Observations :

• % Population of agents in rank 3 are on an increasing trend.
• % Population of agents in Rank 4 – average performers have increased.
• % Population of agents (Outlier – Rank 1, and Extremely poor performers – Rank 2) have reduced by 2% & 12% respectively.
• % of Good performers have increased from 3.86% to 5.15% whole % of Excellent performers have remained constant

Benefits

Cluster Analysis helps in identifying group of agents in the same cluster based on multiple metrics when the CPM’s usually do not have any Correlation with each other. The details of this exercise were shared with the client. The inference of the analysis was

• Top and Bottom performers keep on changing every week.
• The average performers are consistent with 69.26% populations (of the baseline week) who have remained constant for the last 8 weeks.
• Resolution Scores, Case Logging are positively correlated for top performers and so is Resolution scores and Average Handle Time negatively correlated for the same population.
• The Agents in Rank 3 & 4(Average performers) have been in the range of 81.00% Resolution Scores, 50.00% Case Logging and 1100 Sec Average Handle Time.
• Training Needs Identified for these set of 98 advisors would help in increasing the performance of the overall set.
• Movement of ranks for each of the individual metric shows the improvement in each rank except for rank 3 and 4 who are average performers.

Attaching a snapshot for the % of agents who have repeated each week in the same bucket as per the baseline week.

Rank 1: Bottom performers and Rank 6: Top Performers.

This helped in showcasing to the client that the Top and the Bottom performers are not the same week on week hence agent variation Management based on rank 3 would not yield a benefit of more than 1%.

This activity has been showcased to the client on numerous platforms. This has also helped in deciding on the correct structure for deciding on targets for agent variation Management at process level.

Conclusion/Summary

Cluster Analysis thus helps in identifying the focus area, movement of advisors, process when there are more than one CPM.It helps in showcasing the interaction of different CPM’s and the level in which majority can perform considering multiple matrices.

References

• http://en.wikipedia.org/wiki/Cluster_analysis
• http://www.clustan.com/what_is_cluster_analysis.html

Read More

Cluster Analysis

Cluster analysis is an exploratory data analysis tool for solving classification problems.  Its object is to sort cases (people, things, events, etc) into groups, or clusters, so that the degree of association is strong between members of the same cluster and weak between members of different clusters.  Each cluster thus describes, in terms of the data collected, the class to which its members belong; and this description may be abstracted through use from the particular to the general class or type.

When do we Do cluster Analysis

Cluster analysis simply discovers structures in data without explaining why they exist. We deal with clustering in almost every aspect of daily life. For example, a group of diners sharing the same table in a restaurant may be regarded as a cluster of people. In food stores items of similar nature, such as different types of meat or vegetables are displayed in the same or nearby locations.

Cluster analysis was done for a Process which had three metrics which had no correlation with each other. The Client was of the belief that the advisor population based on the three metrics remains the same week on week and identification of outliers can easily be done. The Objective of the exercise was to identify a common rank for the entire agent population of the process based on cumulative performance of the three metrics.

Introduction

The three metrics that were being considered for the process improvement were

• Average Handle Time ( A) – Lower the better
• Resolution scores ( R ) – Higher the better
• Case Logging (C) – Higher the better.

The Need for Doing a Cluster Analysis arose from the following issue.

• It was identified that None of the above three metrics bore any Correlation with each other.
• The client was of perception that the agent populations with High resolution scores have high Case logging and have low AHT.
• The client wanted to have an outlier management program in place based on weekly Quartile wise outliers as they perceived that Quartile 4 agents were constant week on week and hence it was the same set of agents who were responsible for lowering the performance of the site.

The Analysis was done with the Hypothesis: The agent population keeps on changing every week

Phase – I- Data Collection

Resolution score (R) as a metric was a 4 week Lag data point. Case logging scores (C) was sent across by client from the month of Jan’09 onwards. Hence Baseline data is considered for WE 2nd Jan’09 (C, R, A Details). Since Resolution data is lagged by 4 weeks, Resolution data has been considered for WE 30th Jan’09.

Based on the baseline week the movement of the agents would be tracked for the next 8 weeks.

Data set has been considered for Resolution, Average Handle Time and Case Logging for 233 agents who have 8 weeks of data from WE 2nd Jan’09 – WE 20th Feb’09.

Data points considered are:

Resolution scores – WE 30th Jan’09

Case Logging – WE 2nd Jan’09

Average handle Time – WE 2nd Jan’09

Phase – II- Creation of Grid.

Grid for different buckets of Case Logging, Resolution scores & Average Handle Time has been considered.

Agent population across all 7 weeks ( WE 2nd Jan’09 – WE 20th Feb ’09 ) have been ranked in each of the parameters as per the Gridline.

Rank 1- 6 are formed based on the three metrics groups and With Base line rank kept as constant the movement of the same set of agents are tracked week on week.

Movement of overall rank and as well as movement of each metrics group wise is tracked.

The Grid that has been considered for grouping Case Logging , Resolution Scores & Average Handle Time are :

Based on the 5 groups formed rank from 1 – 6 are assigned.

Rank: 1 – Outliers

Rank: 2 – Extremely Poor performance

Rank: 3 – Poor Performance

Rank: 4 – Average Performance

Rank: 5 – Good Performance

Rank: 6 – Excellent performance

Problems/Challenges Faced

The Challenges were:

• Handling huge data base for 253 agents who had rolling 8 weeks data on all three metrics.
• Creating a grid for the entire population based on three metrics week on week.
• Creation of a Rank for Baseline week and tracking the same rank of agents for the next set of 7 weeks.

Movement of Ranks tracked for each week (Overall and individual).

Details of the proposed solution

Creation of a Grid based and Ranking based on individual metric:

The data Points on all three metrics for 253 agents were for the baseline week (WE 2^nd Jan’09).With the help of Minitab the ranks for the individual metrics were obtained. The steps that were followed in Minitab are

Data > Code > Numeric to Text

The Snapshot above shows the Rank Creation for C.The same was used for Rank Creation for R and A.

The Snapshot of agent wise / Metric wise rank created is

To obtain the overall Rank on based of three metrics the Rank of three metrics were concatenated. Snapshot attached for the step and the Result obtained.

The Column Total specifies the Concatenated value. The Entire Column C10-T was copied into an excel to find out the number of possible combinations of the racks post concatenating.

Creation of an overall rank.

A total of 53 combinations were found from the “Total” field. Based on Individual Combinations a Rank was made post discussion with the team.

For Example :

• Agent in rank 1 in Case logging is within a score of 12.28% to 28.89%, Rank 1 in Resolution 51.28% - 61.03% , Rank 1 in Average Handle time ( 412 sec – 706 sec ).Hence the agent is good in Average Handle Time but outlier in Resolution and Case Logging.Hence the overall performance would be in rank 1 ( Outlier).
• Agent in Rank 4 in Case Logging( 62.41% - 79.12% ) , Rank 1 in Average Handle time ( 412 sec – 706 sec ) , rank 5 in Resolution ( 90.26% - 100.00%).This Agent is an excellent performer hence overall rank would be rank 6.

Based on these data points for all 53 combinations an Overall rank ( 1 – 6) were defined. A snapshot of the Overall Rank provided is shown below.

A Matrix plot was then made to see the movement of the agents in each cluster. The Observations are below. Post having the Matrix plot in place for the baseline week the Movement of these ranks was mapped for the next 7 weeks.

Movement of Rank 1 and Rank 2 agents in each of the metric

The Observations were for Rank 1 & Rank 2 agents.

• Average Handling Time for Rank 1 and Rank 2 agents have moved to group 2 on an average. For A lower the group the better the performance is.
• Rank 1 and Rank 2 agents have moved to group 2 & 3 for Case Logging
• Resolution scores for rank 1 and rank 2 agents have moved to group 4.

Observations : - Overall rank – 1

Resolution scores : Baseline Resolution was at 73.03% with variance from 58% - 85%.Over 7 weeks the mean has improved and so is the variation between the same set of agents.

Case Logging : Baseline was at 44% with Huge variation between agent sets. The variation has reduced and mean has improved by 10.00%.

Average Handle Time : Baseline mean was at 1491 which has shown a reducing trend for all 7 weeks and has come down to 1023.31.

Scope : Improvement of variation of this population set in R , C would help in improvement of the overall scores.

Observations Overall: rank 2

Resolution Scores : Resolution scores have improved from 73% to 85% over weeks. The population has been trending at 81% RFT for three weeks.

Case Logging: Baseline agents had a few outliers among them though the variation within the agents was less. Though there has been an improvement in Case Logging for the entire population by 13% there is still scope of improvement for this population.

Average Handle Time : Average handle Time of Rank 2 agents over the week are performing at an optimum level.Average Handle Time reduction has been steady over the weeks.

Scope : Improvement opportunity in Case Logging.

The same exercise was done for Rank 3 , rank 4 , rank 5 & 6 agents.

Rank 3 and Rank 4 agents :

• Rank 3 agents have remained in group 3 over weeks in Case Logging .Rank 4 agents in Case Logging have come down to group 3.
• Rank 3 agents in Resolution scores have moved in group 4 while rank 4 agents have stayed constant in group 4.
• In Average Handle Time rank 3 and rank 4 agents have stayed constant in group 3.

Observations :rank 3

For agents in rank 3 there has been no substantial improvement in Resolution scores and Case Logging.

Resolution scores have improved has improved from 81%-83%, Case Logging has improved from 49% - 55% Average handle time improvement of 200 sec from the baseline data.

Scope : Improvement of this population in R and C.Scrubbing cases of this population to find out areas of opportunity.

Observations :rank 4

Average performers have their Resolution scores decreased over weeks. The Resolution score for 87% has reduced from 87% - 83% on an average.

Improvements observed in Average Handle Time and Case Logging.

Scope : Improvement of this population in Resolution Scores.Training and one on one sessions would help in improving the scores.

Rank 5 & Rank 6 agents

• Case Logging for rank 5 agents have been in group 3 while rank 6 agents have moved to group 4.
• Average Handle Time of rank 5 and 6 agents have been in group 3.
• Resolution scores for rank 5 and rank 6 agents have moved to group 4 and 5.

Observations : rank 5

Rank 5 agents have maintained their scores in all three metrics.

Case Logging has constant through out the weeks.

Average Handle Time variation though high between the agent population the mean Average Handle Time of the population has been constant between 900 – 1000 secs.

Resolution scores – There has been huge fluctuation in the Resolution scores of this population. For We 9th and 16th Jan the population has been trending < 83% Resolution scores, but thereafter the Resolution scores has been consistently > 85%.

Scope : Reduction in Variation in Average Handle Time.

Maintaining the Resolution scores focus drive among this agent set.

Observations : rank 6

Case Logging score of this population has been >60% except for two weeks 30th Jan’09 and 6th Feb’09.

Average Handle Time of this population has been maintained between 800 – 900 sec.

Resolution scores for this population has been at lowest of 79% for WE 23rd Jan.

Scope : Reduction in Variation in Average Handle Time and Case logging.

Weekly Sharing of major call drivers for this set to ensure no major fluctuation of scores in Resolution scoresfor this group.

Movement of Ranks with Baseline Rank

Note :

The Graph represents the movement of the baseline ranks from WE 9th Jan’09 – WE 20th Feb’09.

Inference : Overall population actually moves in Rank – 1 status over the weeks except for the best performers or Rank 6 which has been hovering over Rank 4 & 5.

% Population in each category

Observations :

• % Population of agents in rank 3 are on an increasing trend.
• % Population of agents in Rank 4 – average performers have increased.
• % Population of agents (Outlier – Rank 1, and Extremely poor performers – Rank 2) have reduced by 2% & 12% respectively.
• % of Good performers have increased from 3.86% to 5.15% whole % of Excellent performers have remained constant

Benefits

Cluster Analysis helps in identifying group of agents in the same cluster based on multiple metrics when the CPM’s usually do not have any Correlation with each other. The details of this exercise were shared with the client. The inference of the analysis was

• Top and Bottom performers keep on changing every week.
• The average performers are consistent with 69.26% populations (of the baseline week) who have remained constant for the last 8 weeks.
• Resolution Scores, Case Logging are positively correlated for top performers and so is Resolution scores and Average Handle Time negatively correlated for the same population.
• The Agents in Rank 3 & 4(Average performers) have been in the range of 81.00% Resolution Scores, 50.00% Case Logging and 1100 Sec Average Handle Time.
• Training Needs Identified for these set of 98 advisors would help in increasing the performance of the overall set.
• Movement of ranks for each of the individual metric shows the improvement in each rank except for rank 3 and 4 who are average performers.

Attaching a snapshot for the % of agents who have repeated each week in the same bucket as per the baseline week.

Rank 1: Bottom performers and Rank 6: Top Performers.

This helped in showcasing to the client that the Top and the Bottom performers are not the same week on week hence agent variation Management based on rank 3 would not yield a benefit of more than 1%.

This activity has been showcased to the client on numerous platforms. This has also helped in deciding on the correct structure for deciding on targets for agent variation Management at process level.

Conclusion/Summary

Cluster Analysis thus helps in identifying the focus area, movement of advisors, process when there are more than one CPM.It helps in showcasing the interaction of different CPM’s and the level in which majority can perform considering multiple matrices.

References

• http://en.wikipedia.org/wiki/Cluster_analysis
• http://www.clustan.com/what_is_cluster_analysis.html

Read More

Clustering in JBoss Application Server

Introduction

Whenever business wants to run their IT applications in a scalable and reliable way, they need to have a highly sophisticated environment, which suits their needs. The motto is to keep the business up and running, all the time 24 x7, without any breaks and troubles. Performance also cannot be compromised in this fast growing world. For any J2EE application built and deployed in most widely used, open source application Server like JBoss, Clustering comes in handy to take care of the scalability, reliability and the application availability with no compromise on performance as well. This paper will describe about the clustering concepts in JBoss Application Server

Clustering

Clustering allows us to run an application on several parallel servers (i.e. cluster nodes) while providing a single view to application clients. Load is distributed across different servers, and even if one or more of the servers fails, the application is still accessible via the surviving cluster nodes. It is crucial for scalable enterprise applications, as you can improve performance by simply adding more nodes to the cluster.

The JBoss Application Server (AS) comes with clustering support out of the box. The simplest way to start a JBoss server cluster is to start several JBoss instances on the same local network, using the run -c all command for each instance. Those server instances, all started in the all configuration, detect each other and automatically form a cluster.

What is a Cluster?

A cluster is a set of nodes. In a JBoss cluster, a node is a JBoss server instance. Thus, to build a cluster, several JBoss instances have to be grouped together (known as a "partition"). On a same network, we may have different clusters. In order to differentiate them, each cluster must have an individual name.

Following figure shows an example network of JBoss server instances divided into three clusters, with each cluster only having one node. Nodes can be added to or removed from clusters at any time.

Each JBoss server instance (node) specifies which cluster (i.e., partition) it joins in the ClusterPartition MBean in the deploy/cluster-service.xml file. All nodes that have the same ClusterPartition MBean configuration join the same cluster. Hence, if you want to divide JBoss nodes in a network into two clusters, you can just come up with two different ClusterPartition MBean configurations, and each node would have one of the two configurations depending on which cluster it needs to join. If the designated cluster does not exist when the node is started, the cluster would be created. Likewise, a cluster is removed when all its nodes are removed.

The following example shows the MBean definition packaged with the standard JBoss AS distribution. So, if you simply start JBoss servers with their default clustering settings on a local network, you would get a default cluster named DefaultPartition that includes all server instances as its nodes.

<mbean code="org.jboss.ha.framework.server.ClusterPartition" name="jboss:service=DefaultPartition">      
 <! -- Name of the partition being built -->
    <attribute name="PartitionName">
        ${jboss.partition.name:DefaultPartition}
    </attribute>
    <! -- The address used to determine the node name -->
    <attribute name="NodeAddress">${jboss.bind.address}</attribute>
    <! -- Determine if deadlock detection is enabled -->
    <attribute name="DeadlockDetection">False</attribute>
    <! -- Max time (in ms) to wait for state transfer to complete. 
        Increase for large states -->
    <attribute name="StateTransferTimeout">30000</attribute>
    <! -- The JGroups protocol configuration -->
    <attribute name="PartitionConfig">
        ... ...    </attribute>
</mbean>

Setting up the clustering

Following procedure lets us know how to set up the clustering in JBoss Application Server.

Using Clustered EJBs

Since nodes in a JBoss cluster automatically discover the existence of one another, it is very easy to set up your EJBs to be cluster-enabled. Simply setting a clustering flag in the JBoss-specific bean deployment descriptor, jboss.xml, is enough to enable load-balancing, fail-over, and state replication for your beans.

Example 1. jboss.xml

<?xml version="1.0" encoding="UTF-8"?>
<jboss>
  <enterprise-beans>
  <session>
    <ejb-name>MyEJB</ejb-name>
    <jndi-name>MyEJB</jndi-name>
    <clustered>true</clustered>
  </session>
  <entity>
    <ejb-name>MyEntity</ejb-name>
    <jndi-name>MyEntity</jndi-name>
    <clustered>true</clustered>
  </entity>
</jboss>

Using Cluster-wide JNDI

Remote clients can connect to and use the cluster-wide JNDI tree simply by leaving the provider URL undefined. JBoss will use IP multicast to discover clustered JNDI.

Example 2. jndi.properties

java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces

Using Farming

Farming is not enabled by default, so you'll have to set it up yourself. Simply create the XML file shown below and copy it to the JBoss deploy directory $JBOSS_HOME/server/all/deploy.

Example 3. farm-service.xml

<?xml version="1.0" encoding="UTF-8"?>
<server>
  <classpath codebase="lib" archives="jbossha.jar"/>
  <!--these depends tags no longer do anything
    <depends>jboss:service=Naming</depends>
    <depends>jboss.system:service=ServiceDeployer</depends>
    <depends>jboss:service=DefaultPartition</depends>
  -->
  <mbean code="org.jboss.ha.framework.server.FarmMemberService" 
     name="jboss:service=FarmMember,partition=DefaultPartition" >
    <attribute name="PartitionName">DefaultPartition</attribute>
    <attribute name="FarmDeployDirectory">./farm</attribute>
    <attribute name="ScannerName">jboss.deployment:type=DeploymentScanner,flavor=URL</attribute>
  </mbean>
</server>

After deploying farm-service.xml, you are ready to rumble. With the above configuration, just copy your farmed components into the $JBOSS_HOME/server/all/farm directory, and they will be hot-deployed across the cluster.

Starting JBoss

JBoss comes with three different ready-to-use server configurations: minimal, default, and all. Clustering is only enabled in the all configuration. To run this configuration, you must execute JBoss as follows:

run.bat -c all

JBoss Features

The following is a clustering feature overview for JBoss Servers:

• Automatic cluster membership discovery.
  



• Fail-over and load-balancing features for JNDI, RMI, Entity Beans, Stateful Session Beans with in-memory state replication, and Stateless Session Beans.
  



• Pluggable load-balance policies.
  



• HTTP session replication with Tomcat and Jetty (CVS HEAD only).
  



• Dynamic JNDI discovery. JNDI clients can automatically discover the JNDI InitialContext.
  



• Cluster-wide replicated JNDI tree.
  



• Network Boot.
  



• Farming: Distributed cluster-wide hot-deployment
  

Conclusion

JBoss clustering is designed to be simple to configure and simple to extend. It is one of the final pieces of the puzzle that makes JBoss a viable open source competitor to other enterprise J2EE offerings.

References

• http://www.jboss.org/file-access/default/members/jbossas/freezone/docs/Clustering_Guide/4/html/clustering-intro-def.html
  



• http://docs.jboss.org/jbossas/jboss4guide/r4/html/cluster.chapt.html
  

Read More