On 21/12/2007, at 11:26 AM, David Jencks wrote:
I've been looking at Gianni's master repo stuff and am not sure I
understand how it works so I have some questions.
1. If you deploy into the "local" config store is there any way
this can result in activity in the master or cluster stores? I
would expect not but I haven't been completely able to convince
myself of this.
You are correct.
2. If you deploy into the "master" config store can this result in
activity in the local config store? Again I'd expect not.
You are correct.
3. Does the wadi clustering builder have anything to do with which
repos an app gets installed into? Again I'd expect not.
You are correct.
4. Does the normal local attribute manager serve as attribute
manager and persistent configuration list for the master and
cluster repos? If not where do gbean customizations go for these
repos?
The GBean configurations for these configuration stores are in
plugins/clustering/clustering/src/main/plan/plan.xml. Two new
configuration stores are defined there:
1. MasterConfigurationStore: it relies on a Maven2Repository rooted
at master-configuration/. When a configuration is installed into this
MCS, it is also installed into the ClusterStore defined by the nodes
declared by the cluster configuration. By default, the cluster
configuration declares the current instance as a (local) cluster
member. This is achieved by the NodeInfo GBean. In other words, out-
of-the-box, when a configuration is installed into the MCS, it is
also installed into the ClusterStore of this Geronimo instance.
2. ClusterStore: it relies on a Maven2Repository rooted at cluster-
repository/. This configuration store is not intended to be directly
used by end-users. Although, they can directly interact with this
repo if need be.
These two configuration stores are used by the standard
ConfigurationManager. Hence configurations loaded from these stores
are altered by the default local attribute manager.
5. After you've installed an app into the master repo, with say 3
servers in the cluster or farm, and you shut down all the servers,
what happens when you restart them?
a. one of the non-master servers before the master server
b. the master server
c. the other non-master server after the master.
Do you have to do anything to get the apps running on all servers?
Let's assume that the configuration configId/artifactId/2.0/car is
distributed to the master configuration store of server MASTER. Two
servers are defined in the cluster: SERVER1 and SERVER2. In the case
of a successful distribution:
* MASTER defines the configuration configId/artifactId_G_MASTER/2.0/
car, _G_MASTER for short
* SERVER1 and SERVER2 contain the configuration configId/artifactId/
2.0/car
To start configId/artifactId/2.0/car on SERVER1 and SERVER2, you need
to start _G_MASTER on MASTER. Conversely, to stop it on SERVER1 and
SERVER2, you need to stop t_G_MASTER on MASTER.
By default, _G_MASTER starts successfully even if SERVER1 or SERVER2
are down upon start-up. This can be changed by setting the attribute
BasicClusterConfigurationController.GBEAN_ATTR_IGNORE_START_CONF_FAIL_UP
ON_START to false. In this case, _G_MASTER fails to start when
SERVER1 or SERVER2 are down upon start-up.
MASTER acts as a kind of administration server. SERVER1 and SERVER2
are "standard" servers and they can not become master (they do not
know about _G_MASTER).
Something else I was wondering about was possibly installing
configs via the plugin installer gbean which has a configured
target repo rather than directly into a config store. This would
provide transitive dependency download features from the plugin
system that don't appear to be present in the current "direct to
config store" approach. I imagine this would require all configs
to have at least a minimal geronimo-plugin.xml.... I'm thinking of
adding this in during deployment if its missing.
If you prefer to install configurations directly into a repository
instead of going systematically through a config store, then the
above design will no longer work. Having said that, it is possible to
refactor it so that clustered deployment is handled at the repository
level instead of the config store level. Let me know if you want me
to work on this refacto.
Thanks,
Gianny
This is a really nice feature!
thanks
david jencks