To run the example, simply type mvn verify from this directory, or mvn -PnoServer verify if you want to create and start the broker manually.
This example demonstrates how data is partitioned across two brokers. The idea is to focus on ‘data gravity’ and partition connections to brokers based on the data they will access, rather than focus on balancing connection numbers overall. For example, ensuring that all users of some particular set of data map to Broker0 and all users of some other set, map to Broker1. In this way, there is no extra movement of data to service requests. This architecture is intentionally quite static; based on the configured regular expressions, it is always possible to infer where a given application (key) should be routed to.
In this example both brokers have the role of target, but for a subset of keys. If the key is a match it is accepted, if not it is rejected. Note: redirection in this scenario is optional, with a round-robin distribution of client urls, a connection will eventually find a local target match. In this example, the qpid jms amqp client failover feature does the required round-robin distribution.
The job of application developers in this scenario is to provide a key that can easily be mapped to a regular expression that can capture an appropriate ‘center of data gravity’ for a broker.
In configuration, the local-target-filter provides the regular expression that controls what keys are mapped to a broker. Broker0 takes clientIDs with prefix FOO and Broker1 takes prefix BAR. The target-key-filter specifies how the key is extracted, we care about the first 3 characters, from the user supplied clientId.
<broker-balancer name="symmetric-simple">
<target-key>CLIENT_ID</target-key>
<target-key-filter>^.{3}</target-key-filter>
<local-target-filter>^FOO.*</local-target-filter>
</broker-balancer>