Version 3

    "Could not find new XAResource to use for recovering non-serializable XAResource" is a very generic error that you will see thrown from the recovery manager in arjuna.  Normally it will look like...

     

    2008-10-13 21:59:33,681 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-a0be25a:ca6b:48f3c9af:ba14a0be25a:ca6b:48f3c9af:ba15 >

     

    Normally this would mean that the XAResource is not Serializable , but in the case with JBoss Messaging it is usually indicative of a failure to recover the resource.  We do have a JBoss Messaging Bug associated with this behavior (JBMESSAGING-1403).

     

    In order to undersand how Arjuna(JBossTS) handles recovery, please read the Core Failure Recovery Guide.  This guide moves you through how recovery works from the Arjuna perspective.  Please review the instructions to Configure JBoss Messaging for Recovery also.

     

    When you get this error, it's important to...

    1.  Check to make sure that you have configured the jta.properties file with something similar to

     

    <property name="com.arjuna.ats.jta.recovery.XAResourceRecovery.JBMESSAGING1"
               value="org.jboss.jms.server.recovery.MessagingXAResourceRecovery;java:/DefaultJMSProvider"/>

     

    2.  Make sure the java:/DefaultJMSProvider is defined and working correctly.  It's configured in the jms-ds.xml file or the hajms-ds.xml file.

     

    3.  Check the logs to see what phase the error is happening in.  In some cases, this message will show up in the first phase, but the message will be rectified in the second phase.  It's because the recovery is happpening as the container is starting up and the messaging system has not fully loaded yet.  Here is the text about phases in the Core Failure Recovery Guide:

     

    Recovery consists of two separate passes/phases separated by two timeout periods. The first pass examines the object store for potentially failed transactions; the second pass performs crash recovery on failed transactions. The timeout between the first and second pass is known
    as the backoff period. The timeout between the end of the second pass and the start of the first pass is the recovery period. The recovery period is larger than the backoff period.The Recovery Manager invokes the first pass upon each recovery module, applies the backoff period timeout, invokes the second pass upon each recovery module and finally applies the recovery period timeout before restarting the first pass again.


    So it's possible to fail in the first pass, but succeed in the second pass.  It must succeed in the second pass.