ActiveMQ HTTP transport connector load balanced with HAProxy

If you are using ActiveMQ, you probably use the default tcp transport connector configured in the conf/activemq.xml:

        <transportConnectors>            <transportConnector name="openwire" uri="tcp://0.0.0.0:61616?maximumConnections=1000&amp;wireFormat.maxFrameSize=104857600"/>        </transportConnectors>

ActiveMQ also provides other transport connectors for some particular protocols (amqp, mqtt, stomp) or particular transports.

Especially, it supports a very convenient transport connector to go through firewalls: the http transport connector (and extended from http like https, etc.

It means that it’s possible to load balance the HTTP connections. We won’t be able to balance the messages (we need a network of brokers for that, see previous blog posts about that.

However, the HTTP transport is based on the openwire protocol. So, it’s not just a HTTP request to send a message: the client has to send several HTTP requests to establish the connection.

Basically, the client first does a HEAD HTTP request (to get the option of the transport connector, like if the Gzip compression is supported or not), then it sends a series of GET HTTP requests. For each GET request, the ActiveMQ broker will reply the openwire protocol version, the broker topology, etc.

The correlation between each HTTP request is based on a HTTP header: the clientID. The ActiveMQ HTTP connector maintains a map of clients, with their current state, based on the clientID.

If we want to balance the HTTP requests, we can’t use a simple round-robin on each request. Instead we have to balance either:

  1. the client IP address (all requests coming for a IP address will be routed to the same ActiveMQ broker)
  2. the clientID header (all request coming with the same clientID header will be routed to the same ActiveMQ broker)

We are going to use the later (the clientID HTTP header) with HAProxy.

So, imagine, you have two ActiveMQ brokers. Each broker exposes a HTTP transport connector. It means you have the following:

  • amq1 is running on 192.168.134.2, with the HTTP transport connector bound to 8282 for instance
  • amq2 is running on 192.168.134.3, with the HTTP transport connector bound to 8282 for instance

We can “façade” those two ActiveMQ brokers with HAProxy. The HAProxy configuration looks like:

listen balance  bind *:80  mode http  balance hdr(clientID)  server amq1 192.168.134.2:8282  server amq2 192.168.134.3:8282

The important configuration is the balance one, where you can see the use of clientID header for the balancing affinity.

That’s the first post of a series related to ActiveMQ “classic” for the cloud. In the next one, I will show how to use Hazelcast for deal with clientID affinity.

Comments

Post a Comment

Popular posts from this blog

Exposing Apache Karaf configurations with Apache Arrow Flight

Image
This blog post shows how to use Apache Arrow and Arrow Flight in Apache Karaf runtime. The code base is available here: https://github.com/jbonofre/karaf-arrow . Apache Arrow ? Apache Arrow is composed by: The Arrow format (specification). Format implementations with different languages (C, Java, Go, Rust, ...). Extra subprojects like Flight, Flight SQL, ADBC, nanoarrow, ... Apache Arrow format is a in-memory columnar format, super efficient for scanning and iterating a large chunks of data. In traditional memory buffer, we focus on "row". Apache Arrow format "groups" data per column, which is much more efficient on modern CPUs/GPUs. The Apache Arrow format is basically a specification. We have several implementations for this specification: C C++ C# Go Java Python Ruby Rust As the purpose of this blog post is to show Apache Arrow in Apache Karaf, we will use Arrow Java. In addition, Apache Arrow also provides several...
Read more

Getting started with Apache Karaf Minho

Image
Apache Karaf Minho Apache Karaf Minho is a new runtime, completely created from scratch. The objectives are: super easy to use and run ligtning fast, including GraalVM support Kubernetes compliant to be easily used on the cloud helping to optimize cloud costs by supporting applications colocation providing turnkey services allowing you to create Minho applications in a minute Minho is composed by: minho-boot is the core of Minho. It contains the runtime launcher and the core services (service registry, lifecycle service, configuration service, ...). minho-* services provided additional functionnalities in the runtime. You can use these services to create your own services, it's also where you will find the services managing sepcific kind of applications, allowing colocation. minho-tooling optionally provide convenient tools to create your own runtime. It includes minho-maven-plugin for instance. In this blog post, we will take a quick tour on A...
Read more

Using Apache Karaf with Kubernetes

Image
In a previous blog post ( http://blog.nanthrax.net/?p=893 ), I introduced the “new” docker support in Karaf and the use of Karaf static distribution. This post follows the previous one by illustrating how to use Karaf docker image with a Kubernetes cluster. Preparing Karaf static docker image As in the previous blog post, we are preparing a Karaf static distribution based docker image. For this blog post, I’m using the example provided in Karaf: https://github.com/apache/karaf/tree/master/examples/karaf-docker-example/karaf-docker-example-static-dist . I’m just building the distribution as usual: karaf-docker-example-static-dist$ mvn clean install Preparing kubernetes testing cluster For this blog, I’m using a minikube installed locally. The installation is pretty simple: Download minikube from https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 Rename minikube-linux-amd64 as minikube Copy minikube in your path, for instance /us...
Read more