[jboss-jira] [JBoss JIRA] Closed: (JBAS-6498) JbossMQ Error in committing to JDBC Persistence: message data loss

[Adrian Brock (JIRA)]

     [ https://jira.jboss.org/jira/browse/JBAS-6498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Adrian Brock closed JBAS-6498.
------------------------------

    Resolution: Rejected
      Assignee:     (was: Adrian Brock)


Recovery from transaction commit errors is the responsiblity of the transaction manager not the resource. 

XA recovery is not enabled by default for JBossMQ because of backwards compability issues with
the configuration. If you can't follow the instructions on JBAS-1341 then ask in the forums.

> JbossMQ Error in committing to JDBC Persistence: message data loss
> ------------------------------------------------------------------
>
>                 Key: JBAS-6498
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6498
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS (JBossMQ)
>    Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.2.3.GA
>         Environment: JBoss running with JRE 1.6 and 1.5 with Oracle Thin Drivers on Various OS
>            Reporter: Bernd Eckenfels
>
> In the seldom case of JDBC Errors the JDBC Provider seems to
> a) error in the XA commit
> b) fail to delete a pending message in table, but message is dequeued from MessageCache (and delivers it again only after restart)
> c) does not retry the JDBC statement 
> This is a problem which happens on a few highly loaded systems, in order to reproduce it better, we used a fake JDBC driver to inject errors (same configuration as the last Bug but for different JDBC Statements of JBossMQ)
> So here is a sample stack trace of a failed commit (i.e. a Message Driven Bean modified a CMP as well as sent a transacted JMS MEssage via RA). The commit of the transacted sent failed at the first DB PRoblem (is not retried or "ignored").
> We think ignoring the exception might cause duplicate deliveries after restart, however it would be the better behaviour. Even better is retrying it at least once before giving up.
> 13:44:17,933 WARN  [TransactionImpl] XAException: tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=eckenfels01/2387, Br
> anchQual=, localId=2387] errorCode=XAER_RMFAIL
> org.jboss.mq.SpyXAException: Resource manager error during commit; - nested throwable: (org.jboss.mq.SpyJMSException: Co
> uld not commit tx: 233; - nested throwable: (java.sql.SQLException: this is a FAKE ERROR 2001))
>         at org.jboss.mq.SpyXAException.getAsXAException(SpyXAException.java:72)
>         at org.jboss.mq.SpyXAResource.commit(SpyXAResource.java:92)
>         at org.jboss.tm.TransactionImpl$Resource.commit(TransactionImpl.java:2253)
>         at org.jboss.tm.TransactionImpl.commitResources(TransactionImpl.java:1784)
>         at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:358)
>         at org.jboss.tm.TxManager.commit(TxManager.java:240)
>         at org.jboss.jms.asf.StdServerSession.onMessage(StdServerSession.java:351)
>         at org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(SpyMessageConsumer.java:906)
>         at org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer.java:170)
>         at org.jboss.mq.SpySession.run(SpySession.java:323)
>         at org.jboss.jms.asf.StdServerSession.run(StdServerSession.java:194)
>         at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748)
>         at java.lang.Thread.run(Thread.java:595)
> Caused by: org.jboss.mq.SpyJMSException: Could not commit tx: 233; - nested throwable: (java.sql.SQLException: this is a
>  FAKE ERROR 2001)
>         at org.jboss.mq.pm.jdbc2.PersistenceManager.commitPersistentTx(PersistenceManager.java:891)
>         at org.jboss.mq.pm.Tx.commit(Tx.java:207)
>         at org.jboss.mq.pm.TxManager.commitTx(TxManager.java:159)
>         at org.jboss.mq.server.JMSDestinationManager.transact(JMSDestinationManager.java:518)
>         at org.jboss.mq.server.JMSServerInterceptorSupport.transact(JMSServerInterceptorSupport.java:126)
>         at org.jboss.mq.security.ServerSecurityInterceptor.transact(ServerSecurityInterceptor.java:197)
>         at org.jboss.mq.server.TracingInterceptor.transact(TracingInterceptor.java:352)
>         at org.jboss.mq.server.JMSServerInvoker.transact(JMSServerInvoker.java:132)
>         at org.jboss.mq.il.jvm.JVMServerIL.transact(JVMServerIL.java:175)
>         at org.jboss.mq.Connection.send(Connection.java:1110)
>         at org.jboss.mq.SpyXAResourceManager.commit(SpyXAResourceManager.java:185)
>         at org.jboss.mq.SpyXAResource.commit(SpyXAResource.java:88)
>         ... 11 more
> Caused by: java.sql.SQLException: this is a FAKE ERROR 2001
>         at net.sf.log4jdbc.StatementSpy._reportSql(StatementSpy.java:312)
>         at net.sf.log4jdbc.StatementSpy.reportSql(StatementSpy.java:300)
>         at net.sf.log4jdbc.PreparedStatementSpy.executeUpdate(PreparedStatementSpy.java:1002)
>         at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:251)
>         at org.jboss.mq.pm.jdbc2.PersistenceManager.removeMarkedMessages(PersistenceManager.java:919)
>         at org.jboss.mq.pm.jdbc2.PersistenceManager.commitPersistentTx(PersistenceManager.java:884)
>         ... 22 more

-- 
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