[jboss-jira] [JBoss JIRA] (WFCORE-2876) runtime-failure-causes-rollback does not seem to have effect when configured in model

[Miroslav Novak (JIRA)]

     [ https://issues.jboss.org/browse/WFCORE-2876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Miroslav Novak updated WFCORE-2876:
-----------------------------------
    Steps to Reproduce: 
Steps to reproduce:
{code}
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#testFailbackWithMdbsShutdown -DfailIfNoTests=false -Deap=7x  | tee log
{code}

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


> runtime-failure-causes-rollback does not seem to have effect when configured in model
> -------------------------------------------------------------------------------------
>
>                 Key: WFCORE-2876
>                 URL: https://issues.jboss.org/browse/WFCORE-2876
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Deployment Scanner
>    Affects Versions: 3.0.0.Beta21
>            Reporter: Miroslav Novak
>            Assignee: ehsavoie Hugonnet
>
> This is follow up on discussion in WFCORE-1912. There is difference in behavior if deployment is deployed like:
> {code}deploy ~/tmp/mdb1.jar --unmanaged --headers={rollback-on-runtime-failure=false}{code}
> and if it's deployed by copying to deployments directory and setting {{rollback-on-runtime-failure=false}} in model:
> {code}
> /subsystem=deployment-scanner/scanner=default:write-attribute(name=runtime-failure-causes-rollback,value=false)
> {code}
> 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.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)