FUSE Message Broker
  1. FUSE Message Broker
  2. MB-1129

Duplex option on Network Connector not supported

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Major 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
    • Similar Issues:
      Show 10 results 

      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.

        Activity

        Hide
        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
        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
        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
        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
        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
        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
        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
        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:
            Gary Tully
            Reporter:
            Jason Sherman
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: