[
https://jira.jboss.org/jira/browse/JBMESSAGING-1440?page=com.atlassian.ji...
]
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