3 Replies Latest reply on Mar 21, 2013 6:06 PM by jbertram

    Local and remote clients for messaging Connection Factory

    slrslr
    slrslr Mar 21, 2013 6:21 AM

      Hello all,

       

      I have a question that bothers me about how HornetQ messaging works inside JBoss.

       

      There is by default a In-vm connection factory and a remote connection factory. Queues with JNDI names starting with java:/jboss/exported are available for remote clients and the other ones only for local clients, i.e. inside the same JVM.

       

      What I do not understand is what local/remote relies on. If you are in standalone mode, all your servers are inside the same JVM, so they are local clients. But in domain mode:

       

      - All the queues that are configured in JBoss are hosted on/started with which process ? The host controller ? It seems like all servers require a restart when a new JMS queue is created, but I think strange that the queues are hosted on each server, they must be located on a single process, no ?

      - All the servers inside the same JBoss AS as the JMS queues are considered as local or remote clients ?

       

      Thank you for your lights.

      Cheers.

        • 1. Re: Local and remote clients for messaging Connection Factory
          jbertram
          jbertram Mar 21, 2013 3:32 PM (in response to slrslr)

          What I do not understand is what local/remote relies on.

          Local and remote refers to the *clients* which use those resources.  For example, a remote client which wanted to send messages to a queue would look-up "jms/RemoteConnectionFactory" in JNDI.  It has nothing to do with standalone vs. domain mode.

           

           

          All the queues that are configured in JBoss are hosted on/started with which process ?

          JMS resources are hosted by the server in which they are deployed.

           

           

          It seems like all servers require a restart when a new JMS queue is created, but I think strange that the queues are hosted on each server, they must be located on a single process, no ?

          JMS destinations can be added and removed dynamically.  No server restart should be required.

           

           

          All the servers inside the same JBoss AS as the JMS queues are considered as local or remote clients ?

          I'm not sure what you're asking here.  If the client is in the same JVM then it's considered "local", if not then it's "remote."

          1 of 1 people found this helpful
            • Actions
          • 2. Re: Local and remote clients for messaging Connection Factory
            slrslr
            slrslr Mar 21, 2013 4:53 PM (in response to jbertram)

            Thanks for the answer.

             

            What was misleading me is that I thought that each JMS destination was deployed everywhere (on each server on the domain).

            The mapping server <-> JMS destination is less direct than in Weblogic for example where the "hosting managed server" is configured in the JMSserver and module.

             

            In JBoss this mapping is done by managing several profiles ?

            I need to do a profile A including a jms destination A and a server A, and a profile B including a jms destination B and a server B, to have A deployed only on A and B deployed only on B, or is there another way ?

             

            Thanks

              • Actions
            • 3. Re: Local and remote clients for messaging Connection Factory
              jbertram
              jbertram Mar 21, 2013 6:06 PM (in response to slrslr)

              I'm not familiar with Weblogic and how it implements this kind of functionality so I can't really speak to that point.

               

              However, in JBoss AS7 all the servers in a server-group are configured with the same profile so they are all the same.  When it comes to JMS destinations that means that every server in a server-group would each have all the same destinations deployed.  If you want servers with a different configuration then you'd need a different server-group and a different profile.

                • Actions