Hello,
I am using Jboss 4.0.3RC1 and Mysql 3.23.xxx (very very old I know) and bumped into the following issue.
Jboss is running and topic subscribers are getting their messages (sent as DeliveryMode.PERSISTENT) from Mysql.
If the session was transacted (createSession (true, Session.AUTO_ACKNOWLEDGE)), then I can see a transaction ID in the table JMS_TRANSACTIONS.
Let's say I shut down Jboss then:
- the TXID in the table JMS_TRANSACTION disappears.
- when I start again Jboss then all remaining messages in JMS_MESSAGES just disappear before the topic are up!
Therefore, messages are lost accross Jboss restarts.
So, I looked into the code of the org.jboss.mq.pm.jdbc2.PersistenceManager class and found out that the startService() method calls resolveAllUncommitedTXs().
This method :
- create the tables specified internally or via mysql-jdbc2-service.xml
- change message flags and delete messages depending on their transaction op (TXOP).
Looking at line 384, the statement 'DELETE_MARKED_MESSAGES_WITH_TX' deletes all messages marked TXOP='A'. Well, that deletes them all when Jboss restarts because all remaining messages are marked with TXOP=A.
i tried to play with TX setting when creating the Session objects but it does not help. The messages left by a brutal shutdown (power outtage for example) are deleted when the PersistManager restarts.
I commented this call, recompiled jbossmq package.
The result:
- messages are not deleted anymore when Jboss (or the PersistenManager MBean) restarts
- messages are consumed by the topic subscribers when they reconnect.
My questions:
- did I misinterpret the JMS specs? I though the messages should be persistent also when the provider shuts down then restarts to guarantee later re-delivery.
- or don't I use the right Factory?
My calls are the basic ones, where I look up ConnectionFactory
topicConnectionFactory = (TopicConnectionFactory) jndiContext.lookup("ConnectionFactory");
- what are the side-effects of not deleting them when the PersistManager restarts?
Thank for your help.
Regards
Frederic
