Overview
The ability to combine different servers to a cluster that hides its internal servers from the clients and offers a virtual platform for an application is important for enterprise applications. It can be used to provide
- high scalability by adding cheap computational resources to the cluster on demand or
- high availability by using a transparent failover that hides faults within single servers.
Usually high scalability limits high availability and vice versa, but it is also possible to get both. The JBoss application server can be configured to support both features.
This post is the first one of a series about clustering with the JBoss AS 7. Here, we focus on the basic concepts behind JBoss AS 7 clustering and show you how to setup a basic clustered environment with a simple Java EE application.
In the series, we concentrate on the JBoss AS 7 respectively the EAP 6, which is the Red Hat-supported version of the JBoss application server. Future posts will be about particular subsystems of the JBoss AS, such as HornetQ or Infinispan.
Clustering subsystems of the JBoss AS 7
To support high availability, application data has to be replicated inside the cluster. This ensures that a crash of one server does not result in a loss of data. In the AS 7, the distributed cache of Infinispan is used as a foundation for replication. A Java EE application stores data in different layers. Accordingly the AS 7 comes with four preconfigured cache containers for replication between the cluster nodes:
- web – replication of HTTP sessions
- sfsb – replication of stateful session beans
- hibernate – second level entity cache for JPA/Hibernate
- cluster – general purpose replication of objects in a cluster
To actually transmit replicated data between the cluster nodes, Infinispan uses JGroups as the underlying subsystem. JGroups supports the creation of groups from distributed nodes. It provides operations to add new nodes, to remove nodes explicitely and to automatically abandon faulty nodes. The JBoss AS 7 includes two protocol stacks for reliable communication in a group of nodes: a UDP based protocol stack utilizing multicasts and a TCP based protocol stack for environments that do not support multicast communication. UDP is the default protocol stack in JBoss AS 7.
To support high scalability the requests from the clients have to be distributed among the cluster nodes. This is called load balancing. For load balancing of HTTP-clients, AS 7 supports the mod_cluster module for the Apache httpd server. It provides intelligent, dynamic load balancing for web applications. It utilizes the AJP connector and communicates over UDP with the httpd server module. In contrast to the older mod_jk, the httpd worker is dynamically configured.
Load balancing for EJB remote clients is supported by the JBoss Client library for EJB applications. The library will receive the topology of the cluster from the underling remoting implementation. By default a random node selector is used for load balancing of remote EJB invocations. A remote client uses JBoss remote naming as directory service with a JNDI interface to access the RMI-stub.
The example-application
To demonstrate clustering, we’ll start with a simple example-application. It includes one stateful session bean that counts the invocations and one stateless session bean implementation, which returns the name of its cluster node. Both session beans are called from a JSF page. You can find the application on github, in the cluster-example/ directory. The application is built with Maven by executing the mvn package command. The packaged Web-archive can be found in the cluster-example/target directory.
The objective of the example-application is to demonstrate how to configure your application for clustering at different levels.
Clustering EJB Session Beans
Enterprise Java Beans (EJB) are the core components of a Java EE application. EJBs provide transaction and security management and most EJB-containers also support clustering.
Clustering a Stateless Session Bean
Clustering a stateless session bean is really easy, just annotate the bean-class with @org.jboss.ejb3.annotation.Clustered
or add the corresponding tags in the JBoss-specific deployment descriptor for EJB components.
@Stateless @Clustered @Named public class ClusteredStatelessBean { private final static Logger LOG = Logger.getLogger(ClusteredStatelessBean.class.getName()); public String getNodeName() { LOG.info("invoke getNodeName()"); try { String jbossNodeName = System.getProperty("jboss.node.name"); return jbossNodeName != null ? jbossNodeName : InetAddress.getLocalHost().getHostName(); } catch (UnknownHostException e) { throw new RuntimeException(e); } } }
The example stateless session bean from our application has one simple method getNodeName()
which returns the name of the cluster node that is processing the request.
But why cluster a stateless session bean? The simple reason is that, invocation of a stateless session bean can be load balanced over the cluster nodes. This can be good for beans that do computationally intensive tasks. Thus, clustering of stateless session beans enables scalability. Because they do not encapsulate data there is no risk of loosing information when a node crashes. Thus, availability is no problem.
Clustering a Stateful Session Bean
Clustering stateful session beans is more complex than clustering a stateless session bean, because the state of the components must be managed between the cluster nodes. The application server does this, but a developer should be aware of the added complexity, which can reduce scalability.
Configuring the JBoss to cluster a stateful session bean is the same as for stateless session beans: Annotate the bean-class with @org.jboss.ejb3.annotation.Clustered
or add the corresponding tags in the xml deployment descriptor. In the default configuration of the AS 7, a clustered stateful session bean is replicated with other cluster nodes after every call. So, if one cluster node dies, the state of session is still available. State replication of a stateful session bean means, that the bean is passivated after every invocation and then stored to the ejb cache-container. With the next invocation the bean will be activated again. By default the other nodes get the new state through the Infinispan cache asynchronously.
@Stateful @SessionScoped @Clustered @Named public class ClusteredStatefulBean { private final static Logger LOG = Logger.getLogger(ClusteredStatefulBean.class.getName()); private int counter; public int getCounterValue() { LOG.info("invoke getCounter()"); return counter++; } @PrePassivate public void passivate() { LOG.info("passivate ejb component: " + this); } @PostActivate public void activate() { LOG.info("activate ejb component: " + this); } }
The example stateful session bean is a CDI component associated with the HTTP session. The bean has a counter which is increased every time it is read by the getter-method getCounterValue()
. With the counter you can track how often the bean was invoked during the session.
Enable HTTP Session replication
Replication of the HTTP session ensure that the sessions of the clients will be available on all cluster nodes. That means a session object is replicated to other cluster-nodes. This is done internally by storing the session objects into an Infinispan cache-container. So, if one node dies, the HTTP session of the client can be continued on another node. For this, an external mechanism is required to handle failover and load balancing transparent to the client side, the browser. mod_cluster can do that out-of-the-box and we will cover this below.
Configuring the JBoss AS to replicate the HTTP session is done by adding the <distributable/>
element to the web.xml:
Setting up the JBoss AS 7 instances
To see our example application working, we will need to set up a cluster. We will set up a vertical scalable cluster with two JBoss AS 7 instances located on the same machine.
We need to download the EAP 6 version, because we ran into several known bugs related to the clustering capabilities of the current community release 7.1.1.Final. These bugs are already fixed in the development branch. So you could also try the latest nightly build or download the JBoss 7.1.2.Final tag from github and run the build.sh script.
After you have downloaded the JBoss AS, extract the ZIP archive in two different directories, for example jb1 and jb2. For our cluster environment, we run the JBoss instances in standalone mode. This mode is similar to the previous versions of the JBoss AS. Now we can deploy our example-application. So, copy the Web-archive to both jb1/standalone/deployments/ and jb2/standalone/deployments/ directories.
Before we start the two JBoss AS instances let us have a look at the start commands:
$./jb1/bin/standalone.sh -Djboss.node.name=jb1 \ --server-config=standalone-ha.xml $./jb2/bin/standalone.sh -Djboss.node.name=jb2 \ --server-config=standalone-ha.xml \ -Djboss.socket.binding.port-offset=100
The first parameter will set the property jboss.node.name to jb1 or respectively jb2. Usually this value is automatically set to the host name of the machine on which the application server is running. But as we are running two JBoss instances on the same machine, this will lead to a name conflict in the cluster. The second parameter --server-config tells the JBoss not to use the standard configuration file. If you look into standalone/configuration/ directory you will see a bunch of configuration files for different purposes including our standalone-ha.xml
. The standalone-ha.xml
contains all basic configuration for high availability.
Because two JBoss AS 7 instances run on one machine, we need to avoid port conflicts. With the third parameter from the start-command of the second JBoss AS a port-offset of 100 will be activated. The obvious influence of that option is that if, for example, the port for the management-console is configured to 9990 it will really be available on port 9990+100=10090.
If you want to use different IP socket bindings instead of port-offsets, make sure you use the same multicast group.
Now let us start the first node jb1 with the above command. We will see in the log file that the cluster subsystems are activated and currently one cluster member is registered:
... 20:52:59,458 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 33) JBAS010280: Activating Infinispan subsystem. 20:52:59,459 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 37) JBAS010260: Activating JGroups subsystem. ... 20:52:59,643 INFO [org.jboss.modcluster.ModClusterService] (ModClusterService lifecycle - 1) Initializing mod_cluster 1.2.1.Final-redhat-1 ... 20:53:03,260 INFO [org.jboss.as.clustering.infinispan] (CacheService lifecycle - 1) JBAS010281: Started remote-connector-client-mappings cache from ejb container 20:53:03,260 INFO [org.jboss.as.clustering.infinispan] (CacheService lifecycle - 1) JBAS010281: Started default-host/cluster cache from web container 20:53:03,260 INFO [org.jboss.as.clustering.infinispan] (CacheService lifecycle - 1) JBAS010281: Started repl cache from web container 20:53:03,260 INFO [org.jboss.as.clustering.infinispan] (CacheService lifecycle - 1) JBAS010281: Started repl cache from ejb container 20:53:03,267 INFO [org.jboss.as.clustering] (MSC service thread 1-2) JBAS010238: Number of cluster members: 1 20:53:03,267 INFO [org.jboss.as.clustering] (MSC service thread 1-11) JBAS010238: Number of cluster members: 1 ...
Let us start the second JBoss instance jb2. In the log file, we see similar messages but now there are two registered cluster members.
21:18:27,075 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 33) JBAS010280: Activating Infinispan subsystem. 21:18:27,081 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 37) JBAS010260: Activating JGroups subsystem. 21:18:27,262 INFO [org.jboss.modcluster.ModClusterService] (ModClusterService lifecycle - 1) Initializing mod_cluster 1.2.1.Final-redhat-1 21:18:27,273 INFO [org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl] (ModClusterService lifecycle - 1) Listening to proxy advertisements on 224.0.1.105:23,364 21:18:28,156 INFO [org.jboss.as.clustering.infinispan] (CacheService lifecycle - 1) JBAS010281: Started repl cache from web container 21:18:28,156 INFO [org.jboss.as.clustering.infinispan] (CacheService lifecycle - 1) JBAS010281: Started default-host/cluster cache from web container 21:18:28,157 INFO [org.jboss.as.clustering.infinispan] (CacheService lifecycle - 1) JBAS010281: Started repl cache from ejb container 21:18:28,165 INFO [org.jboss.as.clustering] (MSC service thread 1-13) JBAS010238: Number of cluster members: 2 21:18:28,165 INFO [org.jboss.as.clustering] (MSC service thread 1-3) JBAS010238: Number of cluster members: 2
If we have a second look at the log file from cluster node jb1, we see also jb2 successfully joined our cluster!
21:18:27,844 INFO [org.jboss.as.clustering] (Incoming-1,null) JBAS010225: New cluster view for partition ejb (id: 1, delta: 1, merge: false) : [jb1/ejb, jb2/ejb] 21:18:27,844 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-1,null) ISPN000094: Received new cluster view: [jb1/ejb|1] [jb1/ejb, jb/ejb] 21:18:27,849 INFO [org.jboss.as.clustering] (Incoming-3,null) JBAS010225: New cluster view for partition web (id: 1, delta: 1, merge: false) : [jb1/web, jb2/web] 21:18:27,849 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-3,null) ISPN000094: Received new cluster view: [jb1/web|1] [jb1/web, jb2/web]
Configure Apache httpd and mod_cluster
Another thing we will need is a load balancer, which can also manage failover, if a cluster node goes down. mod_cluster is just such a balancer. First, you will need to install an Apache httpd server and then install and configure the mod_cluster modules.
If you have already installed a recent version of the httpd server, you need only to downlod the mod_cluster dynamic libraries bundle and copy them into the httpd modules directory. Otherwise you can also download a pre-configured version of the httpd server with mod_cluster for your environment from the mod_cluster download site.
To configure the Apache httpd server, open the main configuration file (something like /opt/jboss/httpd/httpd.conf) and add the following to the end of the httpd.conf file. Do not forget to adapt the path to the modules to your system accordingly.
LoadModule proxy_module /opt/jboss/httpd/lib/httpd/modules/mod_proxy.so LoadModule proxy_ajp_module /opt/jboss/httpd/lib/httpd/modules/mod_proxy_ajp.so # load the mod_cluster modules LoadModule slotmem_module /opt/jboss/httpd/lib/httpd/modules/mod_slotmem.so LoadModule manager_module /opt/jboss/httpd/lib/httpd/modules/mod_manager.so LoadModule proxy_cluster_module /opt/jboss/httpd/lib/httpd/modules/mod_proxy_cluster.so LoadModule advertise_module /opt/jboss/httpd/lib/httpd/modules/mod_advertise.so # MOD_CLUSTER_ADDS # Adjust to you hostname and subnet. Listen 127.0.0.1:6666 ManagerBalancerName mycluster Order deny,allow Deny from all Allow from 127.0.0 KeepAliveTimeout 300 MaxKeepAliveRequests 0 #ServerAdvertise on http://@IP@:6666 AdvertiseFrequency 5 #AdvertiseSecurityKey secret #AdvertiseGroup @ADVIP@:23364 EnableMCPMReceive SetHandler mod_cluster-manager Order deny,allow Deny from all Allow from 127.0.0
Now start your Apache httpd with the following command: ./opt/jboss/httpd/sbin/apachectl start
You will see one interesting output line in both log files of the cluster nodes:
[org.jboss.modcluster.ModClusterService] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) Engine [jboss.web] will use jvmRoute: 4e6189af-0502-3305-8ff3-fad7fee8b516
This means that the modcluster subsystem on the JBoss side has successfully registered with mod_cluster on the Apache side. If you open http://127.0.0.1:6666/mod_cluster-manager with your browser you will see some information about the cluster nodes.
Now feel free to play with the cluster you just built. Access our example-application through http://127.0.0.1/cluster.
You see which node is processing the requests – kill that node (ctrl-c in the console window of that node), wait a second and hit the refresh button of your browser. The request should now be processed by the other node and, much more interestingly, you neither get a new session nor a new stateful session bean. It just looks like nothing happened except that the request is handled by another cluster-node. Feel free to play around a little bit with your cluster.
Summary and Prospects
In this post we used the EAP 6 version, which is completely stable and fully usable in relation to the clustering capability. With the current community release 7.1.1.Final we ran into several known bugs. All these bugs have been fixed in the 7.1.2.Final tag. But for production environments we recommend the supported and quality-assured EAP version.
As we have shown, it is really easy to configure a simple Java EE application to run in a clustered environment. In this post we did not cover message-driven-beans or the second-level cache for JPA entities, but we plan to do this in later posts.
The next post covers the management of a clustered environment with the new domain mode of the JBoss AS 7.
Feel free to contact us for any questions or feedback.
immanuel.sims (at) akquinet.de
heinz.wilming (at) akquinet.de
does this document still valid to work on wildfly 11 ?
Not exactly. But stuff is kind of similar. You won’t need the @Clustered annotation anymore and for load balancing I probably wouldn’t use apache+mod_cluster anymore but some alternative depending on what you want to do and what you already have.
is there any updated article or document for implementation
by the way i have already a load-balance
thank you for help
Hi,
thanks a lot for these valuable tips ! configuration done and works !!! 🙂
Now I will configure to use HTTPS, but I don’t know on what configuration I must start ? configure SSL on VirtualHost 6666 ? Rewrite URL ?
thanks
sam
Hi Thanks for this valuable article.
I’ve a question, Is the @Clustered annotation apply for applications deployed at Wildfly ?
Hi,
you will not need the @Clustered annotation in WildFly. If it is present it will log a warning that this annotation is not needed anymore. In WildFly all beans are assumed @Clustered. That’s why you don’t need the annotation anymore.
Thanks, yes I’ve noticed that it’s not required as I’ve deployed my app in the domain controller getting it work in all server groups without any issues.
Is it even possible to use clustering WITHOUT an external web-server (just using the one that comes with JBoss EAP) and if it is possible, how would one do it?
You could use a tcp level load balancer. But there are also other cases like ejb clients that do not use a web interface.
to access the application url is http://127.0.0.1:8000/cluster for me becasue with http://127.0.0.1/cluster url i was not able to access the application.
Hi Immanuel,
The issue is resolved. The issue was with the hosts entry in /etc/hosts for localhost.
Also added the IP of the server on which APACHE is running in http.conf file and restarted apache.
Now I am able to load balance successfully.
Thanks a lot for your replies.
Hi Immanuel,
I have setup standalone EAP 6 on two different servers say on ips 192.168.10.1 and 192.168.10.2. They are configured as a cluster.
Also installed and started Apache with mod_cluster.
The servers and apache starts without any errors. The app deployed is also accessible from the URL.
But how do I test the load balancing here ? What are the steps to make it work for JBOSS cluster on two different servers ?
1. Do I need to install and start APACHE on both the servers ?
2. The clustering works fine, but how do I make the load balancing work ?
3. The app deployed is clusterTest.war, so i use URL: http://192.168.10.1/clusterTest to test. But in case of load-balancing what should be the URL ?
Please guide me with the steps.
Thanks.
Hi,
1. You need only one apache.
2. Load balancing works out of the box. You can configure different schemes in the modcluster subsystem of the jbosses.
3. Use the url that is provided by your apache. If you did everything as described in the post, it will be http://127.0.0.1/cluster .
Hope I could help.
Hi,
Thanks for your response.
I started Apache on 192.168.10.1.
But how will the JBOSS on 192.168.10.2 know which apache to use ?
On 10.1 this is the server startup log:
16:46:22,584 INFO [org.jboss.as.clustering] (Incoming-1,shared=tcp) JBAS010225: New cluster view for partition web (id: 1, delta: 1, merge: false) : [server2/web, server1/web]
16:46:22,585 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-1,shared=tcp) ISPN000094: Received new cluster view: [server2/web|1] [server2/web, server1/web]
and on 10.2 this is the server startup log:
– Started 211 of 333 services (121 services are passive or on-demand)
16:47:23,186 ERROR [org.jboss.modcluster] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) MODCLUSTER000043: Failed to send INFO to localhost/127.0.0.1:6666: java.net.ConnectException: Connection refused
Is that 10.1 is not able to contact the apache ?
The focus of this post is on availability. For more information on scalability I suggest to read the following post.
http://blog.akquinet.de/2012/07/19/scalable-ha-clustering-with-jboss-as-7-eap-6/
I could only see you just test the avalability of the cluster (killing one server, the other will handle request. Please show me how to config scalability and test whether adding/removing a server affect the computation power of the cluster! Thanks
Not sure if you are still tracking these comments .. a bit old now. Thanks for the information .. very useful!
Im running into an issue with the domain mode configuration.
I have 1 domain controller and 2 host controllers running on a sinle pc for testing. Thats 3 separate instances of JBoss Eap 6.1
I can see both host controllers join the domain. And I can see both nodes recognize mod_cluster with the log output that they are using jvm-route.
The behavior i am seeing is that when i stop the server that requests are being sent to, the second server picks up the request but the counter is reset to 0. if i switch back and forth stopping the current server and refreshing the page, the counts are incremented for each individual server. So i have 2 separate counters, one for each node and they continue to increment as that node is hit.
I would have thought that the session replication would make it appear as 1 count and it would continue to increment with each refresh, regardless of which node was processing the request.
Any clue as to what would cause this behavior? Is there additional information I can provide?
Any insight is greatly appreciated.
That’s right. They should share a counter. It looks like no infinispan cluster has been formed. Watch out that you use an *-ha profile. Maybe check the jgroups configuration.
Dear all,
I’ve installed jboss-eap-6.1 in 2 separate machines.
I launch 2 instance with standalone-xa.xml.
The first one output following warning message, it seems they can failed to form a cluster group.
[org.jgroups.protocols.TP$ProtocolAdapter] (Incoming-20,shared=udp) dropping unicast message to wrong destination ocl-jbc-poc-2/web; my local_addr is ocl-jbc-poc-1/web
I ‘ve tested UDP communication by using the Jgroup testing program and it is OK.
I got the same warning message even I switch to TCP
What went wrong ?
Any help is appreciated.! Thanks in advance.
Hi Ivan, you got any fix for this?
Great info especially when ther’s less available for AS7 clusterng
What am I doing wrong if I launch the first instance with standalone-ha.xml and the output log does not contain line with “Number of cluster members: 1” at all? The second launched instance does not register with the first one and they not create a cluster group at all.
Oh, just figured out that these lines are printed when the application with in web.xml is already deployed on the server. Server without any deployed applications looks like server without cluster configuration.
Maybe your nodes do not form a cluster, because your network does not support ip multicast.
JGroups comes with two small programs to test the communication:
java -cp jgroups-3.0.10.Final.jar org.jgroups.tests.McastReceiverTest -mcast_addr 230.0.0.4 -port 55200
Socket=0.0.0.0/0.0.0.0:55200, bind interface=/fe80:0:0:0:e6ce:8fff:fe2d:4be2%5
Socket=0.0.0.0/0.0.0.0:55200, bind interface=/192.168.178.33
Socket=0.0.0.0/0.0.0.0:55200, bind interface=/192.168.2.3
Socket=0.0.0.0/0.0.0.0:55200, bind interface=/192.168.2.2
Socket=0.0.0.0/0.0.0.0:55200, bind interface=/192.168.2.1
Socket=0.0.0.0/0.0.0.0:55200, bind interface=/0:0:0:0:0:0:0:1
Socket=0.0.0.0/0.0.0.0:55200, bind interface=/fe80:0:0:0:0:0:0:1%1
Socket=0.0.0.0/0.0.0.0:55200, bind interface=/127.0.0.1
hello jboss [sender=192.168.178.33:55200]
hello jboss [sender=192.168.178.33:55200]
hello jboss [sender=192.168.178.33:55200]
java -cp jgroups-3.0.10.Final.jar org.jgroups.tests.McastSenderTest -mcast_addr 230.0.0.4 -port 55200
Socket #1=0.0.0.0/0.0.0.0:55200, ttl=32, bind interface=/fe80:0:0:0:e6ce:8fff:fe2d:4be2%5
Socket #2=0.0.0.0/0.0.0.0:55200, ttl=32, bind interface=/192.168.178.33
Socket #3=0.0.0.0/0.0.0.0:55200, ttl=32, bind interface=/192.168.2.3
Socket #4=0.0.0.0/0.0.0.0:55200, ttl=32, bind interface=/192.168.2.2
Socket #5=0.0.0.0/0.0.0.0:55200, ttl=32, bind interface=/192.168.2.1
Socket #6=0.0.0.0/0.0.0.0:55200, ttl=32, bind interface=/0:0:0:0:0:0:0:1
Socket #7=0.0.0.0/0.0.0.0:55200, ttl=32, bind interface=/fe80:0:0:0:0:0:0:1%1
Socket #8=0.0.0.0/0.0.0.0:55200, ttl=32, bind interface=/127.0.0.1
> hello jboss
>
This post (http://blog.akquinet.de/2012/11/29/jgroups-cloud-issues-when-clustering-the-eap-6-as-7/) covers the different transport protocols of jgroups.
Useful information. Fortunate me I discovered your website unintentionally, and I’m surprised why this accident did not happened earlier! I bookmarked it.
Very nice steps. I googled many webpages. but no help. Finally I got the proper working solution here. Thanks a lot.
when I try to load these modules I get the error:
starting httpd: httpd: Syntax error on line 201 of /etc/httpd/conf/httpd.conf: Cannot load /usr/lib/httpd/modules/mod_slotmem.so into server: /usr/lib/httpd/modules/mod_slotmem.so: wrong ELF class: ELFCLASS64
LoadModule slotmem_module modules/mod_slotmem.so
LoadModule manager_module modules/mod_manager.so
LoadModule proxy_cluster_module modules/mod_proxy_cluster.so
LoadModule advertise_module modules/mod_advertise.so
but I can’t find these modules in 32bits.How can I rebuild them?
These are exactly the 4 mod_cluster modules. You can find them in various versions on the mod_cluster download page.
http://www.jboss.org/mod_cluster/downloads/1-2-0-Final
If you just want the .so files look for “dynamic libraries linux2-x86”.
thanks it worked.
if there is a message like this:
14:58:21,340 INFO [org.jboss.as.clustering] (Incoming-10,null) JBAS010225: Nova visualização do cluster para a partição web (id: 20, delta: -1, merge: false) : [inst_server02_jb6/web]
14:58:21,341 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-10,null) ISPN000094: Received new cluster view: [inst_server02_jb6/web|20] [inst_server02_jb6/web]
my cluster is working properly?
how do i know it is load balanced?
These messages basically say that one node has been removed from the cluster and now there is only one remaining: “inst_server02_jb6”.
That does sound good if the other node was intended to go down.
You can test load-balancing by creating NEW web-sessions and playing with the load-metric (configuration of the modcluster subsystem in standalone-ha.xml). See http://docs.jboss.org/mod_cluster/1.2.0/html/java.AS7config.html#LoadMetric
thanks,
can you do this in domain mode?
For sure. This is covered in a follow-up post:
http://blog.akquinet.de/2012/06/29/managing-cluster-nodes-in-domain-mode-of-jboss-as-7-eap-6/
Basically it’s just using the ha profile.
Which version of the JBoss application server are you using?
For me the sample doesnt work in 2 ways:
– statefull : replication fails whith the 2 instances, when i switch to the second after having succesfully called the first.
– stateless : exception on the property of the bean inside xhtml
I don’t put in place the front end in a fist place i call directly the 2 containers. Help is welcome
Hi,
> I don’t put in place the front end in a fist place i call directly the 2 containers.
Does that mean you are not using mod_cluster or mod_jk? You will need some load-balancer to handle fail-over.
I use jboss community 7.1.2 build on my own.
The pb on stateless is resolved with removing remote interface as you did for statefull.
As i try on my pc : mod_cluster is not available on winxp.
Now i try mod_cluster, it works but always failover doesnot work, apache redirect to the second jboss (jb2) but jb2 failed to restore: java.lang.IllegalStateException: Error restoring serialized contextual with id org.jboss.weld.bean-cluster-example-1.0-SNAPSHOT.war.
Your problem does sound similar to this issue:
https://community.jboss.org/thread/195690?start=0&tstart=0
You could try the trick with the different annotations.
If you want to give it a try you could use a newer nightly-build of the JBoss AS from here:
https://ci.jboss.org/hudson/job/JBoss-AS-7.x-latest/
If that does not work too it may be a good idea to post your problem to the jboss forum – maybe in the above thread.
Thanks to you for spending time for me, I finally move to linux mint distrib so i get mod_cluster running.
ans thats work, I have anyway always to remove the stateless remote interface ans the admin mod_cluster not working (port:6666) I investigate. futher.
What I expperiment is that this config is a failover config I can t get load balance the 2 node, does it seems ok for you?
Actually it seemed like I pushed a non working version to github. You are right, I had to remove the remote interface from the stateless session bean. Adding a local interface also solved the issue (seems like JSF requires a local interface). This is now also solved on github.
Thank you!
mod_cluster can and will do load-balancing in this configuration. But it has sticky-sessions activated, i.e. one session will stay on the same node. You can configure the behaviour of mod_cluster in the standalone-ha.xml, subsystem modcluster.
You can not access 127.0.0.1:6666/mod_cluster-manager ?
Maybe there is a problem in the above apache-config. I can’t check that today but I think
should be
If that doesn’t work, try “allow from all” instead of “deny from all”.
Thanks for your answer, I really think I have not a good unerstanding of the integration/configuration of mod_cluster in apache, I don’t find any good documentation about that.
What you give in your post is just the configuration we find with a fresh install of apache+mod_cluster from mod_cluster download.
With this fresh install :
http://localhost:/cluster works but
http://localhost:6666/mod_cluster_manager doesnt works.
It should be http://127.0.0.1:6666/mod_cluster-manager
Note: one underscore and one dash. Not two underscores.
But you are right, the apache part is covered badly in this post and there really is no good documentation about it. Maybe if I got some time I’m gonna change that fact.
love it. great done.
Yes thank you! 🙂
I don’t even know how I ended up here, but I thought this post was good. I do not know who you are but certainly you’re going to a famous blogger if you aren’t already 😉 Cheers!
Thanks! I will pass this further to the people who helped me with this post.