Uploaded image for project: 'AMQ Broker'
  1. AMQ Broker
  2. ENTMQBR-1818

[Artemis 2.x upgrade] Artemis RA connections disconnected after failover

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Blocker
    • None
    • None
    • broker-core
    • None
    • Hide

      Issue is intermittent - not 100% reproducer:

      git clone git://git.app.eng.bos.redhat.com/jbossqe/eap-tests-hornetq.git
cd eap-tests-hornetq/scripts/
git checkout eap7.2.x-artemis2.x
groovy -DEAP_ZIP_URL=https://mw-messaging-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/EAP-tooling/job/early-testing-messaging-prepare/141/ PrepareServers7.groovy
export WORKSPACE=$PWD
export JBOSS_HOME_1=$WORKSPACE/server1/jboss-eap
export JBOSS_HOME_2=$WORKSPACE/server2/jboss-eap
export JBOSS_HOME_3=$WORKSPACE/server3/jboss-eap
export JBOSS_HOME_4=$WORKSPACE/server4/jboss-eap

cd ../jboss-hornetq-testsuite/

mvn clean test -Dtest=DedicatedFailoverTestCaseWithMdb#testShutdownWithFailback -Deap7.clients.version=7.1531981138-SNAPSHOT | tee log
      Show
      Issue is intermittent - not 100% reproducer : git clone git: //git.app.eng.bos.redhat.com/jbossqe/eap-tests-hornetq.git cd eap-tests-hornetq/scripts/ git checkout eap7.2.x-artemis2.x groovy -DEAP_ZIP_URL=https: //mw-messaging-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/EAP-tooling/job/early-testing-messaging-prepare/141/ PrepareServers7.groovy export WORKSPACE=$PWD export JBOSS_HOME_1=$WORKSPACE/server1/jboss-eap export JBOSS_HOME_2=$WORKSPACE/server2/jboss-eap export JBOSS_HOME_3=$WORKSPACE/server3/jboss-eap export JBOSS_HOME_4=$WORKSPACE/server4/jboss-eap cd ../jboss-hornetq-testsuite/ mvn clean test -Dtest=DedicatedFailoverTestCaseWithMdb#testShutdownWithFailback -Deap7.clients.version=7.1531981138-SNAPSHOT | tee log
    • AMQ Broker 1833

    Description

      There is regression againt Artemis 1.5.5.0012 in scenario with failover of Artemis RA from live to backup (shared store, dedicated topology). After backup activates after failover, connections of RA does not failover to backup (or are disconnected from backup just after failover)

      Test scenario:

      • There are three servers. Live server (Node 1) and backupserver (Node 2) are in dedicated HA topology.
      • InQueue and OutQueue are deployed on live and backup. Send messages to InQueue on live server.
      • When all messages are sent, deploy message driven bean on Node 3.
      • MDB sends messages form InQueue to OutQueue.
      • Shutdown live server. Wait for backup server to alive, then start live server again and stop backup.
      • Receive messages from OutQueue from live server.

      Results:
      After live server is stopped and backup activates, no messages are processed by MDB. Looking at trace logs it seems that MDB does reconnect to backup but it's then disconnected. Then I don't see connector to backup server between tried connectors during reconnection.

      Attaching reproduce and logs.

      Attachments

        Issue Links

          blocks

          Component Upgrade - A task tracking an update to a bundled component or revision of component upstream of the project. WFLY-10320 Upgrade artemis from 1.5.x to 2.x.x

          • Blocker - To be worked above all other priorities. This term is chosen when the severity of the issue is very high, has no workaround, or the effort for the change is comparatively low. Issues that may be very publicly visible and could generate significant media attention may also drive a higher priority.
          • Closed
          clones

          Bug - A problem that impairs or prevents the functions of the product. WFLY-11059 Clients do not failover to backup even it if backup started and keep retrying connection

          • Critical - To be worked on immediately following BLOCKER issues.
          • Resolved

          Bug - A problem that impairs or prevents the functions of the product. WFWIP-65 [Artemis 2.x upgrade] Artemis RA connections disconnected after failover

          • Blocker - To be worked above all other priorities. This term is chosen when the severity of the issue is very high, has no workaround, or the effort for the change is comparatively low. Issues that may be very publicly visible and could generate significant media attention may also drive a higher priority.
          • Closed

          Activity

            People

              csuconic@redhat.com Clebert Suconic
              mnovak1@redhat.com Miroslav Novak
              Michal Toth Michal Toth
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Time Tracking

                  Estimated:
                  Original Estimate - 4 days
                  4d
                  Remaining:
                  Remaining Estimate - 4 days
                  4d
                  Logged:
                  Time Spent - Not Specified
                  Not Specified