Uploaded image for project: 'Red Hat Fuse'
  1. Red Hat Fuse
  2. ENTESB-18964

AMQP connection failover doesn't work when connecting to AMQ Broker via OpenShift routes

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • fuse-7.11-GA
    • fuse-7.10-GA
    • Fuse Standalone
    • None
    • False
    • None
    • False
    • % %
    • Todo
    • Hide

      As a part of workaround we can add the following dependency 

      <dependency>
      <groupId>org.apache.qpid</groupId>
      <artifactId>qpid-jms-client</artifactId>
      <version>0.61.0.redhat-00001</version>
      </dependency>

       

      After adding this dependency the failover happens as expected.

      Show
      As a part of workaround we can add the following dependency  <dependency> <groupId>org.apache.qpid</groupId> <artifactId>qpid-jms-client</artifactId> <version>0.61.0.redhat-00001</version> </dependency>   After adding this dependency the failover happens as expected.
    • Hide

      Please follow the below steps to reproduce the issue:

      Step 1: Deploy AMQ Brokers on openshift and add amqp acceptor

      Step 2: Expose this acceptor on the route so that an application outside openshift can connect to it.

      Step 3: Use the attached Fuse project and update the amq broker URL as below

      failover:(amqps://host1:443,amqps://host2:443)?failover.nested.transport.trustAll=true

      Step 4: Ensure that the pom.xml contains Fuse 7.10 bom.

      {{Note: Please ensure that there is no }}qpid-jms-client dependency.

      Step 5: Start the application and start publishing messages.

      Step 6: While the messages are being published delete the amq broker pod on which the application has made the connection and delete the pod.

       

      Expectation: The client application should failover to the other amq broker pod.

      Actual: The application keeps trying the same broker pod and there is loss of messages until the pod comes back.

       

       

      {{}}

      Show
      Please follow the below steps to reproduce the issue: Step 1: Deploy AMQ Brokers on openshift and add amqp acceptor Step 2: Expose this acceptor on the route so that an application outside openshift can connect to it. Step 3: Use the attached Fuse project and update the amq broker URL as below failover:(amqps://host1:443,amqps://host2:443)?failover.nested.transport.trustAll=true Step 4: Ensure that the pom.xml contains Fuse 7.10 bom. {{Note: Please ensure that there is no }}qpid-jms-client dependency. Step 5: Start the application and start publishing messages. Step 6: While the messages are being published delete the amq broker pod on which the application has made the connection and delete the pod.   Expectation: The client application should failover to the other amq broker pod. Actual: The application keeps trying the same broker pod and there is loss of messages until the pod comes back.     {{}}

    Description

      • I am running an AMQ Broker cluster with 2 instances on OpenShift (deployed using the operator). The AMQPS ports (XXXX) of these instances are exposed to the public internet with OpenShift routes. I have also created a Red Hat Fuse application that publishes messages to a queue in this cluster. The connection to the cluster is accomplished using a failover connection string:

      failover:(amqps://host1:443,amqps://host2:443)?failover.nested.transport.trustAll=true

      • After having published a few messages I delete the pod of the first broker to restart it. I expect that the messages will then be published to the second broker (which is still running), but this doesn't happen. Instead, Fuse keeps trying to connect to the first broker until it has been restarted.

      Attachments

        1. amqp-demo-broker1.yaml
          0.6 kB
        2. amqp-demo-broker2.yaml
          0.6 kB
        3. amqp-demo-publisher.zip
          26 kB

        Activity

          People

            ggrzybek Grzegorz Grzybek
            rhn-support-shchavan Shrikant Chavan (Inactive)
            Marco Carletti Marco Carletti
            Votes:
            1 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: