3 Replies Latest reply on Jun 11, 2008 5:42 AM by Bernhard Huber

    JBoss Messaging, and JBoss Remoting in cluster environment

    Bernhard Huber Newbie

      I have question about using JBoss Remoting together with JBoss Messaging.

      The system setup is a JBoss Cluster defining queues, and connection factories,
      which are used by various single JBoss instances.

      The system setup in detail:

      A JBoss Cluster (Clu) defining clustered Queu (Q1) , and
      failover ConnectionFactories (CF).
      Clu runs on JBoss 4.2.2.GA, and JBoss Messaging 1.4.0SP3

      A single JBoss instance (Inst) deployed an MDB using
      Q1, and CF from Clu.
      Moreover a remote JMSProvider is deployed on Inst using the JBoss Messaging from Clu.
      Inst runs on JBoss 4.2.2.GA, and JBoss Messaging 1.4.0SP3.

      Initially I was using JBoss Remoting 2.2.2SP1 as it is default version when you
      install JBoss 4.2.2.GA.

      As I was testing failover in Clu I noticed that the MDBs running on Inst do not realize the failover,
      and were still trying to reconnect to a shutdown Clu instance.

      As soon as I installed JBoss Remoting 2.4.0.GA on the Clu instances, and the Inst
      cluster failover worked quite perfectly.

      The only problem is that the remoting bisocket configuration in JBoss messaging does not
      define the callbackServerHost explictly, thus I cannot configure the callbackServerHost
      in a multi-home environment.

      The bisocket URL is:

      How do I configure the callbackServerHost in jboss messaging?

      Moreover I'd like to hear if the system setup is sensible.

      The reason for choosing this system setup is that we'd like to have Clu defining only the
      JMS infrastructure, like queues, and connection factories, but deploy the applications on
      instances which do not join the cluster.

        • 1. Re: JBoss Messaging, and JBoss Remoting in cluster environme
          Tim Fox Master

          Please see the userguide for how to install JBM in JBoss AS 4.2.

          The guide mentions the remoting version to use is 2.2.2.SP4, this should work fine, and was correct at the time of writing.

          You can also use 2.2.2.SP7 which has some more bugs fixed.

          We haven't tested JBR 2.4 yet.

          • 2. Re: JBoss Messaging, and JBoss Remoting in cluster environme
            Bernhard Huber Newbie

            Hi, thx for the reply,

            I have installed the remoting version 2.2.2.SP7 on both cluster instances, and the standalone instance.

            From my testing session I have following impression:

            1. Sending a message from Inst into Q1 always works
            2. But the MDBs hosted on Inst do not always manage to register itself as listener on Q1.

            Let me detail 2:

            If I start up Clu, and startup Inst then the MDBs on Inst receive messages correctly.

            But after stopping an instance in Clu, sometimes the MDBs do not receive any messages.

            This behaviour is somewhat confusing to me as sometime the MDBs manage to follow the stop/start sequence of the Clu instances, perfectly.

            Any ideas, or hints?

            • 3. Re: JBoss Messaging, and JBoss Remoting in cluster environme
              Bernhard Huber Newbie


              I have re-checked the steps in the section 4.1.3. Extra steps to complete your installation of the JBoss Messaging documentation.

              I have fixed the configurations as explained for the Clu instances, and the standlone instance, especially I have updated the fixes
              * $JBOSS_CONFIG/deploy/jms-ds.xml, and $JBOSS_CONFIG/deploy/hajndi-jms-ds.xml
              * $JBOSS_CONFIG/conf/standardjboss.xml
              * $JBOSS_CONFIG/conf/jboss-service.xml

              Now the MDBs behave much better in case of a Clu instance stops.

              Moreover the single instance is now able to stop w/o killing it if no Clus instance is running.

              I'll make some more tests, but re-checking the config against the docs is certainly a step-forward.