[jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-477) Messages are left in the Messages table after retry message is printed and are retried every time the server is restarted
Tim Fox (JIRA)
jira-events at jboss.com
Thu Aug 3 03:15:11 EDT 2006
[ http://jira.jboss.com/jira/browse/JBMESSAGING-477?page=comments#action_12340477 ]
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
More information about the jboss-jira
mailing list