Uploaded image for project: 'JBoss Enterprise Application Platform 4 and 5'
  1. JBoss Enterprise Application Platform 4 and 5
  2. JBPAPP-677

JBoss Messaging: UseXAForMessagePull is always false

XMLWordPrintable

    • Icon: Task Task
    • Resolution: Done
    • Icon: Major Major
    • 4.3.0.GA_CP01
    • 4.3.0.GA
    • Documentation
    • None

      JBoss Messaging doc says the UseXAForMessagePull is configurable and default is true. However, it is not configurable and is always false.

      • JBoss Messaging document:

      http://www.redhat.com/docs/manuals/jboss/jboss-eap-4.3/doc/messaging/JBoss_Messaging_User_Guide/html-single/index.html

      5.1.1.16. UseXAForMessagePull

      If true, then move a reliable message from one node to another in an XA transaction. Relaxing this gives better performance at the expense of some reliability. See the cluster configurations section for more details. Default is true.

      Chapter 6. JBoss Messaging Clustering Configuration

      When pulling reliable messages from one node to another, by default JBoss Messaging uses an XA transaction to ensure that message was removed from one node and added to another transactionally. Using XA transactions is a fairly heavyweight operation. If you are willing to to relax the reliability guarantee somewhat in order to gain some performance then you can set the attribute UseXAForMessagePull in server peer to false. By default it is true

      • Actual code in org.jboss.messaging.core.impl.clusterconnection.MessageSucker:

      //this.xa = xa;
      //XA is currently disabled for message sucking - this is because JBM 1.4.0 uses shared database so XA is
      //unnecesary - we can move the ref from one channel to another with a database update
      this.xa = false;

            timfox_jira Tim Fox (Inactive)
            rhn-support-tkimura Takayoshi Kimura
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: