7 Replies Latest reply on Apr 5, 2006 9:59 PM by jaink

    Dynamically create JMS destinations in clustered environment

    chris_pollentier

      Hi all,

      I have deployed JMS in a clustered environment, using the 'all' server configuration.
      In this configuration, the JMS DestinationManager service is deployed as a singleton service.

      I want to create queues on demand from within my application. Before we were running in a clustered environment, I retrieved the DestinationManagerMBean, and called the createQueue(..) method.
      Now this poses a problem, because the code that wants to create the queues is deployed on both JBoss instances. When I try to create a queue from the JBoss instance where the DestinationManager is NOT deployed, I get an exception saying that it cannot find the DestinationManager service (which is normal, since it is running on the other JBoss).

      My question: Is there a way to invoke a method from the singleton service (DestinationManager) from anywhere in the cluster, while the code does not know if it is running on the master node ?




        • 1. Re: Dynamically create JMS destinations in clustered environ
          vaidyatcr

          Hello,

          I noticed that you'd posted this a while ago but haven't got a response yet. I have pretty much the same problem, so if you did resolve it, can you please respond how?

          On the other hand, if you haven't been successful, then I will let you know if I get a solution.

          Thanks

          • 2. Re: Dynamically create JMS destinations in clustered environ
            chris_pollentier

            Hi,

            I did indeed found a solution for this.

            Check wiki:
            http://www.jboss.org/wiki/Wiki.jsp?page=JBossHASingletonRemoteAccess

            This wiki explains how to deploy an RMI invoker that can be used to invoke methods on singleton MBeans from anywhere in the cluster.
            This invoker is deployed as a singleton (deploy-hasingleton) on the each node in a cluster, and binds itself to HAJNDI, which makes it available cluster-wide.
            The invoker will delegate all calls to it's local MBeanServer. Since the RMIAdapter is deployed in the deploy-hasingleton directory, this will always be the MBeanServer that is also running the JMS DestinationManager MBean

            After you deploy this RMI invoker, you can create a queue at runtime by invoking the DestinationManager through this rmi-invoker:

            // Get HAJNDI InitialContext
            Properties env = new Properties();
            env.setProperty(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");
            env.setProperty(Context.PROVIDER_URL, "localhost:1100");
            env.setProperty(Context.URL_PKG_PREFIXES, "org.jboss.naming:org.jnp.interfaces");
            InitialContext context = new InitialContext(env);

            // Get the RMI Invoker
            RMIAdaptor rmiAdaptor = (RMIAdaptor) context.lookup("jmx/invoker/SingletonRMIAdaptor");

            // Create the queue by delegating the call to the 'master' server
            // through the RMI invoker
            ObjectName objectName = new ObjectName("jboss.mq:service=DestinationManager");
            rmiAdaptor.invoke(objectName, "createQueue", new Object[] {name}, new String[] {"java.lang.String"});

            This solution is working fine for me. Hope it helps you as well.

            Regards,
            Chris

            • 3. HOWTO:Dynamically create persistent JMS destinations in clus

              Hi,

              Is this way queue will be persitent..? and will the queue be added on secondary JMS server(i.e. which is not Master node)

              I need to do the same and I need the queue to be persistent and should be added on both node.


              Regards,
              Umesh

              • 4. Re: Dynamically create JMS destinations in clustered environ
                chris_pollentier

                The queue will be persistent if you configured the JMS provider to use persistent queues (the file hsqldb-jdbc2-service.xml in the deploy-hasingleton/jms directory configures the persistent storage using hypersonic DB)

                There is no secondary JMS server where the queue can be added. When deploying JMS on a clustered environment, it is running ONLY on the master node.
                Any node using JMS must connect to this node. If the node goes down, it gets redeployed on the newly selected master node (this occurs for all services deployed in the deloy-hasingleton directory)

                The service described in this thread describes a service that automatically detects the master node, and delegates the creation of JMS queues to that node. When the master node goes down, and a new node is selected to host the JMS provider, then the service will automatically direct the subsequent queue creation calls to that new node.

                For 'normal' usage of JMS (sending / receiving), use the cluster wide jndi-context (listening on port 1100) to get the JMS ConnectionFactories. The connection factories will take care of routing the message to the correct node .
                The RMIAdapter is intended to be used to invoke a method on an MBean on the master node of a cluster (e.g. when trying to create a queue at runtime),

                • 5. JBoss Support for JMS clustering
                  jaink

                  Hi,

                  I am new to JBoss and JBoss MQ but need to create clusters with cluster-wide queues and topics. Does JBoss supports it? Is it possible to route messages from one cluster to another?

                  Thanks.

                  • 6. Re: Dynamically create JMS destinations in clustered environ
                    brian.stansberry

                    From one cluster to another, or one server to another within a cluster?

                    If the latter, yes, JBoss MQ supports clustering. See http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossMQHA.

                    • 7. Re: Dynamically create JMS destinations in clustered environ
                      jaink

                      Thanks for replying. Cluster to cluster with cluster being across WAN with possibly a satellite link connecting them.