3 Replies Latest reply on Nov 24, 2010 2:51 AM by Wolf-Dieter Fink

    Which HA-JMS ConnectionFactory?

    Gerald Turner Newbie

      How should I code transacted HA-JMS sender and receiver non-EJB clients deployed within a cluster of JBoss containers?


      The question is tricky because: we're using JBoss 4.2.3 in "all" configuration, but would like to upgrade to 5.1 without code changes; the clients are SAR deployments of custom MBeans; no EJB/MDB whatsoever.


      Various informal documentation I've been able to scrape from the web suggests looking up the ConnectionFactory from local (non-HA) JNDI with name "java:/JmsXA" and looking up the Queue from HA-JNDI.


      JmsXA is not working because evidently (and as it's name suggests) it is an XAConnectionFactory, and the code:


      QueueSession session =
          connection.createQueueSession(true, Session.SESSION_TRANSACTED);


      …is not actually honoring the transcted/mode arguments (javadoc: "usage undefined"¹).  This becomes a problem when the receiver code issues session.commit() or session.rollback() which raise the exception "TransactionInProgressException: Should not be call from a XASession".


      I've searched for examples of using XASession from a non-EJB client and haven't come up with anything.  I suppose I could try experimenting with session.getXAResource², but first problem faced would be how to allocate Xid objects, and then I imagine there will be failures because the underlying DataSource isn't XA (MySQL Cluster/NDB storage engine doesn't support XA).


      Avoiding the XA mess and trying ConnectionFactory lookup with JNDI name "java:/ConnectionFactory" isn't working either: this object only exists on the master nodes local JNDI, it's not exported to HA-JNDI.  I suppose I'll have to do remote JNDI connection to the master node?  That sounds awful since I'll also need to detect and reconnect on master node failover.


      Does JBoss 5.1 / JBoss Messaging "fix" any of this?  I could change targets but I'm having massive interoperability problems between 4.2 and 5.1 in other applications (several clusters with total of 300+ JBoss application servers, "fork-lift" upgrade of our applications isn't


      Any advice would be much appreciated!


      ¹ http://download.oracle.com/javaee/5/api/javax/jms/XAConnection.html#createSession(boolean,%20int)


      ² http://download.oracle.com/javaee/5/api/javax/jms/XASession.html#getXAResource()

        • 1. Re: Which HA-JMS ConnectionFactory?
          Wolf-Dieter Fink Master

          We've had similar problems with 4.2 => 4.3 migration.

          It is a migration from JBossMQ (HA-singleton) to JBMessaging.

          With 4.2 we use SpyTopic/Queue to have failover.

          This code must be refactored to standard JEE.

          But with JBM this problems are gone.


          Do you have a mixed environment with 4.2 and 5.1 running?

          serveral JBoss cluster with 300+ instances sounds very huge!

          • 2. Re: Which HA-JMS ConnectionFactory?
            Gerald Turner Newbie

            Thanks for the feedback.  I'm now focusing on JBoss 5.1.0 upgrade to get to JBoss Messaging.  Looks like there's a possibility to use JBoss Messaging in 4.2.3 in case there's too much breakage.


            When you say use SpyQueue, do you mean as a work-around to looking up the Queue in JNDI (e.g. new SpyQueue("queue/Whatever")), or do you mean coding with the JBossMQ implementation, SpyConnectionFactory, etc.?


            Queue lookup was the only part that works


            I overestimated 300 servers (about 100 of them don't have JBoss), the clusters average about 10 nodes and are all JBoss 4.2.3 (and 4.0.4 many years ago).  It's a lot of iron just to handle an aggregate of 4000 VoIP calls per second, the complexity is from spanning multiple data centers and icky firewalls creating fun software engineering problems

            • 3. Re: Which HA-JMS ConnectionFactory?
              Wolf-Dieter Fink Master

              AFAIK the main difference between 4.2 and 4.3 is JBM and WebServices.

              We migrate to 4.3 to have JBM (we do not use WebServices ATM)

              The migration was without not difficult for that.


              Regarding the SpyQueue, we do not use the SpyConectionFactory.