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

[szhigunov (JIRA)]

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

szhigunov commented on JBMESSAGING-1440:
----------------------------------------

At stage 7):

Node_id	transaction_id	branch_qual	format_id	global_txid
0	20480	[B at 16a9d0a	131075	[B at 6c0995

Message_id	Channel_id	Transaction_id	state	ORD	Page_order	Delivery_count	Sched_delivery
81920	3	20480	-	40184362145710080		0	0

I believe commit() should go "after" since my code may not be the one who controls the global transaction (EJB + CMT is an example). Anyway, I tried to commit "before". In this case JBM commit succeeds and no duplicate delivery happens. But the whole point here is to fail JBM commit after prepare finished. Why it does not fail in this case I do not know (my guess is when I stop JCA pool, connection in-use is not actually killed).

Now, my real scenario involves two servers, remote runs the queue, local controls tx. So instead of step 6) I hard kill local server (remote JBM prepared but did not commit). Instead of 8 I start local server again. So "stop JCA pool" trick is a workaround to simplify test set-up (one server).  Today I re-tested my two server scenarios and committing "before" or "after" did not make any difference: I got the same massage delivered and committed twice.

You are right, if I do not use XA, the issue is not applicable - close always rollback. 
If I use XA and fail before prepare  - all my tests rollback nicely (as expected)


> 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: Tim Fox
>             Fix For: 1.4.0.SP3.CP05, 1.4.2.GA
>
>         Attachments: myxatest.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