You are viewing a plain text version of this content. The canonical link for it is here.
Posted to gitbox@activemq.apache.org by GitBox <gi...@apache.org> on 2021/10/06 17:37:58 UTC

[GitHub] [activemq-artemis] gemmellr commented on a change in pull request #3788: ARTEMIS-3365 - add simple local-target balancer example with amqp fai…

gemmellr commented on a change in pull request #3788:
URL: https://github.com/apache/activemq-artemis/pull/3788#discussion_r723525734



##########
File path: examples/features/broker-balancer/symmetric-simple/readme.md
##########
@@ -0,0 +1,30 @@
+# Symmetric Simple Example
+
+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 connections, ensure that all users of some set of addresses map to broker X
+and all users of some other set, map to broker B. In that way, there is no extra movement of
+data to service requests.

Review comment:
       "Rather than focus on connections" and "set of addresses" seems off given the previous sentence specifically says it focuses on partitioning connections, the feature is specifically about balancing connections, and addresses are ultimately not necessarily related (same address can still be used on different brokers for different users, depending on use cases).
   
   Dont have an immediate suggestion for better wording though.
   
   Comparing broker X and B is confusing. A and B, or X and Y, would seem more typical.

##########
File path: docs/user-manual/en/broker-balancers.md
##########
@@ -19,9 +19,9 @@ It is a string retrieved from an incoming client connection, the supported value
 * `USER_NAME` is the username indicated by the client.
 
 ## Pools
-The pool is a group of target brokers and checks periodically their state.
+The pool is a group of target brokers with periodic checks on their state.
 It provides a list of ready target brokers to distribute incoming client connections only when it is active.
-A pool becomes active when the minimum number of ready target brokers defined by the `quorum-size` parameter is reached.
+A pool becomes active when the minimum number of target brokers, as defined by the `quorum-size` parameter, is reached.

Review comment:
       ```suggestion
   A pool becomes active when the minimum number of target brokers, as defined by the `quorum-size` parameter, become ready.
   ```

##########
File path: examples/features/broker-balancer/symmetric-simple/readme.md
##########
@@ -0,0 +1,30 @@
+# Symmetric Simple Example
+
+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 connections, ensure that all users of some set of addresses map to broker X
+and all users of some other set, map to broker B. In that 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,

Review comment:
       Further to X vs B comment...now it is 0 and 1? :)




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: gitbox-unsubscribe@activemq.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org