2 Replies Latest reply on Nov 2, 2007 3:21 PM by Scott Marlow

    Some cluster enhancements...

    Scott Marlow Master

      Hi,

      I have been working on a few small enhancements, some of them are complete and some need more work. I would like to check in the following changes into some 4.x or 5.x release if we agree that the changes are good:

      1. new HAPartition methods for calling a specific cluster targetNode (identified with opaque server reference that is currently a org.jgroups.stack.IpAddress). This was useful for sending messages to a specific target node in the cluster.

      2. A load balancing policy based on FirstAvailable that always favors a same machine choice.

      3. A load balancing policy that always picks the ha-singleton server (depends on ha-jndi and a server side ha-singleton).

      The hapartition ehancement is minor and easy. The other changes are additions so they shouldn't break anything.

      I have a ejb enhancement as well but I'll post about that in ejb design forum.

      Thoughts?

      Scott

        • 1. Re: Some cluster enhancements...
          Brian Stansberry Master

           

          "ScottMarlowNovell" wrote:
          Hi,

          I have been working on a few small enhancements, some of them are complete and some need more work. I would like to check in the following changes into some 4.x or 5.x release if we agree that the changes are good:


          Great. It would have to be in trunk; 4.x is pretty much in maintenance mode.


          1. new HAPartition methods for calling a specific cluster targetNode (identified with opaque server reference that is currently a org.jgroups.stack.IpAddress). This was useful for sending messages to a specific target node in the cluster.


          Hmm, ability to call a single member other than coord seemed like such an obviously good thing that I had to double check to confirm it wasn't already there! :)

          Shouldn't the param be a ClusterNode, which is the type returned by getClusterNodes()?


          2. A load balancing policy based on FirstAvailable that always favors a same machine choice.


          This sounds similar to http://jira.jboss.com/jira/browse/JBAS-4455 which Galder Zamarreno is working on. Probably you guys should coordinate.


          3. A load balancing policy that always picks the ha-singleton server (depends on ha-jndi and a server side ha-singleton).


          OK. How does it work?

          • 2. Re: Some cluster enhancements...
            Scott Marlow Master

             



            Hmm, ability to call a single member other than coord seemed like such an obviously good thing that I had to double check to confirm it wasn't already there! :)
            Shouldn't the param be a ClusterNode, which is the type returned by getClusterNodes()?

            Shouldn't the param be a ClusterNode, which is the type returned by getClusterNodes()?

            Definitely, good point!



            2. A load balancing policy based on FirstAvailable that always favors a same machine choice.

            This sounds similar to http://jira.jboss.com/jira/browse/JBAS-4455 which Galder Zamarreno is working on. Probably you guys should coordinate.

            JBAS-4455 seems a little different but there could be opportunities to combine our approaches.



            3. A load balancing policy that always picks the ha-singleton server (depends on ha-jndi and a server side ha-singleton).

            OK. How does it work?

            A ha-singleton binds its location (ip address + port) to ha-jndi. The load balancing policy does a ha-jndi lookup of the singleton node and does a little magic to determine which server target is the singleton. Perhaps this could be combined with the JBAS-4455 solution, although it might be easier to understand for application developers to have separate solutions.