[jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1440) JTA-prepared message delivered to other consumer.

[Howard Gao (JIRA)]

    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12441879#action_12441879 ] 

Howard Gao commented on JBMESSAGING-1440:
-----------------------------------------


The details is:

When a message is received over a XA transacted session and enlisted in a XA transaction as a branch of work, the resource manager will keep track of the Tx commit. 

In JBM when the Tx is being prepared, the Persistence Manager stores the message in to JBM_MSG (and REF) table and also records the TX in JBM_TX for recovery. (see TransactionCallback.handleBeforePrepare() in JDBCPersistenceManager)

Then in commit time, the message will be acked and removed.  (see TransactionCallback.handleBeforeCommit2PC() in JDBCPersistenceManager).

If the connection is stopped after the Tx is prepared but not committed yet, JBM will detect it and try to cancel all unfinished deliveries, including the above said one. The cancel simply puts the message ref back to mem list and re-deliver, regardless whether there is a TX associated or not (see ChannelSupport.cancel(del)).

The result is, when another receiver tries to receive messages when the connection is back, the said message will be delivered flat. which is WRONG because it is still belongs to an unfinished and prepared XA tx.

To prevent this, I introduced a boolean into the Delivery object to remember whether it is associated with an XA transaction, and in the cancel time, the boolean will be checked and if the delivery is with an XA transaction, the message reference will not be put back into the mem list for re-delivery. 



> JTA-prepared message delivered to other consumer. 
> --------------------------------------------------
>
>                 Key: JBMESSAGING-1440
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1440
>             Project: JBoss Messaging
>          Issue Type: Bug
>         Environment: JBoss 4.2.2 + JBM 1.4.0.SP3. Windows XP.
>            Reporter: szhigunov
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP05, 1.4.2.GA
>
>         Attachments: myxatest.zip, myxatest1.zip
>
>
> The problem is that when fully prepared tx1 fails in the commit phase, JBM delivers the message second time in tx2, while tx1 is still in progress. Eventually recovery commits tx1, so the message gets delivered and committed twice.
> The attached test (myxatest.zip) is a clean JBoss 4.2.2 + JBM 1.4.0 SP3 with my test MBean: jboss-4.2.2.GA\server\messaging\lib\myxatest.jar (code and source) + jboss-4.2.2.GA\server\messaging\deploy\myxatest-service.xml.
> Steps to reproduce the problem:
> 1.	Start the server.
> 2.	Go to JMX console + myxatest + service=Test. Invoke send.
> 3.	Go to JMX console + jboss.messaging.destination + name=A.service=Queue. Verify MessageCount=1.
> 4.	Go to JMX console + myxatest + service=Test. Invoke receive. That will start XA transaction; enlist DummyXAResource; get JMS connection from JCA and receive message. DummyXAResource sleeps 60 sec inside the commit call.
> 5.	Verify that DummyXAResource prints "DummyXAResource commit start sleeping for 60 sec" message.
> 6.	Go to JMX console + jboss.jca + name=JmsXA,service=ManagedConnectionPool and invoke stop(). Check that DummyXAResource finished commit and printed "DummyXAResource commit end" message. JBM commit fails.
> 7.	Now we have fully prepared JBM transaction in progress. You can see one record in JBM_TX.
> 8.	Go to JMX console + jboss.jca + name=JmsXA,service=ManagedConnectionPool and invoke start().
> 9.	Go to JMX console + myxatest + service=Test. Invoke receive again. Same message delivered again. And this is wrong. Wait for a minute and let transaction finish successfully.
> 10.	Got to JBM_TX and verify that transaction is still there (nobody recovered it!).
> 11.	Stop server, enable JBM recovery, start server. In couple minutes the original transaction is found and committed (second time). JBM_TX is empty.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira