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

szhigunov (JIRA) jira-events at lists.jboss.org
Tue Nov 11 14:31:36 EST 2008


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

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

>Creating a consumer in an EJB method to consume a message, is IIRC illegal under the JEE spec. 

Agree, that was a bad example.  Let's leave alone EJBs - we are not using them to consume. But we are using XA transactions + JCA (not part of JBM). Talking about call order I still believe that the correct one is: 1) Start tx; 2) Open JCA connection (resource enlistment); 3) Do work; 4) Close JCA connection (resource delistment) 5) Commit. It should not matter what do you do: database update or JMS send or JMS receive. 

Just want to confirm that JBM team point of view is that 5) Commit should go before 4) Close. Correct?

So I attached a new test case that commits "before" (myxatest1.zip). This is more real scenario (but I think the same problem).

Test setup.
1) Start clean JBoss 4.2.2 + JBM 1.4.0 SP3 on the remote machine (remote server).
2) Configure local JBoss. Drop myxatest.jar to the lib, myxatest-service.xml + jms-ds.xml (from myxatest1.zip) to deploy.
3) Change  java.naming.provider.url=jnp://tts-testbox01:1099 in jms-ds.xml to your remote server url.
4) Change  <attribute name="Url">jnp://tts-testbox01:1099</attribute> in myxatest-service.xml to your remote server url.

Test steps:
1.	Start remote server; start local server
2.	Go to local JMX console / myxatest / service=Test. Invoke send().
3.	Go to remote JMX console / jboss.messaging.destination / name=A.service=Queue. Verify MessageCount=1.
4.	Go to local JMX console / myxatest / service=Test. Invoke receiveCommitBefore(). That will start XA transaction; enlist DummyXAResource; get JMS connection from JCA and receive message. DummyXAResource falls to 60 sec sleep inside the commit.
5.	Verify that DummyXAResource prints "DummyXAResource commit start sleeping for 60 sec" message.
6.	Kill local server.
7.	Now we have fully prepared JBM transaction in progress. You can see one record in remote JBM_TX.
8.	Start local server.
9.	See TM recovery commits DummyXAResource. JMS recovery is not configured, so remote JMS tx is still in progress. 
10.	Go to local JMX console / myxatest / service=Test. Invoke receiveCommitBefore() again. Same message delivered again. And this is wrong. Wait for a minute and let transaction commit successfully.
11.	Got to remote JBM_TX and verify that initial transaction is still there (nobody recovered it!).
12.	Stop local server, enable JBM recovery, start server. In couple minutes the original transaction is found and committed (second time). Remote JBM_TX is empty. I can see in the local log: DEBUG [org.jboss.jms.server.recovery.MessagingXAResourceWrapper] Commit java:/DefaultJMSProvider





> 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, 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

        



More information about the jboss-jira mailing list