JBoss EAP 6.3 provides a technology preview of WebSocket and WildFly have supported them as part of Java EE 7 compliance.

github.com/javaee-samples/javaee7-samples/tree/master/websocket provide tons of Java EE 7 samples that run on WildFly. If you are interested in similar functionality on JBoss EAP 6.3 then github.com/jboss-developer/jboss-eap-quickstarts/tree/6.4.x-develop/websocket-hello is a quickstart. In addition, there are a few more samples at github.com/arun-gupta/jboss-samples/tree/master/eap63.

One of the common questions asked related to WebSockets is how to how to load balance  them. This Tech Tip will explain that for WildFly and JBoss EAP 6.3.

First, what are the main components ?

• At least Apache HTTPD 2.4.5 is required. Now HTTPD binaries are not available for Mac but fortunately compiling instructions are explained clearly in Tech Tip #45.
• mod_proxy_wstunnel is an Apache module that provides support for tunneling of Web Socket connections to a backend Web Sockets server, such as WildFly or JBoss EAP. It is a support module to mod_proxy that provide support for a number of popular protocols as well as several different load balancing algorithms. The connection is automagically upgraded to a WebSocket connection.  And all the modules are already included in the modules directory.
• mod_proxy_balancer module is required that provides load balancing for HTTP and other protocols.

Let’s go!

1. Download and unzip WildFly 8.1.
2. Start WildFly 8.1 in domain mode using ./bin/domain.sh.
3. Download this chat sample, rename the file to “chat.war” and deploy to “main-server-group” as:
   
   ~/tools/wildfly-8.1.0.Final/bin/jboss-cli.sh -c --command="deploy chat.war --server-groups=main-server-group"

   1	~/tools/wildfly-8.1.0.Final/bin/jboss-cli.sh -c --command="deploy chat.war --server-groups=main-server-group"

   
   The only difference from the original Java EE 7 WebSocket Chat sample is the addition of System.getProperty("jboss.node.name") to display the name of WildFly instance serving the application. The source code is available at github.com/arun-gupta/wildfly-samples/tree/master/websocket-loadbalance.
4. Uncomment the following lines in /usr/local/apache2/conf/httpd.conf:
   
   LoadModule lbmethod_byrequests_module modules/mod_lbmethod_byrequests.so LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_wstunnel_module modules/mod_proxy_wstunnel.so LoadModule proxy_balancer_module modules/mod_proxy_balancer.so

   1 2 3 4

   LoadModule lbmethod_byrequests_module modules/mod_lbmethod_byrequests.so LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_wstunnel_module modules/mod_proxy_wstunnel.so LoadModule proxy_balancer_module modules/mod_proxy_balancer.so

   
   This will enable all the required modules.
5. Add the following code fragment at the end of “httpd.conf”:
   
   <Proxy balancer://mycluster> BalancerMember ws://localhost:8080 BalancerMember ws://localhost:8230 </Proxy> ProxyPass /chat balancer://mycluster/chat

   1 2 3 4 5

   <Proxy balancer://mycluster>     BalancerMember ws://localhost:8080     BalancerMember ws://localhost:8230 </Proxy> ProxyPass /chat balancer://mycluster/chat

   
   Proxy is a container for proxied resources and is creating a load balancing group in this case using balancer directive. BalancerMember adds a member to this load balancing group.  ProxyPass is a standard directive that maps remote servers running on different ports into the space of the local server. In this case, WildFly is started in domain mode and so starts two instances on port 8080 and 8230. Both of these instances are mapped to localhost:80, which is where Apache HTTPD is running by default.

The deployed chat sample is now accessible at localhost:8080/chat (first instance in the managed domain), localhost:8230/chat (second WildFly instance in the managed domain), and localhost/chat (via Apache HTTPD).

Now even if you kill one of the WildFly instances, the other instance will continue to serve the client. Note, this only gives application availability as there is no session failover in this.

This was also verified on JBoss EAP 6.3 and there are a few differences:

1. Use the sample from github.com/arun-gupta/jboss-samples/tree/master/eap63/websocket-chat instead.
2. The generated archive name is different and so the command would look slightly different too:
   
   ~/tools/jboss-eap-6.3/bin/jboss-cli.sh -c --command="deploy websocket-chat-1.0-SNAPSHOT.war --server-groups=main-server-group"

   1	~/tools/jboss-eap-6.3/bin/jboss-cli.sh -c --command="deploy websocket-chat-1.0-SNAPSHOT.war --server-groups=main-server-group"

3. Configure “httpd.conf” as:
   
   <Proxy balancer://mycluster> BalancerMember ws://localhost:8080 BalancerMember ws://localhost:8230 </Proxy> ProxyPass /websocket-chat-1.0-SNAPSHOT balancer://mycluster/websocket-chat-1.0-SNAPSHOT

   1 2 3 4 5

   <Proxy balancer://mycluster>     BalancerMember ws://localhost:8080     BalancerMember ws://localhost:8230 </Proxy> ProxyPass /websocket-chat-1.0-SNAPSHOT balancer://mycluster/websocket-chat-1.0-SNAPSHOT

And that’s it!

Watch this live in action:

An important point to understand is that there is no concept of “sticky sessions” in WebSocket as, unlike HTTP, there is a direct and “permanent” connection between the client and the server in this case.

Enjoy!