1 2 Previous Next 25 Replies Latest reply on Oct 19, 2012 11:31 AM by jbertram Go to original post
      • 15. Re: HA & LoadBalancing
        ataylor

        No i didnt say that, its pretty simple

         

        ha=true = inform me of all the live/backup servers in a cluster and allow me to connect to any one

         

        ha=false = i only connect to the live server i configure (i.e no failover)

        • 16. Re: HA & LoadBalancing
          zont

          OK, thanks for all explanations, but once again.

           

          What I want is:

           

          1. All connections created using the connectionfactory, which is looked up from server A, have to connect to A (there should be no connection loadbalancing etc.)
          2. The client has to switch to backup if live fails!

           

          Point 2 works. But in the same time the <ha>true</ha> activates the connection loadbalancing.

           

          How should look my configuration to achieve both points?

          • 17. Re: HA & LoadBalancing
            jbertram

            Just to add to what Andy has already said...

             

            If the administrator doesn’t define the <discovery-group-ref> in the factory, he actually wants the clients which lookup this factory, to connect to THIS node (and its backup) and not to some other in the cluster…

            The <discovery-group-ref> is simply used to discover servers for the initial connection. 

             

            Looking up a connection factory in JNDI which has a <discovery-group-ref> is like invoking

             

            org.hornetq.api.jms.HornetQJMSClient.createConnectionFactoryWithHA(DiscoveryGroupConfiguration, JMSFactoryType)
            

             

            Here's what the JavaDoc for that method has to say:

            The discoveryAddress and discoveryPort parameters in this method are used to listen for UDP broadcasts which contain connection information for members of the cluster. The broadcasted connection information is simply used to make an initial connection to the cluster, once that connection is made, up to date cluster topology information is downloaded and automatically updated whenever the cluster topology changes. If the topology includes backup servers that information is also propagated to the client so that it can know which server to failover onto in case of live server failure.

            It has nothing to do with whether or not fail-over will actually occur.  The <ha> attribute controls that.

            • 18. Re: HA & LoadBalancing
              ataylor

              you can't, if you have several servers (live and backup) running it should be transparent as to where they connect or failover to, basically what you are saying is i want to run a HA cluster but my clients to ignore this. If you need to know what server you are connecting to then you need to rethink your application.

              • 19. Re: HA & LoadBalancing
                jbertram

                I agree with Andy here that you may need to rethink your application design since anything connecting to the cluster should really be node agnostic. 

                 

                At first, I thought you might could achieve what you want by implementing a custom org.hornetq.api.core.client.loadbalance.ConnectionLoadBalancingPolicy and specifying that in your connection factory via <connection-load-balancing-policy-class-name>.  However, the way the interface is designed rules that out.

                • 20. Re: HA & LoadBalancing
                  jbertram

                  This isn't exactly what you want, but you could use the org.hornetq.api.core.client.loadbalance.RandomStickyConnectionLoadBalancingPolicy which will choose the initial node randomly then return the same node for subsequent requests.

                  • 21. Re: HA & LoadBalancing
                    zont

                    Thanks to you both, it becomes slowly clear for me.

                    If you need to know what server you are connecting to then you need to rethink your application

                     

                    I fully agree. But my application has to monitor a clustered queue on each node. The app should be able to say: Node A has 10 messages, node B has 20 messages… For this, I lookup from each node its con-factory and create a connection. The problem here is that I can’t be sure that connection created by Factory A is connected to A. Same for B. Furthermore neither factory-object nor connection-object  have methods that can help to determine the corresponding node.

                     

                    but you could use the org.hornetq.api.core.client.loadbalance.RandomStickyConnectionLoadBalancingPolicy which will choose the initial node randomly then return the same node for subsequent requests.

                     

                    I will try it out.

                    • 22. Re: HA & LoadBalancing
                      jbertram

                      A couple of ideas:

                       

                      1. If you know you have X nodes are in your cluster then you can use org.hornetq.api.core.client.loadbalance.RoundRobinConnectionLoadBalancingPolicy and get a new connection X number of times and you'll hit every node in the cluster.
                      2. If you know all the addresses/ports of the nodes in your cluster then you could use org.hornetq.api.jms.HornetQJMSClient#createConnectionFactoryWithoutHA(JMSFactoryType, TransportConfiguration...) for each node and connect directly to each one.  The point here is to bypass JNDI and configure the connection factory on the client side as you see fit.
                      • 23. Re: HA & LoadBalancing
                        zont

                        Unfortunately adding the

                         

                             org.hornetq.api.core.client.loadbalance.RandomStickyConnectionLoadBalancingPolicy

                         

                        prevents the client to switch to backup. It just fails.

                         

                        If you know you have X nodes are in your cluster then you can use org.hornetq.api.core.client.loadbalance.RoundRobinConnectionLoadBalancingPolicy and get a new connection X number of times and you'll hit every node in the cluster.

                         

                        In this case the problem remains. Yes, I can be sure that all nodes will be hit, but I still don’t know which connection belongs to which node. I need this mapping to be able to say “Node A has 10 messages”. For me it seems not possible with this solution.

                         

                        If you know all the addresses/ports of the nodes in your cluster then you could use org.hornetq.api.jms.HornetQJMSClient#createConnectionFactoryWithoutHA(JMSFactoryType, TransportConfiguration...) for each node and connect directly to each one.  The point here is to bypass JNDI and configure the connection factory on the client side as you see fit.

                         

                        I thought on it, too but I really wanted to use jndi; so the administrator can change the settings without modifying the code etc.

                        • 24. Re: HA & LoadBalancing
                          zont

                          Unfortunately adding the

                           

                               org.hornetq.api.core.client.loadbalance.RandomStickyConnectionLoadBalancingPolicy

                           

                          prevents the client to switch to backup. It just fails.

                          sorry, it is not true. I did some wrong configuration

                          • 25. Re: HA & LoadBalancing
                            jbertram

                            sorry, it is not true. I did some wrong configuration

                            That's good to know.  I was surprised by your initial result indicating that it failed.

                             

                            I thought on it, too but I really wanted to use jndi; so the administrator can change the settings without modifying the code etc.

                            You could create another connection factory in JNDI which doesn't have <ha>true<ha> specifically for this admin app.

                            1 2 Previous Next