|Pivotal GemFire||8.0 and later|
The server is not starting.
GFSH commands are recorded in the cluster.xml file. Local cache.xml definitions are not recorded in the cluster.xml file, and the cluster.xml file is loaded prior to the local cache.xml. If the local cache.xml file contains definitions required by the cluster.xml, then this poses a problem because those definitions are not loaded yet when the cluster.xml is loading. The result can be a server which will not start. Let's look at an example:
<?xml version="1.0" encoding="UTF-8"?> <cache xsi:schemaLocation="http://schema.pivotal.io/gemfire/cache http://schema.pivotal.io/gemfire/cache/cache-8.1.xsd" lock-lease="120" lock-timeout="60" search-timeout="300" is-server="false" copy-on-read="false" version="8.1" xmlns="http://schema.pivotal.io/gemfire/cache" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <disk-store name="mydiskstore" time-interval="60000" queue-size="50"> <region name="target"> <region-attributes data-policy="persistent-partition" disk-store-name="mydiskstore"/> </region> </cache>
As can be seen in the cluster.xml above, the region named target refers to the disk store called mydiskstore. This region was created from a template region via GFSH, and recorded in the cluster.xml, but the disk store definition is in the local cache.xml file, which will be loaded afterwards.
To summarize, the sequence of events is as follows:
- The disk store is created when the initial cache.xml is loaded.
- Then GFSH is used to create a region referencing that disk store.
- This causes the cluster.xml to be updated to reflect this region-disk store association.
- The member is then restarted.
- Upon restart, when the cluster.xml is being loaded first, it references a disk store that doesn't yet exist.
- This is because of the local cache.xml gets loaded after the cluster.xml.
By default, it is not possible to edit the cluster.xml. To edit the cluster.xml, set the following when the locator is started:
This will read the existing cluster.xml file. Please refer to the "Cluster Configuration Files and Troubleshooting" section and the "Loading Existing Configuration Files into Cluster Configuration" section of our GemFire Users Guide documentation. These sections describe this potential issue and how to resolve it in much more detail.