race conditions(?) during HornetQ RA teardown

[jmesnil]

I'm following up on https://github.com/jbossas/jboss-as/pull/2327 which was to update HornetQ to 2.2.18.Final in AS7.

It highlighted race conditions during HornetQ RA tear down. The main change is that now MDB can be interrupted when the MDB is undeployed.

HornetQMessageHandler.onMessage() is written as if its endpoint is not null for the duration of the method. But this is not true.

For example, if there is a long-running computation in the MDB and the admin undeploys its archive at the same time, it is possible that the endpoint become null before the MDB onMessage returns.

This could lead to a NPE when calling endpoint.afterDelivery() for example.

I am rewriting the AS7 test to take into account that a MDB can be interrupted. The new MDB  workflow is:

* handle an "await" message

   * if the message has been redelivered, reply to it

    * else, await on a cyclic barrier to let the driver test undeploys the MDB

      => at the stage, the MDB will throw an interrupted exception. As it is CMT required, I expect it to be redelivered

* handle other messages and reply

However the "await" message is never redelivered.

I modified the test to be able to run it without a undeploy/deploy in the middle of the test.

https://github.com/jmesnil/jboss-as/blob/RA_test/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/ejb/mdb/containerstart/SendMessagesTestCase.java

If there is no undeploy/deploy (in the test, redeploy=false), the test pass

If there is a redeployment, the test fails and the "await" message is never redelivered.

The test is on my jboss-as RA_test branch on github https://github.com/jmesnil/jboss-as/tree/RA_test

you can run it with

$  ./integration-tests.sh clean install -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.ejb.mdb.containerstart.SendMessagesTestCase -Dtrace=org.jboss.as.test.integration.ejb.mdb

I am struggling to locate the issue.

I wonder if the issue is not about the XAResource management. i.e. the XAResource associated to the MDB session is detached from the transaction before it is set to rollback only or something like that...

Any idea, suggestion is welcome

[clebert.suconic]

We should probably have to explicitly call TX.rollback during an undeployment.

The issue was really having any rollback during the message on the tear-down. If you rolled back at the last message received during tearDown you would also have an issue.