Uploaded image for project: 'ActiveMQ Artemis'
  1. ActiveMQ Artemis
  2. ARTEMIS-4378

Federation, ignore address policy when using pull consumer connection

Details

    • Improvement
    • Status: Closed
    • Minor
    • Resolution: Fixed
    • 2.29.0
    • 2.31.0
    • Federation
    • None

    Description

      Using the batching pull consumer from ARTEMIS-4314 is only applicable to queue Federation but both policies can be configured in the same federation.
      If consumer window size of zero is configured any address policy should be ignored. With address federation there is no local queue to gauge capacity and messages will just accumate in the upstream. The concept of a pull consumer for address federation does not make any sense.
      This strategy is already adopted for queue Federation configured for multicast addresses.

      Attachments

        Issue Links

          Activity

            githubbot ASF GitHub Bot logged work - 24/Aug/23 14:19
            githubbot ASF GitHub Bot logged work - 24/Aug/23 14:40
            • Time Spent:
              10m
               
              tabish121 commented on code in PR #4590:
              URL: https://github.com/apache/activemq-artemis/pull/4590#discussion_r1304443770


              ##########
              artemis-server/src/main/java/org/apache/activemq/artemis/core/server/federation/address/FederatedAddress.java:
              ##########
              @@ -310,10 +312,15 @@ private boolean match(AddressInfo addressInfo) {
                  }
               
                  private boolean match(SimpleString address, RoutingType routingType) {
              - //Currently only supporting Multicast currently.
              + // only supporting Multicast currently.
                     if (RoutingType.ANYCAST.equals(routingType)) {
                        return false;
                     }
              + if (hasPullConnectionConfig) {
              + // multicast address federation has no local queue to trigger batch pull requests, a regular fast consumer with credit window is necessary
              + // otherwise the upstream would fill up and block.

              Review Comment:
                 It is probably worth logging something here (debug level probably) that indicates that a match was rejected because pull consumer was configured and the core federation doesn't allow a way to have both address and queue federation when in pull mode. At least then you have a breadcrumb to debug it when someone complains their address federation is broken.



            githubbot ASF GitHub Bot logged work - 24/Aug/23 17:08
            • Time Spent:
              10m
               
              gtully commented on code in PR #4590:
              URL: https://github.com/apache/activemq-artemis/pull/4590#discussion_r1304632604


              ##########
              artemis-server/src/main/java/org/apache/activemq/artemis/core/server/federation/address/FederatedAddress.java:
              ##########
              @@ -310,10 +312,15 @@ private boolean match(AddressInfo addressInfo) {
                  }
               
                  private boolean match(SimpleString address, RoutingType routingType) {
              - //Currently only supporting Multicast currently.
              + // only supporting Multicast currently.
                     if (RoutingType.ANYCAST.equals(routingType)) {
                        return false;
                     }
              + if (hasPullConnectionConfig) {
              + // multicast address federation has no local queue to trigger batch pull requests, a regular fast consumer with credit window is necessary
              + // otherwise the upstream would fill up and block.

              Review Comment:
                 thanks Tim, sure it won't hurt and could help. Can do the same for both config error clauses.



            githubbot ASF GitHub Bot logged work - 24/Aug/23 18:22
            githubbot ASF GitHub Bot logged work - 25/Aug/23 10:15

            People

              gtully Gary Tully
              gtully Gary Tully
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Time Tracking

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - 0h
                  0h
                  Logged:
                  Time Spent - 50m
                  50m