4 Replies Latest reply on Nov 11, 2013 7:10 AM by tomjenkinson

    'Advanced' jbossts configuration

    janssk77

      Hi,

       

      When using jboss 5, i was able to configure a 'Volatile' action store. I understand it's not the most robust store, but in my case performance is more important than tx consistency.

      I tried to configure the Volatile store in AS 7.1.3 as well (using a custom jbossts-properties.xml file defined via the com.arjuna.ats.arjuna.common.propertiesFile systemsetting ), but doing that breaks the recovery thread. It prints out a warning message (Volatile storage does not support recovery blablabla...). That would be fine, but this recovery issue also prevents jboss from shutting down cleanly. I have to kill it to stop it.

       

      I tried to change the recovery configuration as well in jbossts-properties, but apparantly the ArjunaRecoveryManagerService class overwrite the recovery configuration mentioned in my jbossts-properties.xml file.

       

      Having the list of recovery modules hardcoded in ArjunaRecoveryManagerService makes me wonder how i should register extra recovery handlers (eg  org.hornetq.jms.server.recovery.HornetQXAResourceRecovery). Is that even possible ?

       

      On a more general note, is there a way to take complete control of the jboss ts configuration ?

        • 1. Re: 'Advanced' jbossts configuration
          tomjenkinson

          Hi,

           

          I think you have discovered a couple of limitations in the integration with WildFly.

           

          Might I recommend you to create a couple of WildFly issues (WildFly - JBoss Issue Tracker) as the issues are both in that project really rather than JBTM:

          1. Cannot stop recovery manager when configured with volatile store

          ( tried to configure the Volatile store in AS 7.1.3 as well (using a custom jbossts-properties.xml file defined via the com.arjuna.ats.arjuna.common.propertiesFile systemsetting ), but doing that breaks the recovery thread. It prints out a warning message (Volatile storage does not support recovery blablabla...). That would be fine, but this recovery issue also prevents jboss from shutting down cleanly. I have to kill it to stop it.)

           

          2. Cannot configure the list of recovery modules due to ArjunaRecoveryManagerService hardcoding them

          In terms of the specific module you mention "org.hornetq.jms.server.recovery.HornetQXAResourceRecovery" this should be done by the HQ service itself when it starts up so don't worry about that one, but its a valid point. I guess what I would do is check the system property in the ArjunaRecoveryManagerService and append the ones it wants to use there with the list you are speccing in a system property.

           

          In terms of "On a more general note, is there a way to take complete control of the jboss ts configuration ?" well, not really when integrated with WildFly, it is a design of the application server that does it this way. All you can do is when you spot a limitation let us know (via WFLY issues) and we can correct them. System properties work so long as WildFly hasn't programatically overriden them...

           

          Either assign the two issues to me if you have the prviledges or PM me the WFLY numbers and I will make sure we fix them.

           

          Thanks!

          Tom

          1 of 1 people found this helpful
          • 3. Re: 'Advanced' jbossts configuration
            tomjenkinson

            Thanks Koen, I will take a look at them.

            • 4. Re: 'Advanced' jbossts configuration
              tomjenkinson

              Hi Koen,

               

              WFLY-2454 has been moved to JBTM-2016, you will still get the stack trace to say the RM is not working which I think is fine but it will allow you to shutdown WildFly cleanly now.

               

              I am trying to gauge the priority of WFLY-2455. As I mentioned initially, the HornetQXAResourceRecovery will be registered by JCA so you don't need to worry about that one, as such although it could be a useful feature to add I would tackle it as a enhancement rather than a bug. Unless you have a test case to show that HQ doesn't perform recovery, please can you update the issue type on the Jira or let me know and I will do the same.

               

              Thanks,

              Tom