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!
- Download and unzip WildFly 8.1.
- Start WildFly 8.1 in domain mode using ./bin/domain.sh.
- Download this chat sample, rename the file to “chat.war” and deploy to “main-server-group” as:
123~/tools/wildfly-8.1.0.Final/bin/jboss-cli.sh -c --command="deploy chat.war --server-groups=main-server-group"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. - Uncomment the following lines in
/usr/local/apache2/conf/httpd.conf
:
123456LoadModule lbmethod_byrequests_module modules/mod_lbmethod_byrequests.soLoadModule proxy_module modules/mod_proxy.soLoadModule proxy_wstunnel_module modules/mod_proxy_wstunnel.soLoadModule proxy_balancer_module modules/mod_proxy_balancer.so - Add the following code fragment at the end of “httpd.conf”:
1234567<Proxy balancer://mycluster>BalancerMember ws://localhost:8080BalancerMember ws://localhost:8230</Proxy>ProxyPass /chat balancer://mycluster/chat
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:
- Use the sample from github.com/arun-gupta/jboss-samples/tree/master/eap63/websocket-chat instead.
- The generated archive name is different and so the command would look slightly different too:
123~/tools/jboss-eap-6.3/bin/jboss-cli.sh -c --command="deploy websocket-chat-1.0-SNAPSHOT.war --server-groups=main-server-group" - Configure “httpd.conf” as:
1234567<Proxy balancer://mycluster>BalancerMember ws://localhost:8080BalancerMember 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!