-
Notifications
You must be signed in to change notification settings - Fork 19
Explanation of Config Sections
High-level descriptions of config file sections.
Note that detailed explanations of these sections can be found in the XSD. This page includes high-level descriptions, more along the lines of why the sections are used.
The plugins section is used be extensions to the capabilities of the servers within the config. Generally, this is used to configure specific service elements which will map to ServiceProvider objects which can be used by entities. This might include things like sizing or location information for an on-disk storage service, for example.
Additionally, config elements can be used to provide arbitrary configuration data which is exposed to all ServiceProvider instances, when they are initialized (via PlatformConfiguration argument). This might be used to describe a global debug option or top-level directories which many services may want to share.
The entities section is used to describe entities which must always be available to clients of the cluster. This is typically used to avoid bootstrapping state issues where a client would need to bootstrap a cluster with some common utility entities required by an application. These entities can be defined, here, in order to remove that pre-bootstrap uninitialized state.
The tc.properties section exposes a list of key-value pairs to further tweak the behavior of the cluster. Note that this section is normally empty.
The servers section defines all the servers which will make up this stripe of a cluster. High-availability is enabled by having at least 2 servers in this section. Note that there is no explicit configuration of which server takes an active or passive role as that may change over the life of the cluster.
When starting a specific server, it determines which of the configured servers it is based on the name given to the start script.