Refactoring of HAPartition-related services

[brian.stansberry]

Thoughts re: other cleanup of stuff that uses HAPartition. DRM, DS, HASessionState -- all are going to use JBC in 5.0. Currently ClusterPartition creates HAPartition, which then creates DRM and DS. We need to get a reference to the JBC instance to DRM and DS. 2 alternatives:

1) Inject the JBC into ClusterPartition, which passes it to HAPartition via its c'tor, which passes it to DRM and DS through c'tor. There is code now that partially does this.
2) Make DRM and DS independent services, and dependency inject the JBC instance.

I much prefer #2, unless there is some obstacle. I think the way it is now has something to do w/ how DRM and DS get state; once they get it through JBC, that reason should go away.

Even if we go w/ #1, we need to refactor the code so we no longer have HAPartitionTreeCacheImpl, DistributedStateTreeCacheImpl, etc. The standard HAPartitionImpl, DistributedStateImpl should work with JBC.

[jerrygauth]

In 5.0, HA-JNDI and DS have already been modified to use a shared instance of JBC as their data store. We should be able to modify these services to inject the cache instance instead of the current mechanisms.

I don't think that DRM has been examined but presumbaly it can also be modified to use a shared instance of JBC as its data store.

These services will also be evaluated to see if they can use a multiplexed JGroups stack with other services such as ClusterPartition. Since the channel is actually consumed by JBC, this may be dependent on JBC support for multiplexed channels.

[ben.wang]

I'd go for #2 as well. Abstractly, now that jgroups channel will be a service, I see the function of HAPartition in providing only maybe the RPC functionality. What else does it need?

[jerrygauth]

1) HAPartition provides state transfer support in addition to providing RPC capabilities. So client services can get a reference to HAPartition through the ClusterPartition mbean and then subscribe to state transfer notifications. HAPartition also makes cluster memberhip changes available to clients.

Clients should be able to obtain these services directly from JGroups. Is the intent here to remove the cluster layer on top of JGroups and expose it directly?

2) DRM can presumably be modified to use JBC as its internal store but it seems to be a different fit. If I understand DRM correctly, for a given key, it stores node-specific objects, unlike clustered JBC where the value of a key is replicated across the cluster. Of ocurse, you could replicate node/key/value across the cluster so that each JBC node had a complete set of DRM values for all nodes/keys.

[ben.wang]

Re: #1, I think HAPartition providing view change is still useful. Jgroups only emit the events but someone need to aggregate it.

As for state transfer, do we know who is using this capability now? I'd assume outside user can pretty much find this in JBC already, IMO.

[belaban]

#1 I assume instead of JGroups you meant Multiplexer right ? No service should use JGroups directly, but if you want cluster method calls, use the Multiplexer.
Currently, most services that need cluster method calls use ClusterPartition, which (internally) uses the Multiplexer. That's fine, we can gradually move those services to use the Multiplexer directly, if we want to do this at all (Brian?) !

[jerrygauth]

Bela - yes, I didn't mean direct instantiation of JGroups. I meant that third party services could configure DI of the multiplexer; this seems to be the easiest way to access multiplexed JGroups services.

[jerrygauth]

Ben - ClusterPartition state transfer is currently used by DRM and HASessionStateTransfer.

[brian.stansberry]

Re: having services work through ClusterPartition/HAPartition vs. using the multiplexer directly, I think having an abstraction on top of JGroups is useful. We're talking about having one in JBossCache as well. If people want to write services that depend on JGroups directly, they can always do that.

Right now HAPartition is really a hodge-podge. It directly provides 3 services -- RPC calls to the group, group membership, and initial state transfer. It also provides access to DRM and DS.

IMO, the first two logically go together in a service interface meant for group RPC. State transfer is a separate issue and doesn't belong in the group RPC interface. Maybe in a subinterface, but not in the base.

It would be good to remove finding the DRM and DS from the HAPartition interface. If these can be independently deployed, services that need them can have them dependency injected.

That leaves state transfer. DRM and HASessionState currently use this, but for 5.0 we are going to convert those to JBC, so they won't any more. Jerry has pointed out the service lifecycle issue where the HAPartition state transfer only works properly for mbeans deployed as part of cluster-service.xml. We could leave the state transfer methods in HAPartition as a convenience, although I'm mildly inclined to remove them.

I can see 3 broad alternatives:

1) Define a new group RPC interface. HAPartition extends this, adding in state transfer and access to DRM and DS. This provides full compatibility with the existing HAPartition. Our own code just writes to the group RPC interface, the other stuff is there for legacy user code.

2) Define a new group RPC interface. Scrap HAPartition.

3) Remove state transfer and DRM/DS access from HAPartition; it becomes the group RPC interface. I think this is bad; it's a major change w/o changing the name. Also, HAPartition is any overly broad name for a group RPC interface.

[ben.wang]

HASessionState is for the ejb2.1 sfsb, correct? So we will need to keep this in AS5.0, unfortunately.

So maybe your proposal #1 would make sense if it is not too much of hassle.

[brian.stansberry]

If possible, HASessionState is going to be moved to use JBC, so it won't need state transfer via HAPartition.

Option #1 is definitely not a hassle; may actually be less work.