Uploaded image for project: 'FUSE Message Broker'
  1. FUSE Message Broker
  2. MB-1129

Duplex option on Network Connector not supported

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: 5.5.1-fuse-03-06
    • Fix Version/s: 5.5.1-fuse-04-01
    • Component/s: None
    • Labels:
      None
    • Environment:

      Fuse Message Broker 5.5.1-fuse-03-06
      Fuse Message Broker 5.3.0.4

      Description

      It has been reported and confirmed with testing that when configuring a NetworkConnector as follows messages are not forwarded across the bridge. The scenario for this test case is as follows:

      NetworkConnector configured on 5.5.1-fuse-03-06

      <networkConnector uri="static:(failover:(tcp://localhost:61616,tcp://localhost:62616))?maxReconnectAttempts=1000;useExponentialBackOff=false;maxReconnectDelay=30000"
                             name="bridge"
                             networkTTL="6"
                             duplex="true"
                             dynamicOnly="false"
                             conduitSubscriptions="true"
                             decreaseNetworkConsumerPriority="false">
                      <excludedDestinations>
                      </excludedDestinations>
                      <dynamicallyIncludedDestinations>
                         <topic physicalName="TEST"/>
                      </dynamicallyIncludedDestinations>
                      <staticallyIncludedDestinations>
                      </staticallyIncludedDestinations>
      </networkConnector>

      Though the duplex option is configured messages will not flow as follows:

      producer -> 5.3.0.4 -> 5.5.1-fuse-03-06 -> consumer

      However sending messages in the other direction does work:

      consumer <- 5.3.0.4 <- 5.5.1-fuse-03-06 <- producer

      It seems in the first case the duplex option is ignored. If the same network connector is used with brokers of the same version, messages can flow in both directions.

      Additionally if the network connector is defined in the 5.3.0.4 broker I see messages can flow in both directions.

        Gliffy Diagrams

          Activity

          Hide
          garytully Gary Tully added a comment -

          There is a workaround. The problem stems from the change to the way the destinationFilter[1] is used. In a duplex network, the destinationFilter is propagated to the other end, in this case a 5.3.0, which cannot deal with the changed destinationFilter value.
          The workaround is to specify a non default destination filter with a dummy value that can consume the prepended "ActiveMQ.Advisory.Consumer." that is added in 5.3.x
          If there are no dynamicallyIncludedDestinations, a value for destinationFilter of "Legacy,ActiveMQ.Advisory.Consumer.>" will suffice.
          Otherwise, adding a dummy "legacy" destination to the list of dynamically included destinations will work.

          <dynamicallyIncludedDestinations>
                             <topic physicalName="Legacy"/>
                             <topic physicalName="TEST"/>
                          </dynamicallyIncludedDestinations>

          [1] https://issues.apache.org/jira/browse/AMQ-3384

          Show
          garytully Gary Tully added a comment - There is a workaround. The problem stems from the change to the way the destinationFilter [1] is used. In a duplex network, the destinationFilter is propagated to the other end, in this case a 5.3.0, which cannot deal with the changed destinationFilter value. The workaround is to specify a non default destination filter with a dummy value that can consume the prepended "ActiveMQ.Advisory.Consumer." that is added in 5.3.x If there are no dynamicallyIncludedDestinations, a value for destinationFilter of "Legacy,ActiveMQ.Advisory.Consumer.>" will suffice. Otherwise, adding a dummy "legacy" destination to the list of dynamically included destinations will work. <dynamicallyIncludedDestinations> <topic physicalName="Legacy"/> <topic physicalName="TEST"/> </dynamicallyIncludedDestinations> [1] https://issues.apache.org/jira/browse/AMQ-3384
          Hide
          garytully Gary Tully added a comment -

          Also, note that failover should only be used with a network connector of the maxReconnectAttempts=0 because the network connector needs to be aware of transport failures so that it can recreate the forwarding bridge.

          Show
          garytully Gary Tully added a comment - Also, note that failover should only be used with a network connector of the maxReconnectAttempts=0 because the network connector needs to be aware of transport failures so that it can recreate the forwarding bridge.
          Hide
          garytully Gary Tully added a comment -

          linking to https://issues.apache.org/jira/browse/AMQ-3384 where the changes were introduced that are the root cause or the problem.

          Show
          garytully Gary Tully added a comment - linking to https://issues.apache.org/jira/browse/AMQ-3384 where the changes were introduced that are the root cause or the problem.
          Hide
          jsherman Jason Sherman added a comment - - edited

          I spoke with Gary on this issue this morning. For the work around to work in my testing the destinationFilter needed to be defined in order to get messages to flow from the 5.3.x broker to 5.5.x broker. The configuration used was as follows:

          <networkConnectors>
                        <networkConnector uri="static:(failover:(tcp://localhost:63616)?maxReconnectAttempts=0)?useExponentialBackOff=false;maxReconnectDelay=30000"
                                  name="bridge-551-to-5304M"
                                  networkTTL="6"
                                  duplex="true"
                                  dynamicOnly="false"
                                  conduitSubscriptions="true"
                                  decreaseNetworkConsumerPriority="false"
                                  destinationFilter="Legacy,ActiveMQ.Advisory.Consumer.Topic.TEST">
                          <excludedDestinations>
                          </excludedDestinations>
                          <dynamicallyIncludedDestinations>    
                             <topic physicalName="TEST"/>
                          </dynamicallyIncludedDestinations>
                              
                          <staticallyIncludedDestinations>
                          </staticallyIncludedDestinations>
                        </networkConnector>
          </networkConnectors>

          Show
          jsherman Jason Sherman added a comment - - edited I spoke with Gary on this issue this morning. For the work around to work in my testing the destinationFilter needed to be defined in order to get messages to flow from the 5.3.x broker to 5.5.x broker. The configuration used was as follows: <networkConnectors> <networkConnector uri="static:(failover:(tcp://localhost:63616)?maxReconnectAttempts=0)?useExponentialBackOff=false;maxReconnectDelay=30000" name="bridge-551-to-5304M" networkTTL="6" duplex="true" dynamicOnly="false" conduitSubscriptions="true" decreaseNetworkConsumerPriority="false" destinationFilter="Legacy,ActiveMQ.Advisory.Consumer.Topic.TEST"> <excludedDestinations> </excludedDestinations> <dynamicallyIncludedDestinations> <topic physicalName="TEST"/> </dynamicallyIncludedDestinations> <staticallyIncludedDestinations> </staticallyIncludedDestinations> </networkConnector> </networkConnectors>

            People

            • Assignee:
              garytully Gary Tully
              Reporter:
              jsherman Jason Sherman
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: