[jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1403) Recovery doesn't hapen when JBoss Transactions Recovery Manager is configured

Recovery doesn't hapen when JBoss Transactions Recovery Manager is configured ----------------------------------------------------------------------------- Key: JBMESSAGING-1403 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1403 Project: JBoss Messaging Issue Type: Bug Components: Messaging Core Affects Versions: 1.4.0.SP3.CP02 Environment: JBoss-EAP-4.3_CP1 , JDK 1.5.0_15-b04 , Fedora 8, MySQL 5.0.45 , Enabled JBoss Transactions Recovery Manager to recover JBoss Messaging resources as per the "JBoss Messaging XA Recovery Configuration" Reporter: Tyronne Wickramarathne Assignee: Jeff Mesnil Fix For: Unscheduled Attachments: MessagingXAResourceRecovery#getXAResource().txt, server-200808131311.txt.zip, server.log, Tests.zip How to reproduce: ------------------------ -Configure jbossjta-properties.xml is configured with the following property: <property name="com.arjuna.ats.jta.recovery.XAResourceRecovery.JBMESSAGING1" value="org.jboss.jms.server.recovery.MessagingXAResourceRecovery;java:/DefaultJMSProvider"/> -Deploy the attached mdbtest.war , mymdbs.jar at JBoss-EAP. -Run the qsender.jsp : http://<your_host>:<port>/mdbtest/qsender.jsp -Kill the JBoss-EAP when all the messages are sent to the destination -Reboot the server, you'd see the messages are getting delivered, but the ERROR+WARN messages are getting logged The Tests.zip folder contains both (mdbtest.war , mymdbs.jar) libraries, configured to send 100000 messages while setting the latency in consuming messages to 500ms. You can use these libraries to reproduce this issue, quite rapidly. Findings after debugging JBM: ----------------------------------------- When you reproduce this as per the given instructions, it gives you two different behaviours. 1. You don't get any records left at JBM_MSG, JBM_MSG_REF or JBM_TX tables, once the server is killed. When you restart the server, you can find the following : 2008-07-18 11:57:44,070 ERROR [STDERR] **recoveryModules [com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule@81db25, com.arjuna.ats.internal.txoj.recovery.TORecoveryModule@15a740a, com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule@1787395] 2008-07-18 11:57:44,070 WARN [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa] [com.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa] Could not find new XAResource to use for recovering non-serializable XAResource < 131075, 28, 26, 1-7f000001:a493:487ef922:4f67f000001:a493:487ef922:4fc########################################################################## > MessagingXAResourceRecovery#getXAResource() returns the following : "res"= MessagingXAResourceWrapper (id=399) connection= null delegate= null password= null providerName= "java:/DefaultJMSProvider" count= 24 hash= 0 offset= 58 value= char[82] (id=412) username= null 2. You'd find one or more records left with at JBM_MSG, JBM_MSG_REF or JBM_TX tables, when the server is killed. At this stage, when you restart the server, you won't encounter any transaction errors from JBossTM component. Also, you can notice MessagingXAResourceRecovery#getXAResource() returns a valid XA resource. Please refer the attach document to see the content of : MessagingXAResourceRecovery#getXAResource().txt But, the message(s) remains in the database table and it doesn't get delivered to the destination or shown in the corresponding destination when you observe via JMX-Console. Also, I have attached the server.log for this scenario at TRACE level.