5 Replies Latest reply on Jan 18, 2007 9:10 AM by timfox

    jbossjta-properties has duplicated properties

    timfox

      The version of jbossjta-properties.xml in the repository:

      jboss/jbossts/resources/jbossjta-properties has multiple duplicated properties in the recovery manager config section:

      
      <properties depends="arjuna" name="recoverymanager">
       <!--
       Properties used only by the RecoveryManager.
       -->
       <!--
       Periodic recovery settings.
       Time values in this section are in seconds.
       -->
       <!--
       Interval in seconds between initiating the periodic recovery modules.
       Default is 120 seconds.
       -->
       <property
       name="com.arjuna.ats.arjuna.recovery.periodicRecoveryPeriod" value="120"/>
       <!--
       Interval in seconds between first and second pass of periodic recovery.
       Default is 10 seconds.
       -->
       <property
       name="com.arjuna.ats.arjuna.recovery.recoveryBackoffPeriod" value="10"/>
       <!--
       Periodic recovery modules to use. Invoked in sort-order of names.
       -->
       <property
       name="com.arjuna.ats.arjuna.recovery.recoveryExtension1" value="com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule"/>
       <property
       name="com.arjuna.ats.arjuna.recovery.recoveryExtension2" value="com.arjuna.ats.internal.txoj.recovery.TORecoveryModule"/>
       <!--
       Expired entry removal
       -->
       <!--
       Expiry scanners to use (order of invocation is random).
       Names must begin with "com.arjuna.ats.arjuna.recovery.expiryScanner"
       -->
       <property
       name="com.arjuna.ats.arjuna.recovery.expiryScannerTransactionStatusManager" value="com.arjuna.ats.internal.arjuna.recovery.ExpiredTransactionStatusManagerScanner"/>
       <!--
       Interval, in hours, between running the expiry scanners.
       This can be quite long. The absolute value determines the interval -
       if the value is negative, the scan will NOT be run until after one
       interval has elapsed. If positive the first scan will be immediately
       after startup. Zero will prevent any scanning.
       Default = 12 = run immediately, then every 12 hours.
       -->
       <property
       name="com.arjuna.ats.arjuna.recovery.expiryScanInterval" value="12"/>
       <!--
       Age, in hours, for removal of transaction status manager item.
       This should be longer than any ts-using process will remain running.
       Zero = Never removed. Default is 12.
       -->
       <property
       name="com.arjuna.ats.arjuna.recovery.transactionStatusManagerExpiryTime" value="12"/>
       <!--
       Use this to fix the port on which the TransactionStatusManager listens,
       The default behaviour is to use any free port.
       -->
       <property
       name="com.arjuna.ats.arjuna.recovery.transactionStatusManagerPort" value="0"/>
       <!--
       Properties used only by the RecoveryManager.
       -->
       <!--
       Periodic recovery settings.
       Time values in this section are in seconds.
       -->
       <!--
       Interval in seconds between initiating the periodic recovery modules.
       Default is 120 seconds.
       -->
       <property
       name="com.arjuna.ats.arjuna.recovery.periodicRecoveryPeriod" value="120"/>
       <!--
       Interval in seconds between first and second pass of periodic recovery.
       Default is 10 seconds.
       -->
       <property
       name="com.arjuna.ats.arjuna.recovery.recoveryBackoffPeriod" value="10"/>
       <!--
       Periodic recovery modules to use. Invoked in sort-order of names.
       -->
       <property
       name="com.arjuna.ats.arjuna.recovery.recoveryExtension1" value="com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule"/>
       <property
       name="com.arjuna.ats.arjuna.recovery.recoveryExtension2" value="com.arjuna.ats.internal.txoj.recovery.TORecoveryModule"/>
       <property
       name="com.arjuna.ats.arjuna.recovery.recoveryExtension3" value="com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule"/>
       <!--
       Expired entry removal
       -->
       <!--
       Expiry scanners to use (order of invocation is random).
       Names must begin with "com.arjuna.ats.arjuna.recovery.expiryScanner"
       -->
       <property
       name="com.arjuna.ats.arjuna.recovery.expiryScannerTransactionStatusManager" value="com.arjuna.ats.internal.arjuna.recovery.ExpiredTransactionStatusManagerScanner"/>
       <!--
       Interval, in hours, between running the expiry scanners.
       This can be quite long. The absolute value determines the interval -
       if the value is negative, the scan will NOT be run until after one
       interval has elapsed. If positive the first scan will be immediately
       after startup. Zero will prevent any scanning.
       Default = 12 = run immediately, then every 12 hours.
       -->
       <property
       name="com.arjuna.ats.arjuna.recovery.expiryScanInterval" value="12"/>
       <!--
       Age, in hours, for removal of transaction status manager item.
       This should be longer than any ts-using process will remain running.
       Zero = Never removed. Default is 12.
       -->
       <property
       name="com.arjuna.ats.arjuna.recovery.transactionStatusManagerExpiryTime" value="12"/>
       <!--
       Use this to fix the port on which the TransactionStatusManager listens,
       The default behaviour is to use any free port.
       -->
       <property
       name="com.arjuna.ats.arjuna.recovery.transactionStatusManagerPort" value="0"/>
       </properties>
      
      


      I'm assuming this is an error?

        • 1. Re: jbossjta-properties has duplicated properties
          marklittle
          • 2. Re: jbossjta-properties has duplicated properties
            timfox

            I removed the duplicated properties and followed instructions in the programming guide for configuring an XAResourceRecovery, ending up with this config:

            <?xml version="1.0" encoding="UTF-8"?>
            
            <!-- Arjuna JTA config for JBoss Messaging test suite
            This config has some quicker settings (lik recovery period) than you would
            probably have in a real production config, this is so the tests don't take aeons to run -->
            
            <transaction-service>
            
             <properties depends="common" name="arjuna">
             <!--
             Transaction Reaper Timeout (default is 120000 microseconds).
             -->
             <property
             name="com.arjuna.ats.arjuna.coordinator.txReaperTimeout" value="120000"/>
             <!--
             Transaction Reaper Mode, can be: NORMAL or DYNAMIC (default is NORMAL).
             -->
             <property name="com.arjuna.ats.arjuna.coordinator.txReaperMode" value="NORMAL"/>
             <!--
             (default is NO)
             -->
             <property name="com.arjuna.ats.arjuna.coordinator.asyncCommit" value="NO"/>
             <!--
             (default is NO)
             -->
             <property name="com.arjuna.ats.arjuna.coordinator.asyncPrepare" value="NO"/>
             <!--
             (default is YES)
             -->
             <property
             name="com.arjuna.ats.arjuna.coordinator.commitOnePhase" value="YES"/>
             <!--
             (default is defaultStore)
             -->
             <property name="com.arjuna.ats.arjuna.objectstore.localOSRoot" value="defaultStore"/>
             <!--
             default is under user.home - must be writeable!)
             -->
             <property
             name="com.arjuna.ats.arjuna.objectstore.objectStoreDir" value="ObjectStore"/>
             <!--
             (default is ON)
             -->
             <property
             name="com.arjuna.ats.arjuna.objectstore.objectStoreSync" value="ON"/>
             <!--
             (default is ShadowNoFileLockStore)
             -->
             <property
             name="com.arjuna.ats.arjuna.objectstore.objectStoreType" value="ShadowNoFileLockStore"/>
             <!--
             (default is 255)
             -->
             <property
             name="com.arjuna.ats.arjuna.objectstore.hashedDirectories" value="255"/>
             <!--
             (default is ON)
             -->
             <property
             name="com.arjuna.ats.arjuna.objectstore.transactionSync" value="ON"/>
             <!--
             (Must be unique across all Arjuna instances.)
             -->
             <property name="com.arjuna.ats.arjuna.xa.nodeIdentifier" value="node0"/>
             <!-- property
             name="com.arjuna.ats.arjuna.coordinator.actionStore"
             value="HashedActionStore"
             value="JDBCActionStore"
             -->
             <!-- property
             name="com.arjuna.ats.arjuna.objectstore.jdbcTxDbAccess"
             value="JDBCAccess"
             -->
             <!-- property
             name="com.arjuna.ats.arjuna.objectstore.objectStoreType"
             value="ShadowNoFileLockStore"
             value="JDBCStore"
             -->
             <!-- property
             name="com.arjuna.ats.arjuna.objectstore.jdbcUserDbAccess"
             value="JDBCAccess"
             -->
             <!-- property
             name="com.arjuna.ats.arjuna.objectstore.jdbcPoolSizeInitial"
             value="1"
             -->
             <!-- property
             name="com.arjuna.ats.arjuna.objectstore.jdbcPoolSizeMaximum"
             value="1"
             -->
             <!-- property
             name="com.arjuna.ats.arjuna.objectstore.jdbcPoolPutConnections"
             value="false"
             -->
             <!-- property
             name="com.arjuna.ats.arjuna.internal.arjuna.objectstore.cacheStore.size"
             value=""
             -->
             <!-- property
             name="com.arjuna.ats.arjuna.internal.arjuna.objectstore.cacheStore.period"
             value=""
             -->
             <!--
             The location for creating temporary files, e.g., Uids.
             Default is under user.home.
             IMPORTANT: make sure the directory is lockable, e.g., /tmp on Unix
             may not be!
             -->
             <!--
             <property
             name="com.arjuna.ats.arjuna.common.varDir"
             value="var"/>
             -->
             </properties>
             <properties depends="arjuna" name="recoverymanager">
             <!--
             Properties used only by the RecoveryManager.
             -->
             <!--
             Periodic recovery settings.
             Time values in this section are in seconds.
             -->
             <!--
             Interval in seconds between initiating the periodic recovery modules.
             Default is 120 seconds.
             -->
             <property
             name="com.arjuna.ats.arjuna.recovery.periodicRecoveryPeriod" value="10"/>
             <!--
             Interval in seconds between first and second pass of periodic recovery.
             Default is 10 seconds.
             -->
             <property
             name="com.arjuna.ats.arjuna.recovery.recoveryBackoffPeriod" value="2"/>
            
             <!--
             Expired entry removal
             -->
             <!--
             Expiry scanners to use (order of invocation is random).
             Names must begin with "com.arjuna.ats.arjuna.recovery.expiryScanner"
             -->
             <property
             name="com.arjuna.ats.arjuna.recovery.expiryScannerTransactionStatusManager" value="com.arjuna.ats.internal.arjuna.recovery.ExpiredTransactionStatusManagerScanner"/>
             <!--
             Interval, in hours, between running the expiry scanners.
             This can be quite long. The absolute value determines the interval -
             if the value is negative, the scan will NOT be run until after one
             interval has elapsed. If positive the first scan will be immediately
             after startup. Zero will prevent any scanning.
             Default = 12 = run immediately, then every 12 hours.
             -->
             <property
             name="com.arjuna.ats.arjuna.recovery.expiryScanInterval" value="12"/>
             <!--
             Age, in hours, for removal of transaction status manager item.
             This should be longer than any ts-using process will remain running.
             Zero = Never removed. Default is 12.
             -->
             <property
             name="com.arjuna.ats.arjuna.recovery.transactionStatusManagerExpiryTime" value="12"/>
             <!--
             Use this to fix the port on which the TransactionStatusManager listens,
             The default behaviour is to use any free port.
             -->
             <property
             name="com.arjuna.ats.arjuna.recovery.transactionStatusManagerPort" value="0"/>
             <!--
             Properties used only by the RecoveryManager.
             -->
             <!--
             Periodic recovery modules to use. Invoked in sort-order of names.
             -->
             <property
             name="com.arjuna.ats.arjuna.recovery.recoveryExtension1" value="com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule"/>
             </properties>
             <properties name="common">
             <!-- CLF 2.0 properties -->
             <property name="com.arjuna.common.util.logging.DebugLevel"
             type="System" value="0x00000000"/>
             <property name="com.arjuna.common.util.logging.FacilityLevel"
             type="System" value="0xffffffff"/>
             <property name="com.arjuna.common.util.logging.VisibilityLevel"
             type="System" value="0xffffffff"/>
             <property name="com.arjuna.common.util.logger" type="System" value="log4j"/>
             </properties>
             <properties depends="arjuna" name="txoj">
             <!--
             (default is LockStore of installation - must be writeable!)
             -->
             <!--
             <property
             name="com.arjuna.ats.txoj.lockstore.lockStoreDir"
             value="LockStore"/>
             -->
             <!--
             (default is BasicLockStore)
             -->
             <property name="com.arjuna.ats.txoj.lockstore.lockStoreType" value="BasicLockStore"/>
             <!--
             (default is NO)
             -->
             <property name="com.arjuna.ats.txoj.lockstore.multipleLockStore" value="NO"/>
             <!--
             (default is YES)
             -->
             <property name="com.arjuna.ats.txoj.lockstore.singleLockStore" value="YES"/>
             <!--
             (default is YES)
             -->
             <property
             name="com.arjuna.ats.txoj.lockstore.allowNestedLocking" value="YES"/>
             </properties>
             <properties depends="arjuna" name="jta">
            
            
             <!-- This used when deployed in the app server and we want to do a recovery of a JMS provider, the string after the semi colon
             must match the JMS provider name from the JMSProviderAdapter -->
            
             <!--
             <property name="com.arjuna.ats.jta.recovery.XAResourceRecovery.JBMESSAGING" value="org.jboss.jms.recovery.JMSProviderXAResourceRecovery;DefaultJMSProvider"/>
            -->
            
             <!-- This is used for recovery using the message bridge, in which case JMSProviderAdapters aren't deployed so the string after the semi-colon
             is first the provider name, then a comma, then the name of a properties file available on the classpath which has the server connection information, e.g:
             provider1.jndi.prop1=xxxx
             provider1.jndi.prop2=yyyy
             provider1.jndi.prop3=zzzz
             provider1.xaconnectionfactorylookup=xyz
             provider2.jndi.prop1=xxxx
             provider2.jndi.prop2=yyyy
             provider2.jndi.prop3=zzzz
             provider2.xaconnectionfactorylookup=xyz
             -->
             <property name="com.arjuna.ats.jta.recovery.XAResourceRecovery.JBMESSAGINGBRIDGE_SERVER0" value="org.jboss.jms.recovery.BridgeXAResourceRecovery;server0,bridge-recovery.properties"/>
             <property name="com.arjuna.ats.jta.recovery.XAResourceRecovery.JBMESSAGINGBRIDGE_SERVER1" value="org.jboss.jms.recovery.BridgeXAResourceRecovery;server1,bridge-recovery.properties"/>
            
             <!--
             Support subtransactions in the JTA layer?
             Default is NO.
             -->
             <property name="com.arjuna.ats.jta.supportSubtransactions" value="NO"/>
             <property name="com.arjuna.ats.jta.jtaTMImplementation" value="com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionManagerImple"/>
             <!--
             com.arjuna.ats.internal.jta.transaction.jts.TransactionManagerImple
             -->
             <property name="com.arjuna.ats.jta.jtaUTImplementation" value="com.arjuna.ats.internal.jta.transaction.arjunacore.UserTransactionImple"/>
             <!--
             com.arjuna.ats.internal.jta.transaction.jts.UserTransactionImple
             -->
             </properties>
             <properties depends="jta" name="jdbc">
             <!--
             property name="com.arjuna.ats.jdbc.isolationLevel" value="TRANSACTION_SERIALIZABLE"/>
             -->
             </properties>
            </transaction-service>
            


            I changed periodic recovery period and backoff to be pretty quick (10 and 2 seconds) so I didn't have to wait around too long for the test.

            I then start a JTA transaction with 2 participants, enlist them, delist them, and commit, and I force it so that when commit is called on the 2nd resource it throws an exception.

            This leaves the first resource heuristically committed. So I would expect recovery to want to try and recommit the 2nd resource, until it works.

            I have configured my XAResourceRecovery in the config, and I have trace statements that tell me if it gets called. But I don't notice the recovery manager ever attempting to call it (calling initialise() or getXAResource()), even though I wait for a good few minutes.

            Is there anything else I need to do get the recovery manager to run? I notice the JTA admin guide refers to starting the recovery manager as a different process, but I'm assuming that doesn't apply when the tx mgr is already running? Maybe that's an incorrect assumption?


            • 3. Re: jbossjta-properties has duplicated properties
              marklittle

              If you are running JBossTS in the application server (as per the installation instructions) then the recovery manager runs automatically for that AS instance. If you're running it outside of AS, then you need to start it yourself, either as a separate process or embedded in your application.

              • 4. Re: jbossjta-properties has duplicated properties
                timfox

                I have successfully started the recovery manager programmatically (I looked at the TransactionManagerService MBean to see how this is done):

                 RecoveryManager.delayRecoveryManagerThread();
                 recoveryManager = RecoveryManager.manager(RecoveryManager.INDIRECT_MANAGEMENT );
                


                Now I can see it starting up and telling my two configured XAResourceRecovery instances to initialise, which they then do:

                2007-01-18 13:26:46,296 13593 INFO [com.arjuna.ats.jta.logging.loggerI18N] @main [com.arjuna.ats.internal.jta.recovery.info.loading] Local XARecoveryModule loading org.jboss.jms.recovery.BridgeXAResourceRecoveryserver1,bridge-recovery.properties
                2007-01-18 13:26:46,312 13609 TRACE [org.jboss.jms.recovery.BridgeXAResourceRecovery] @main org.jboss.jms.recovery.BridgeXAResourceRecovery@1e1dadb intialise: server1,bridge-recovery.properties
                2007-01-18 13:26:46,312 13609 TRACE [org.jboss.jms.recovery.BridgeXAResourceRecovery] @main org.jboss.jms.recovery.BridgeXAResourceRecovery@1e1dadb initialised
                2007-01-18 13:26:46,312 13609 TRACE [org.jboss.jms.recovery.BridgeXAResourceRecovery] @Finalizer org.jboss.jms.recovery.BridgeXAResourceRecovery@e79839 finalizing
                2007-01-18 13:26:46,312 13609 INFO [com.arjuna.ats.jta.logging.loggerI18N] @main [com.arjuna.ats.internal.jta.recovery.info.loading] Local XARecoveryModule loading org.jboss.jms.recovery.BridgeXAResourceRecoveryserver0,bridge-recovery.properties
                2007-01-18 13:26:46,312 13609 TRACE [org.jboss.jms.recovery.BridgeXAResourceRecovery] @main org.jboss.jms.recovery.BridgeXAResourceRecovery@bac9b9 intialise: server0,bridge-recovery.properties
                2007-01-18 13:26:46,312 13609 TRACE [org.jboss.jms.recovery.BridgeXAResourceRecovery] @main org.jboss.jms.recovery.BridgeXAResourceRecovery@bac9b9 initialised
                2007-01-18 13:26:46,312 13609 INFO [com.arjuna.ats.jta.logging.loggerI18N] @main [com.arjuna.ats.internal.jta.recovery.noxanodes] No XA recovery nodes specified. Will only recover saved states.
                2007-01-18 13:26:46,312 13609 INFO [com.arjuna.ats.arjuna.logging.arjLogger] @main RecoveryManagerImple is ready on port 2204
                


                However that's the last thing the recovery manager ever does with the XAResourceRecovery instances, it never calls getXAResource() on them.

                I noticed the line
                [com.arjuna.ats.internal.jta.recovery.noxanodes] No XA recovery nodes specified. Will only recover saved states.
                


                So I made sure I have specified the following line in the config:

                <property name="com.arjuna.ats.arjuna.xa.nodeIdentifier" value="0"/>
                


                But to no avail, recovery still does not occur.

                What am I doing wrong?

                • 5. Re: jbossjta-properties has duplicated properties
                  timfox

                  Shit, no wonder I was having so much trouble. I've been working from the JTA userguide/programmers guide and I just realised there's another user's guide in Arjuna core that explains all this :)

                  Well, you guys should take it as a compliment that your code is clear enough to be able to work our what is going on by hacking it, without any real documentation to go on :)