Extracting load balancing classes from AS cluster module for

[brian.stansberry]

Opening a forum thread for discussions of http://jira.jboss.com/jira/browse/JBCLUSTER-137

First fundamental issue is the dependencies that the LoadBalancePolicy interface brings with it:

1) public void init (HARMIClient father);

This method is only used by HARMIClient (which in the AS itself is only used by HA-JNDI, and JBREM-424 will probably make that go away.) This method is implemented as a no-op in all the LoadBalancePolicy impls the AS ships with.

My inclination here is to remove this method from the interface we extract from the AS code, and leave a subinterface in the AS cluster module that includes this method.

2) public Object chooseTarget (FamilyClusterInfo clusterFamily);

This is the only method that any of our implementation classes actually implement.

Issue here is dependence on FamilyClusterInfo. Presence of this interface in the API means we need to continue to use it, or break existing custom LoadBalancePolicy impls that users may have. That would make migrating to AS 5 harder.

Tom/Ron, how do you see FamilyClusterInfo fitting into what you want to do with failover in Remoting?

3) public Object chooseTarget (FamilyClusterInfo clusterFamily, Invocation routingDecision);

The overloaded Invocation param is not actually used in any of std LoadBalancePolicy impls. However, it *is called* by all the detached invoker HAProxy impls. The ClusterChooserInterceptor used by EJB3 does not call this method.

Again, I'd prefer not to break existing custom policies. If necessary, I could add this method to the AS-specific subinterface discussed above for the init() method. But, http://jira.jboss.com/jira/browse/JBREM-385 discusses moving all the old detached invoker stuff into Remoting, so keeping it in the main interface probably makes more sense.

The problem there is you get a circular dependency -- cluster project LoadBalancePolicy depends on Invocation class from a Remoting jar; Remoting depends on LoadBalancePolicy for HA features. A solution is to move the load balance policies into Remoting as well, but then they pull FamilyClusterInfo with them. (FamilyClusterInfo does not bring any further dependencies.)

Thoughts?

[tom.elrod]

1. Agree with removing the HARMIClient.

2. FamilyClusterInfo looks fine with me to use within remoting. There are a few methods that I don't really understand what they do, such as:

public int getCursor();
public int setCursor (int cursor);
public Object getObject ();
public Object setObject (Object whatever);

(org.jboss.ha.framework.interfaces.FamilyClusterInfoImpl sheds no light on them really as they are not used for anything other than the toString()).

3. Would prefer to not have the:

public Object chooseTarget (FamilyClusterInfo clusterFamily, Invocation routingDecision);

in the root interface.

Overall, would like to have a base LoadBalancePolicy interface with just:

public Object chooseTarget (FamilyClusterInfo clusterFamily);

and then have a JBossAS specific one that extends that. Only problem is that everyone is already using the current LoadBalancePolicy, so could create another base interface the the current one extends that just has the one chooseTarget() method. Don't really know what to name it, but seems like might be the easiest approach.

Although jndi will use remoting at some point and deteached invokers will fall under remoting project at some point, don't want to factor that in too much right now as don't know when this will happen or what the impact will be.

[brian.stansberry]

2. FamilyClusterInfo looks fine with me to use within remoting. There are a few methods that I don't really understand what they do, such as:

public int getCursor();
public int setCursor (int cursor);
public Object getObject ();
public Object setObject (Object whatever);

These are used by the load balance policies. A load balance policy instance will get created with every proxy download, while the FCI instance for the family gets created on the 1st download and thereafter remains the same. So, the FCI is the natural location to store state that multiple proxies for the same family use.

cursor -- used by RoundRobin to store the index of the current target.

object -- used by FirstAvailableIdenticalAllProxies to store the current target.

Overall, would like to have a base LoadBalancePolicy interface with just:

public Object chooseTarget (FamilyClusterInfo clusterFamily);

and then have a JBossAS specific one that extends that. Only problem is that everyone is already using the current LoadBalancePolicy, so could create another base interface the the current one extends that just has the one chooseTarget() method. Don't really know what to name it, but seems like might be the easiest approach.

+1.

We can probably just call it LoadBalancePolicy and namespace it with a different package.

Although jndi will use remoting at some point and deteached invokers will fall under remoting project at some point, don't want to factor that in too much right now as don't know when this will happen or what the impact will be.

OK, for now the stuff necessary to support the legacy code will remain in AS. Even if/when the detached invoker stuff shifts to Remoting you'd probably want to package that separately, so there'll probably still be a base interface and an extended one.

[tom.elrod]

Roger. Thanks.

[brian.stansberry]

With the effort underway to consolidate the client side interceptor models (see http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3970879#3970879), need to revisit a bit the LoadBalancePolicy interface.

We'd decided earlier to create a simple base interface with only chooseTarget(FamilyClusterInfo fci) and then to leave a legacy subinterface with a method that took o.j.invocation.Invocation as a param.

If we're going to consolidate to a single interceptor model, this raises a few questions:

1) Will we get rid of the subinterface w/ o.j.invocation.Invocation? (An indirect way of asking whether we'll get rid of the old interceptor model for 5.0, or leave it around for ease of migration.)
2) Will we want a method chooseTarget(FamilyClusterInfo, o.j.aop.joinpoint.Invocation) ? This will provide an API similar to the old detached invoker model that any custom policies that people wrote can adapt to.
3) If yes to #1 and #2, in the base interface or a subinterface?
4) Another possibility Tom and I discussed is to create an abstraction of the data that would be passed in the Invocation and pass that to the LoadBalancePolicy, thus reducing the coupling to the invocation type.

[starksm64]

1) We have to drop the old interceptor/invocation if we are going to be able to unify and resuse aspects.

2-4) LoadBalancePolicy should ideally just have an abstraction of the invocation payload and metadata as that is all that it would use rather than a dependency on the org.jboss.aop.joinpoint.Invocation. I thought we were breaking out the metadata from the Invocation, but its still there. Still, I would just have chooseTarget(FamilyClusterInfo, Map) and if a policy needs the Invocation it can be added by interceptor.