Hi, I'm integrating the HornetQ's 2.5.x branch in WildFly master and have some issues with the new HA policy in this version.
First, I don't understand what the different policies are.
Could you explain them in a few sentences (esp. the COLOCATED ones)?
I have some questions about their XML representation, their WildFly definitions and the HornetQ HAPolicy API.
Let's start with the HAPolicy API
I understand the idea is that we start from one of the defined types and are able to override the properties on top of that.
However, it's very hard to understand which properties are affected by which type. If I define a BACKUP_SHARED_STORE, what's the use of a replication-cluster-name property?
It'd be a good thing to move away from a flat API with dozens of unrelated properties to a well-defined API.
E.G. all scale-down properties looks related to the SCALE_DOWN strategy. This should be reflected by the API. If I use a FULL backup strategy, why are the scale-down properties even exposed?
Could you also make the API follow a fluent builder pattern. That'd prevent to break integration everytime a new property is added to the API and it'd make the code much more readable (and the public API well defined).
At first glance, it looks that some configuration are mutually exclusive:
live or backup
shared store or replication
full or scale down strategy
remote or colocated backups
Having all the configuration in a single level makes for an unmaintainable API.
I don't want to put validation code in WildFly to check if the configuration makes sense. As much as possible, it's the API job to provide only "valid" configuration.
For WildFly integration, we provide 2 ways to configure HornetQ. Using the management API (through the CLI) and through XML.
Please note that the canonical one is the management API (the XML only generates management operations that uses this API).
It's a good idea to try to build a hornet-server using the CLI to test whether the management API is usable or not
But let's start with XML first.
I want to move away from a flat list of unrelated elements to a well-structured tree (that kind of mirrors the fluent API I talked above).
The current XSD lists all ha-policy attributes but it's too hard to understand how they relate to each other (and it does not help, I don't understand the different policy types in the first place).
Guys, could you define a few use cases that are covered by the ha-policy.
1. no HA
2. backup server with shared store
3. backup server with replication
4. colocated backup server with shared store
And what their XML looks like.
As an example, using a shared-store or replication is mutually exclusive. This should be reflected by the schema. For example I could have:
But it makes no sense to have a replication-cluster-name with a shared store.
If the XSD stipulates that I can have either a <shared-store> or a <replication>
that'd be much more simple to write the configuration.
But like I wrote, the XML is not the canonical way to build the configuration. It is WildFly management API. As an exercise, you can start WildFly with --admin-only so that there is no runtime operation, just enough to build the configuration.
As you will see, it's harder than it should be (e.g. why is the policy-type an attribute of the ha-policy if we use the policy-type resource name when the build the HAPolicy).
I can deal with updating the WildFly XML and management API but for that, I need a better understanding of the different use cases covered by the HA policy stuff.
And if you could use a fluent builder API that reflects the API that'd be much more simple to integrate and maintain.
As it stands now, I conside the ha-policy integration broken and we need to improve it before merging it in WildFly master.