2:15 a.m.
[ http://jira.jboss.com/jira/browse/JBMESSAGING-477?page=comments#action_12... ]
Tim Fox commented on JBMESSAGING-477:
-------------------------------------
Joel-
Your example is using UserTransaction in an attempt to demarcate transaction boundaries,
but you are not using a JCA managed connection factory (the default one is at
java:/jmsXA), you are using a standard, vanilla non JCA JMS connection factory
(/XAConnectionFactory).
This is what I was trying to explain on the forum - any jms sessions obtained from a
standard non JCA connection factory will not be automatically enlisted in a global
transaction (for instance one which you have started using UserTransaction) .
This is normal JBoss behaviour- after all a standard jms connection factory has no
knowledge of the app server managed environment, so how can it automatically enlist
itself?
If you want to use UserTransaction to demarcate transaction boundaries (not sure why you
want to do that) then you *must* used a managed JCA connection factory.
The managed JCA connection factory is basically a layer over the actual JMS connection
factory that handles pooling, security and automatically connects up JMS transactions with
the app server global transactions - this is all explained in the JCA specification.
JBoss MQ uses the exact same approach. In fact it is not limited to JMS, when using JDBC
in jboss if you directly created a JDBC connection inside a managed EJB method, then it
would *not* automatically get enlisted in the ejb's transaction. Not surprising really
- how would the Oracle connection know about the global transaction in the first place to
enlist it?
This is why, in JBoss you create JDBC managed connection factories (these are things you
deploy, called Oracle-ds.xml for example) which wrap the underyling database connections
so they can provide the standard JCA guarantee (transactions, security etc) .
Pretty much the exact same reasoning applies for JMS - if you use the jms
connection/session directly it's not going to get enlisted - you must use the JCA
managed connection factory.
There is quite a lot of documentation on this in the wiki.
I would definitely recommend reading and getting familiar with the following two pages at
least:
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossJMSRA
http://jboss.com/wiki/Wiki.jsp?page=JBossJCA
Hope that clears things up a bit.
Messages are left in the Messages table after retry message is
printed and are retried every time the server is restarted
-------------------------------------------------------------------------------------------------------------------------
Key: JBMESSAGING-477
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-477
Project: JBoss Messaging
Issue Type: Bug
Components: Messaging Core
Affects Versions: 1.0.1.CR2
Environment: Windows XP
Reporter: Joel Lindheimer
Assigned To: Ovidiu Feodorov
Fix For: 1.0.1.CR5
Attachments: TestConsumer.java, TestJMSClient.java
I am testing Consumer.receive() with a userTransaction rollback scenario; the messages
rollback and are retried. Eventually the follwoing message is printed:
JBossMessage[49410]:PERSISTENT has exceed maximum delivery attempts and will be removed.
However, the messages are never deleted from the messages table; it is therefore retried
upon every subsequent server restart.
To reproduce just send a simple message with a consumer that does the following:
while (true) {
log.warn("whileloop+");
ut = (UserTransaction)
getInitialContext().lookup("UserTransaction");
ut.begin();
conn = (QueueConnection) this.getQueueFactory().createQueueConnection();
conn.start();
session = conn.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
receiver = session.createReceiver(getQueue());
// Note: starting the ut here does causes other issues... so i moved it
up
// ut = (UserTransaction)
getInitialContext().lookup("UserTransaction");
// ut.begin();
TextMessage msg = (TextMessage) receiver.receive(5000);
receiver.close();
session.close();
conn.close();
log.warn("msg: " + msg);
if(msg!=null) {
log.warn("msg.text: " +msg.getText());
}
ut.rollback();
(...)
Here is the server console print:
12:41:30,946 WARN [TestConsumer] msg: null
12:41:30,946 WARN [TestConsumer] whileloop-
12:41:30,946 WARN [TestConsumer] whileloop+
12:41:30,946 WARN [TestConsumer] msg: delegator->JBossMessage[49410]:PERSISTENT
12:41:30,946 WARN [TestConsumer] msg.text: Payload #2
12:41:30,946 WARN [TestConsumer] whileloop-
12:41:30,946 WARN [TestConsumer] whileloop+
12:41:30,946 WARN [TestConsumer] msg: delegator->JBossMessage[49410]:PERSISTENT
12:41:30,946 WARN [TestConsumer] msg.text: Payload #2
12:41:30,946 WARN [TestConsumer] whileloop-
12:41:30,946 WARN [TestConsumer] whileloop+
12:41:30,962 WARN [TestConsumer] msg: delegator->JBossMessage[49410]:PERSISTENT
12:41:30,962 WARN [TestConsumer] msg.text: Payload #2
12:41:30,962 WARN [TestConsumer] whileloop-
12:41:30,962 WARN [TestConsumer] whileloop+
12:41:30,962 WARN [TestConsumer] msg: delegator->JBossMessage[49410]:PERSISTENT
12:41:30,962 WARN [TestConsumer] msg.text: Payload #2
12:41:30,962 WARN [TestConsumer] whileloop-
12:41:30,962 WARN [TestConsumer] whileloop+
12:41:30,962 WARN [TestConsumer] msg: delegator->JBossMessage[49410]:PERSISTENT
12:41:30,962 WARN [TestConsumer] msg.text: Payload #2
12:41:30,962 WARN [TestConsumer] whileloop-
12:41:30,962 WARN [TestConsumer] whileloop+
12:41:30,962 WARN [TestConsumer] msg: delegator->JBossMessage[49410]:PERSISTENT
12:41:30,962 WARN [TestConsumer] msg.text: Payload #2
12:41:30,962 WARN [TestConsumer] whileloop-
12:41:30,962 WARN [TestConsumer] whileloop+
12:41:30,977 WARN [TestConsumer] msg: delegator->JBossMessage[49410]:PERSISTENT
12:41:30,977 WARN [TestConsumer] msg.text: Payload #2
12:41:30,977 WARN [TestConsumer] whileloop-
12:41:30,977 WARN [TestConsumer] whileloop+
12:41:30,977 WARN [TestConsumer] msg: delegator->JBossMessage[49410]:PERSISTENT
12:41:30,977 WARN [TestConsumer] msg.text: Payload #2
12:41:30,977 WARN [TestConsumer] whileloop-
12:41:30,977 WARN [TestConsumer] whileloop+
12:41:31,009 WARN [TestConsumer] msg: delegator->JBossMessage[49410]:PERSISTENT
12:41:31,009 WARN [TestConsumer] msg.text: Payload #2
12:41:31,009 WARN [TestConsumer] whileloop-
12:41:31,009 WARN [TestConsumer] whileloop+
12:41:31,009 WARN [TestConsumer] msg: delegator->JBossMessage[49410]:PERSISTENT
12:41:31,009 WARN [TestConsumer] msg.text: Payload #2
12:41:31,009 WARN [TestConsumer] whileloop-
12:41:31,009 WARN [TestConsumer] whileloop+
12:41:31,024 WARN [TestConsumer] msg: delegator->JBossMessage[49410]:PERSISTENT
12:41:31,024 WARN [TestConsumer] msg.text: Payload #2
12:41:31,024 WARN [TestConsumer] whileloop-
12:41:31,024 WARN [TestConsumer] whileloop+
12:41:31,024 WARN [ServerConsumerEndpoint] JBossMessage[49410]:PERSISTENT has exceed
maximum delivery attempt
s and will be removed
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira