Uploaded image for project: 'WildFly Core'
  1. WildFly Core
  2. WFCORE-2876

runtime-failure-causes-rollback does not seem to have effect when configured in model

    XMLWordPrintable

Details

    • Hide

      Steps to reproduce:

      git clone git://git.app.eng.bos.redhat.com/jbossqe/eap-tests-hornetq.git
cd eap-tests-hornetq/scripts/
git checkout master

groovy -DEAP_VERSION=7.1.0.DR19 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=ReplicatedColocatedClusterFailoverTestCase#testFailbackWithMdbsShutdownDeployByCopy -DfailIfNoTests=false -Deap=7x  | tee log

      There is 2nd test which is deploying MDB using CLI deploy command and shows that MDB is awakens on node 2 once Artemis live activates and deploys queues/connection factories:
      ReplicatedColocatedClusterFailoverTestCase#testFailbackWithMdbsShutdownDeployUsingCLI

      Show
      Steps to reproduce: git clone git: //git.app.eng.bos.redhat.com/jbossqe/eap-tests-hornetq.git cd eap-tests-hornetq/scripts/ git checkout master groovy -DEAP_VERSION=7.1.0.DR19 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=ReplicatedColocatedClusterFailoverTestCase#testFailbackWithMdbsShutdownDeployByCopy -DfailIfNoTests= false -Deap=7x | tee log There is 2nd test which is deploying MDB using CLI deploy command and shows that MDB is awakens on node 2 once Artemis live activates and deploys queues/connection factories: ReplicatedColocatedClusterFailoverTestCase#testFailbackWithMdbsShutdownDeployUsingCLI

    Description

      This is follow up on discussion in WFCORE-1912. There is difference in behavior if deployment is deployed like:

      deploy ~/tmp/mdb1.jar --unmanaged --headers={rollback-on-runtime-failure=false}

      and if it's deployed by copying to deployments directory and setting rollback-on-runtime-failure=false in model:

      /subsystem=deployment-scanner/scanner=default:write-attribute(name=runtime-failure-causes-rollback,value=false)

      If it's deployed by the 1st way using CLI deploy command then If deployment is missing some dependencies (like connection factories, queues/topics) and those are added later then deployment is able recover from it and start working without need to reload/restart server or redeploy.

      However if it's deployed the 2nd way then deployment does not recover when missing dependencies are added. It looks like attribute runtime-failure-causes-rollback does not have the effect in this case.

      This is causing problems when Artemis is configured in colocated HA topology with replicated journal where it takes some time for Artemis to activate but deployment which depends on some connection factories and queues has already tried to deploy. We need deployment to recover from this situation automatically. Restart/Reload will not help in this case as it would end up in the same situation. Only manual redeploy will help which is a workaround.

      Attachments

        Issue Links

          is related to

          Feature Request - Feature requests from customers and/or users WFLY-364 a "failure-causes-rollback="false"" attribute for the filesystem scanner

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Closed

          Bug - A problem that impairs or prevents the functions of the product. WFLY-1305 a file-scanner deployment that fails on boot will not be undeployed after failure

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Closed
          relates to

          Feature Request - Feature requests from customers and/or users WFCORE-1912 Redeploy deployment if all missing dependencies for deployment are corrected

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Open

          Activity

            People

              ehugonne1@redhat.com Emmanuel Hugonnet
              mnovak1@redhat.com Miroslav Novak
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: