Some cluster enhancements...

[smarlow]

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

[brian.stansberry]

"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?

[smarlow]

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.