http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/ff80a931/geode-docs/configuring/cluster_config/gfsh_config_troubleshooting.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/configuring/cluster_config/gfsh_config_troubleshooting.html.md.erb b/geode-docs/configuring/cluster_config/gfsh_config_troubleshooting.html.md.erb deleted file mode 100644 index 51f89b0..0000000 --- a/geode-docs/configuring/cluster_config/gfsh_config_troubleshooting.html.md.erb +++ /dev/null @@ -1,58 +0,0 @@ ---- -title: Cluster Configuration Files and Troubleshooting ---- - -When you use the cluster configuration service in Geode, you can examine the generated configuration files in the `cluster_config` directory on the locator. `gfsh` saves configuration files at the cluster-level and at the individual group-level. - -The following directories and configuration files are available on the locator running the cluster configuration service: - -**Cluster-level configuration** -For configurations that apply to all members of a cluster, the locator creates a `cluster` subdirectory within the `cluster_config` directory (or in the cluster configuration directory when starting up the locator with the `--cluster-config-dir=value` parameter) specified All servers receive this configuration when they are started using `gfsh`. This directory contains: - -- `cluster.xml` -- A Geode `cache.xml` file containing configuration common to all members -- `cluster.properties` -- a Geode ` gemfire.properties` file containing properties common to all members -- Jar files that are intended for deployment to all members - -<!-- --> - -**Group-level configuration** -When you specify the `--group` parameter in a `gfsh` command, (for example, `start server` or `create region`) the locator writes the configurations for each group in a subdirectory with the same name as the group. When you start a server that specifies one or more group names, the server receives both the cluster-level configurations and the configurations from all groups specified. This subdirectory contains: - -- `<group-name>.xml` -- A Geode `cache.xml` file containing configurations common to all members of the group -- `<group-name>.properties` -- A Geode `gemfire.properties` file containing properties common to all members of the group -- Jar files that are intended for deployment to all members of the group - -<img src="../../images_svg/cluster-group-config.svg" id="concept_ylt_2cb_y4__image_bs1_mcb_y4" class="image" /> - -You can export a zip file that contains all artifacts of a cluster configuration. The zip file contains all of the files in the `cluster_config` (or otherwise specified) subdirectory of a locator. You can import this configuration to a new cluster. See [Exporting and Importing Cluster Configurations](export-import.html#concept_wft_dkq_34). - -## Individual Configuration Files and Cluster Configuration Files - -Geode applies the cluster-wide configuration files first and then group-level configurations next. If a member has its own configuration files defined (cache.xml and gemfire.properties files), those configurations are applied last. Whenever possible, use the member group-level configuration files in the cluster-configuration service to apply non-cluster-wide configurations on individual members. - -## Troubleshooting Tips - -- When you start a locator using `gfsh`, you should see the following message: - - ``` pre - Cluster configuration service is up and running. - ``` - - If you do not see this message, there may be a problem with the cluster configuration service. Use the `status cluster-configuration-service` command to check the status of the cluster configuration. - - - If the command returns RUNNING, the cluster configuration is running normally. - - If the command returns WAITING, run the `status locator` command. The output of this command returns the cause of the WAITING status. -- If a server start fails with the following exception: `ClusterConfigurationNotAvailableException`, the cluster configuration service may not be in the RUNNING state. Because the server requests the cluster configuration from the locator, which is not available, the `start server` command fails. -- You can determine what configurations a server received from a locator by examining the server's log file. See [Logging](../../managing/logging/logging.html#concept_30DB86B12B454E168B80BB5A71268865). -- If a `start server` command specifies a cache.xml file that conflicts with the existing cluster configuration, the server startup may fail. -- If a `gfsh` command fails because the cluster configuration cannot be saved, the following message displays: - - ``` pre - Failed to persist the configuration changes due to this command, - Revert the command to maintain consistency. Please use "status cluster-config-service" - to determine whether Cluster configuration service is RUNNING." - ``` - -- There are some types of configurations that cannot be made using `gfsh`. See [gfsh Limitations](gfsh_persist.html#concept_r22_hyw_bl__section_bn3_23p_y4). - -
http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/ff80a931/geode-docs/configuring/cluster_config/gfsh_load_from_shared_dir.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/configuring/cluster_config/gfsh_load_from_shared_dir.html.md.erb b/geode-docs/configuring/cluster_config/gfsh_load_from_shared_dir.html.md.erb deleted file mode 100644 index b9e9a5d..0000000 --- a/geode-docs/configuring/cluster_config/gfsh_load_from_shared_dir.html.md.erb +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: Loading Existing Configuration Files into Cluster Configuration ---- - -To load an existing cache.xml or gemfire.properties configuration file into a new cluster, use the `--load-cluster-configuration-from-dir` parameter when starting up the locator. - -You can use this technique to migrate a single server's configuration into the cluster configuration service. To load an existing cache.xml file or cluster configuration into a cluster, perform the following steps: - -1. Make sure the locator is not currently running. -2. Within the locator's working directory, create a `cluster_config/cluster` directory if the directory does not already exist. -3. Copy the desired configuration files (cache.xml or gemfire.properties, or both) into the `cluster_config/cluster` directory. -4. Rename the configuration files as follows: - - Rename `cache.xml` to `cluster.xml` - - Rename `gemfire.properties` to `cluster.properties` - -5. Start the locator in `gfsh` as follows: - - ``` pre - gfsh>start locator --name=<locator_name> --enable-cluster-configuration=true --load-cluster-configuration-from-dir=true - ``` - - After successful startup, the locator should report that the "Cluster configuration service is up and running." Any servers that join this cluster and have `--use-cluster-configuration` set to true will pick up these configuration files. - -**Note:** -If you make any manual modifications to the cluster.xml or cluster.properties (or group\_name.xml or group\_name.properties) files, you must stop the locator and then restart the locator using the `--load-cluster-configuration-from-dir` parameter. Direct file modifications are not picked up iby the cluster configuration service without a locator restart. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/ff80a931/geode-docs/configuring/cluster_config/gfsh_persist.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/configuring/cluster_config/gfsh_persist.html.md.erb b/geode-docs/configuring/cluster_config/gfsh_persist.html.md.erb deleted file mode 100644 index 85be33c..0000000 --- a/geode-docs/configuring/cluster_config/gfsh_persist.html.md.erb +++ /dev/null @@ -1,108 +0,0 @@ ---- -title: Overview of the Cluster Configuration Service ---- - -The Apache Geode cluster configuration service persists cluster configurations created by `gfsh` commands to the locators in a cluster and distributes the configurations to members of the cluster. - -## Why Use the Cluster Configuration Service - -We highly recommend that you use the `gfsh` command line and the cluster configuration service as the primary mechanism to manage your distributed system configuration. Using a common cluster configuration reduces the amount of time you spend configuring individual members and enforces consistent configurations when bringing up new members in your cluster. You no longer need to reconfigure each new member that you add to the cluster. You no longer need to worry about validating your cache.xml file. It also becomes easier to propagate configuration changes across your cluster and deploy your configuration changes to different environments. - -You can use the cluster configuration service to: - -- Save the configuration for an entire Apache Geode cluster. -- Restart members using a previously-saved configuration. -- Export a configuration from a development environment and migrate that configuration to create a testing or production system. -- Start additional servers without having to configure each server separately. -- Configure some servers to host certain regions and other servers to host different regions, and configure all servers to host a set of common regions. - -## Using the Cluster Configuration Service - -To use the cluster configuration service in Geode, you must use dedicated, standalone locators in your deployment. You cannot use the cluster configuration service with co-located locators (locators running in another process such as a server) or in multicast environments. - -The standalone locators distribute configuration to all locators in a cluster. Every locator in the cluster with `--enable-cluster-configuration` set to true keeps a record of all cluster-level and group-level configuration settings. - -**Note:** -The default behavior for `gfsh` is to create and save cluster configurations. You can disable the cluster configuration service by using the `--enable-cluster-configuration=false` option when starting locators. - -Subsequently, any servers that you start with `gfsh` that have `--use-cluster-configuration` set to `true` will pick up the cluster configuration from the locator as well as any appropriate group-level configurations (for member groups they belong to). To disable the cluster configuration service on a server, you must start the server with the `--use-cluster-configuration` parameter set to `false`. By default, the parameter is set to true. - -You can also load existing configuration files into the cluster configuration service by starting up a standalone locator with the parameter `--load-cluster-configuration-from-dir` set to true. See [Loading Existing Configuration Files into Cluster Configuration](gfsh_load_from_shared_dir.html). - -## How the Cluster Configuration Service Works - -When you use `gfsh` commands to create Apache Geode regions, disk-stores, and other objects, the cluster configuration service saves the configurations on each locator in the cluster (also called a Geode distributed system). If you specify a group when issuing these commands, a separate configuration is saved containing only configurations that apply to the group. - -When you use `gfsh` to start new Apache Geode servers, the locator distributes the persisted configurations to the new server. If you specify a group when starting the server, the server receives the group-level configuration in addition to the cluster-level configuration. Group-level configurations are applied after cluster-wide configurations; therefore you can use group-level to override cluster-level settings. - -<img src="../../images_svg/cluster_config_overview.svg" id="concept_r22_hyw_bl__image_jjc_vhb_y4" class="image" /> - -## gfsh Commands that Create Cluster Configurations - -The following `gfsh` commands cause the configuration to be written to all locators in the cluster (the locators write the configuration to disk): - -- `configure pdx`\* -- `create region` -- `alter region` -- `alter runtime` -- `destroy region` -- `create index` -- `destroy index` -- `create disk-store` -- `destroy disk-store` -- `create async-event-queue` -- `deploy jar` -- `undeploy jar` - -**\*** Note that the `configure pdx` command must be executed *before* starting your data members. This command does not affect any currently running members in the system. Data members (with cluster configuration enabled) that are started after running this command will pick up the new PDX configuration. - -The following gateway-related commands use the cluster configuration service, and their configuration is saved by locators: - -- `create gateway-sender` -- `create gateway-receiver` - -## <a id="concept_r22_hyw_bl__section_bn3_23p_y4" class="no-quick-link"></a>gfsh Limitations - -There are some configurations that you cannot create using `gfsh`, and that you must configure using cache.xml or the API: - -- Client cache configuration -- You cannot specify parameters and values for Java classes for the following objects: - - `function` - - `custom-load-probe` - - `cache-listener` - - `cache-loader` - - `cache-writer` - - `compressor` - - `serializer` - - `instantiantor` - - `pdx-serializer` - - **Note:** - The `configure pdx` command always specifies the `org.apache.geode.pdx.ReflectionBasedAutoSerializer` class. You cannot specify a custom PDX serializer in gfsh. - - - `custom-expiry` - - `initializer` - - `declarable` - - `lru-heap-percentage` - - `lru-memory-size` - - `partition-resolver` - - `partition-listener` - - `transaction-listener` - - `transaction-writer` -- Adding or removing a TransactionListener -- Adding JNDI bindings -- Deleting an AsyncEventQueue - -In addition, there are some limitations on configuring gateways using `gfsh`.You must use cache.xml or the Java APIs to configure the following: - -- Configuring a GatewayConflictResolver -- You cannot specify parameters and values for Java classes for the following: - - `gateway-listener` - - `gateway-conflict-resolver` - - `gateway-event-filter` - - `gateway-transport-filter` - - `gateway-event-substitution-filter` - -## <a id="concept_r22_hyw_bl__section_fh1_c3p_y4" class="no-quick-link"></a>Disabling the Cluster Configuration Service - -If you do not want to use the cluster configuration service, start up your locator with the `--enable-cluster-configuration` parameter set to false or do not use standalone locators. You will then need to configure the cache (via cache.xml or API) separately on all your distributed system members. http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/ff80a931/geode-docs/configuring/cluster_config/gfsh_remote.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/configuring/cluster_config/gfsh_remote.html.md.erb b/geode-docs/configuring/cluster_config/gfsh_remote.html.md.erb deleted file mode 100644 index 9132e44..0000000 --- a/geode-docs/configuring/cluster_config/gfsh_remote.html.md.erb +++ /dev/null @@ -1,61 +0,0 @@ ---- -title: Using gfsh to Manage a Remote Cluster Over HTTP or HTTPS ---- - -You can connect `gfsh` via HTTP or HTTPS to a remote cluster and manage the cluster using `gfsh` commands. - -To connect `gfsh` using the HTTP protocol to a remote GemFire cluster: - -1. Launch `gfsh`. See [Starting gfsh](../../tools_modules/gfsh/starting_gfsh.html#concept_DB959734350B488BBFF91A120890FE61). -2. When starting the remote cluster on the remote host, you can optionally specify `--http-bind-address` and `--http-service-port` as GemFire properties when starting up your JMX manager (server or locator). These properties can be then used in the URL used when connecting from your local system to the HTTP service in the remote cluster. For example: - - ``` pre - gfsh>start server --name=server1 --J=-Dgemfire.jmx-manager=true \ - --J=-Dgemfire.jmx-manager-start=true --J=-Dgemfire.http-service-port=8080 \ - --J=-Dgemfire.http-service-bind-address=myremotecluster.example.com - ``` - - This command must be executed directly on the host machine that will ultimately act as the remote GemFire server that hosts the HTTP service for remote administration. (You cannot launch a GemFire server remotely.) - -3. On your local system, run the `gfsh` `connect` command to connect to the remote system. Include the `--use-http` and `--url` parameters. For example: - - ``` pre - gfsh>connect --use-http=true --url="http://myremotecluster.example.com:8080/gemfire/v1"; - - Successfully connected to: GemFire Manager's HTTP service @ http://myremotecluster.example.com:8080/gemfire/v1 - ``` - - See [connect](../../tools_modules/gfsh/command-pages/connect.html). - - `gfsh` is now connected to the remote system. Most `gfsh` commands will now execute on the remote system; however, there are exceptions. The following commands are executed on the local cluster: - - `alter disk-store` - - `compact offline-disk-store` - - `describe offline-disk-store` - - `help` - - `hint` - - `sh` (for executing OS commands) - - `sleep` - - `start jconsole` (however, you can connect JConsole to a remote cluster when gfsh is connected to the cluster via JMX) - - `start jvisualvm` - - `start locator` - - `start server` - - `start vsd` - - `status locator``*` - - `status server``*` - - `stop locator``*` - - `stop server``*` - - `run` (for executing gfsh scripts) - - `validate disk-store` - - `version` - - `*`You can stop and obtain the status of *remote locators and servers* when `gfsh` is connected to the cluster via JMX or HTTP/S by using the `--name` option for these `stop`/`status` commands. If you are using the `--pid` or `--dir` option for these commands, then the` stop`/`status` commands are executed only locally. - -To configure SSL for the remote connection (HTTPS), enable SSL for the `http` component -in <span class="ph filepath">gemfire.properties</span> or <span class="ph -filepath">gfsecurity-properties</span> or upon server startup. See -[SSL](../../managing/security/ssl_overview.html) for details on configuring SSL parameters. These -SSL parameters also apply to all HTTP services hosted on the configured JMX Manager, which can -include the following: - -- Developer REST API service -- Pulse monitoring tool http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/ff80a931/geode-docs/configuring/cluster_config/persisting_configurations.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/configuring/cluster_config/persisting_configurations.html.md.erb b/geode-docs/configuring/cluster_config/persisting_configurations.html.md.erb deleted file mode 100644 index e18bb30..0000000 --- a/geode-docs/configuring/cluster_config/persisting_configurations.html.md.erb +++ /dev/null @@ -1,320 +0,0 @@ ---- -title: TutorialâCreating and Using a Cluster Configuration ---- - -A short walk-through that uses a single computer to demonstrate how to use `gfsh` to create a cluster configuration for a Geode cluster. - -The `gfsh` command-line tool allows you to configure and start a Geode cluster. The cluster configuration service uses Apache Geode locators to store the configuration at the group and cluster levels and serves these configurations to new members as they are started. The locators store the configurations in a hidden region that is available to all locators and also write the configuration data to disk as XML files. Configuration data is updated as `gfsh` commands are executed. - -This section provides a walk-through example of configuring a simple Apache Geode cluster and then re-using that configuration in a new context. - -1. Create a working directory (For example:`/home/username/my_gemfire`) and switch to the new directory. This directory will contain the configurations for your cluster. - -2. Start the `gfsh` command-line tool. For example: - - ``` pre - $ gfsh - ``` - - The `gfsh` command prompt displays. - - ``` pre - _________________________ __ - / _____/ ______/ ______/ /____/ / - / / __/ /___ /_____ / _____ / - / /__/ / ____/ _____/ / / / / - /______/_/ /______/_/ /_/ 1.0.0 - - Monitor and Manage Apache Geode - gfsh> - - ``` - -3. Start a locator using the command in the following example: - - ``` pre - gfsh>start locator --name=locator1 - Starting a GemFire Locator in /Users/username/my_gemfire/locator1... - ............................. - Locator in /Users/username/my_gemfire/locator1 on 192.0.2.0[10334] as locator1 is currently online. - Process ID: 5203 - Uptime: 15 seconds - GemFire Version: 8.1.0 - Java Version: 1.7.0_71 - Log File: /Users/username/my_gemfire/locator1/locator1.log - JVM Arguments: -Dgemfire.enable-cluster-configuration=true - -Dgemfire.load-cluster-configuration-from-dir=false - -Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true - -Dsun.rmi.dgc.server.gcInterval=9223372036854775806 - Class-Path: /Users/username/Pivotal_GemFire_810_b50582_Linux/lib/gemfire.jar - :/Users/username/Pivotal_GemFire_810_b50582_Linux/lib/locator-dependencies.jar - - Successfully connected to: [host=192.0.2.0, port=1099] - - Cluster configuration service is up and running. - ``` - - Note that `gfsh` responds with a message indicating that the cluster configuration service is up and running. If you see a message indicating a problem, review the locator log file for possible errors. The path to the log file is displayed in the output from `gfsh`. - -4. Start Apache Geode servers using the commands in the following example: - - ``` pre - gfsh>start server --name=server1 --group=group1 - Starting a GemFire Server in /Users/username/my_gemfire/server1... - ..... - Server in /Users/username/my_gemfire/server1 on 192.0.2.0[40404] as server1 is currently online. - Process ID: 5627 - Uptime: 2 seconds - GemFire Version: 8.1.0 - Java Version: 1.7.0_71 - Log File: /Users/username/my_gemfire/server1/server1.log - JVM Arguments: -Dgemfire.default.locators=192.0.2.0[10334] -Dgemfire.groups=group1 - -Dgemfire.use-cluster-configuration=true -XX:OnOutOfMemoryError=kill -KILL %p - -Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true - -Dsun.rmi.dgc.server.gcInterval=9223372036854775806 - Class-Path: /Users/username/Pivotal_GemFire_810_b50582_Linux/lib/gemfire.jar - :/Users/username/Pivotal_GemFire_810_b50582_Linux/lib/server-dependencies.jar - - gfsh>start server --name=server2 --group=group1 --server-port=40405 - Starting a GemFire Server in /Users/username/my_gemfire/server2... - ..... - Server in /Users/username/my_gemfire/server2 on 192.0.2.0[40405] as server2 is currently online. - Process ID: 5634 - Uptime: 2 seconds - GemFire Version: 8.1.0 - Java Version: 1.7.0_71 - Log File: /Users/username/my_gemfire/server2/server2.log - JVM Arguments: -Dgemfire.default.locators=192.0.2.0[10334] -Dgemfire.groups=group1 - -Dgemfire.use-cluster-configuration=true -XX:OnOutOfMemoryError=kill -KILL %p - -Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true - -Dsun.rmi.dgc.server.gcInterval=9223372036854775806 - Class-Path: /Users/username/Pivotal_GemFire_810_b50582_Linux/lib/gemfire.jar - :/Users/username/Pivotal_GemFire_810_b50582_Linux/lib/server-dependencies.jar - - gfsh>start server --name=server3 --server-port=40406 - Starting a GemFire Server in /Users/username/my_gemfire/server3... - ..... - Server in /Users/username/my_gemfire/server3 on 192.0.2.0[40406] as server3 is currently online. - Process ID: 5637 - Uptime: 2 seconds - GemFire Version: 8.1.0 - Java Version: 1.7.0_71 - Log File: /Users/username/my_gemfire/server3/server3.log - JVM Arguments: -Dgemfire.default.locators=192.0.2.0[10334] - -Dgemfire.use-cluster-configuration=true -XX:OnOutOfMemoryError=kill -KILL %p - -Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true - -Dsun.rmi.dgc.server.gcInterval=9223372036854775806 - Class-Path: /Users/username/Pivotal_GemFire_810_b50582_Linux/lib/gemfire.jar - :/Users/username/Pivotal_GemFire_810_b50582_Linux/lib/server-dependencies.jar - ``` - - Note that the `gfsh` commands you used to start `server1` and `server2` specify a group named `group1` while the command for `server3` did not specify a group name. - -5. Create some regions using the commands in the following example: - - ``` pre - gfsh>create region --name=region1 --group=group1 --type=REPLICATE - Member | Status - ------- | -------------------------------------- - server2 | Region "/region1" created on "server2" - server1 | Region "/region1" created on "server1" - - gfsh>create region --name=region2 --type=REPLICATE - Member | Status - ------- | -------------------------------------- - server1 | Region "/region2" created on "server1" - server2 | Region "/region2" created on "server2" - server3 | Region "/region2" created on "server3" - ``` - - Note that `region1` is created on all cache servers that specified the group named `group1` when starting the cache server (`server1` and `server2`, in this example). `region2` is created on all members because no group was specified. - -6. Deploy jar files. Use the `gfsh deploy` command to deploy application jar files to all members or to a specified group of members. The following example deploys the `mail.jar` and `mx4j.jar` files from the distribution. (Note: This is only an example, you do not need to deploy these files to use the Cluster Configuration Service. Alternately, you can use any two jar files for this demonstration.) - - ``` pre - gfsh>deploy --group=group1 --jar=${SYS_GEMFIRE_DIR}/lib/mail.jar - Post substitution: deploy --group=group1 --jar=/Users/username/Pivotal_GemFire_810_b50582_Linux/lib/mail.jar - Member | Deployed JAR | Deployed JAR Location - ------- | ------------ | ------------------------------------------------- - server1 | mail.jar | /Users/username/my_gemfire/server1/vf.gf#mail.jar#1 - server2 | mail.jar | /Users/username/my_gemfire/server2/vf.gf#mail.jar#1 - - gfsh>deploy --jar=${SYS_GEMFIRE_DIR}/lib/mx4j.jar - Post substitution: deploy --jar=/Users/username/Pivotal_GemFire_810_b50582_Linux/lib/mx4j.jar - Member | Deployed JAR | Deployed JAR Location - ------- | ------------ | ------------------------------------------------- - server1 | mx4j.jar | /Users/username/my_gemfire/server1/vf.gf#mx4j.jar#1 - server2 | mx4j.jar | /Users/username/my_gemfire/server2/vf.gf#mx4j.jar#1 - server3 | mx4j.jar | /Users/username/my_gemfire/server3/vf.gf#mx4j.jar#1 - ``` - - Note that the `mail.jar` file was deployed only to the members of `group1` and the `mx4j.jar` was deployed to all members. - -7. Export the cluster configuration. - You can use the `gfsh export cluster-configuration` command to create a zip file that contains the cluster's persisted configuration. The zip file contains a copy of the contents of the `cluster_config` directory. For example: - - ``` pre - gfsh>export cluster-configuration --zip-file-name=myClusterConfig.zip --dir=/Users/username - ``` - - Apache Geode writes the cluster configuration to the specified zip file. - - ``` pre - Downloading cluster configuration : /Users/username/myClusterConfig.zip - ``` - - The remaining steps demonstrate how to use the cluster configuration you just created. - -8. Shut down the cluster using the following commands: - - ``` pre - gfsh>shutdown --include-locators=true - As a lot of data in memory will be lost, including possibly events in queues, do you - really want to shutdown the entire distributed system? (Y/n): Y - Shutdown is triggered - - gfsh> - No longer connected to 192.0.2.0[1099]. - gfsh> - ``` - -9. Exit the `gfsh` command shell: - - ``` pre - gfsh>quit - Exiting... - ``` - -10. Create a new working directory (for example: `new_gemfire`) and switch to the new directory. -11. Start the `gfsh` command shell: - - ``` pre - $ gfsh - ``` - -12. Start a new locator. For example: - - ``` pre - gfsh>start locator --name=locator2 --port=10335 - Starting a GemFire Locator in /Users/username/new_gemfire/locator2... - ............................. - Locator in /Users/username/new_gemfire/locator2 on 192.0.2.0[10335] as locator2 is currently online. - Process ID: 5749 - Uptime: 15 seconds - GemFire Version: 8.1.0 - Java Version: 1.7.0_71 - Log File: /Users/username/new_gemfire/locator2/locator2.log - JVM Arguments: -Dgemfire.enable-cluster-configuration=true - -Dgemfire.load-cluster-configuration-from-dir=false - -Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true - -Dsun.rmi.dgc.server.gcInterval=9223372036854775806 - Class-Path: /Users/username/Pivotal_GemFire_810_b50582_Linux/lib/gemfire.jar - :/Users/username/Pivotal_GemFire_810_b50582_Linux/lib/locator-dependencies.jar - - Successfully connected to: [host=192.0.2.0, port=1099] - - Cluster configuration service is up and running. - ``` - -13. Import the cluster configuration using the `import cluster-configuration` command. For example: - - ``` pre - gfsh>import cluster-configuration --zip-file-name=/Users/username/myClusterConfig.zip - Cluster configuration successfully imported - ``` - - Note that the `locator2` directory now contains a `cluster_config` subdirectory. - -14. Start a server that does not reference a group: - - ``` pre - gfsh>start server --name=server4 --server-port=40414 - Starting a GemFire Server in /Users/username/new_gemfire/server4... - ........ - Server in /Users/username/new_gemfire/server4 on 192.0.2.0[40414] as server4 is currently online. - Process ID: 5813 - Uptime: 4 seconds - GemFire Version: 8.1.0 - Java Version: 1.7.0_71 - Log File: /Users/username/new_gemfire/server4/server4.log - JVM Arguments: -Dgemfire.default.locators=192.0.2.0[10335] - -Dgemfire.use-cluster-configuration=true -XX:OnOutOfMemoryError=kill -KILL %p - -Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true - -Dsun.rmi.dgc.server.gcInterval=9223372036854775806 - Class-Path: /Users/username/Pivotal_GemFire_810_b50582_Linux/lib/gemfire.jar - :/Users/username/Pivotal_GemFire_810_b50582_Linux/lib/server-dependencies.jar - ``` - -15. Start another server that references `group1`: - - ``` pre - gfsh>start server --name=server5 --group=group1 --server-port=40415 - Starting a GemFire Server in /Users/username/new_gemfire/server5... - ..... - Server in /Users/username/new_gemfire/server2 on 192.0.2.0[40415] as server5 is currently online. - Process ID: 5954 - Uptime: 2 seconds - GemFire Version: 8.1.0 - Java Version: 1.7.0_71 - Log File: /Users/username/new_gemfire/server5/server5.log - JVM Arguments: -Dgemfire.default.locators=192.0.2.0[10335] -Dgemfire.groups=group1 - -Dgemfire.use-cluster-configuration=true -XX:OnOutOfMemoryError=kill -KILL %p - -Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true - -Dsun.rmi.dgc.server.gcInterval=9223372036854775806 - Class-Path: /Users/username/Pivotal_GemFire_810_b50582_Linux/lib/gemfire.jar - :/Users/username/Pivotal_GemFire_810_b50582_Linux/lib/server-dependencies.jar - ``` - -16. Use the `list regions` command to display the configured regions. Note that region1 and region2, which were configured in the original cluster level are available. - - ``` pre - gfsh>list regions - List of regions - --------------- - region1 - region2 - ``` - -17. Use the `describe region` command to see which members host each region. Note that region1 is hosted only by server5 because server5 was started using the group1 configuration. region2 is hosted on both server4 and server5 because region2 was created without a group specified. - - ``` pre - gfsh>describe region --name=region1 - .......................................................... - Name : region1 - Data Policy : replicate - Hosting Members : server5 - - Non-Default Attributes Shared By Hosting Members - - Type | Name | Value - ------ | ---- | ----- - Region | size | 0 - - - gfsh>describe region --name=region2 - .......................................................... - Name : region2 - Data Policy : replicate - Hosting Members : server5 - server4 - - Non-Default Attributes Shared By Hosting Members - - Type | Name | Value - ------ | ---- | ----- - Region | size | 0 - ``` - - This new cluster uses the same configuration as the original system. You can start any number of servers using this cluster configuration. All servers will receive the cluster-level configuration. Servers that specify `group1` also receive the `group1` configuration. - -18. Shut down your cluster using the following commands: - - ``` pre - gfsh>shutdown --include-locators=true - As a lot of data in memory will be lost, including possibly events in queues, - do you really want to shutdown the entire distributed system? (Y/n): Y - Shutdown is triggered - - gfsh> - No longer connected to 192.0.2.0[1099]. - ``` http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/ff80a931/geode-docs/configuring/cluster_config/using_member_groups.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/configuring/cluster_config/using_member_groups.html.md.erb b/geode-docs/configuring/cluster_config/using_member_groups.html.md.erb deleted file mode 100644 index 524d787..0000000 --- a/geode-docs/configuring/cluster_config/using_member_groups.html.md.erb +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: Using Member Groups ---- - -Apache Geode allows you to organize your distributed system members into logical member groups. - -The use of member groups in Apache Geode is optional. The benefit of using member groups is the ability to coordinate certain operations on members based on logical group membership. For example, by defining and using member groups you can: - -- Alter a subset of configuration properties for a specific member or members. See [alter runtime](../../tools_modules/gfsh/command-pages/alter.html#topic_7E6B7E1B972D4F418CB45354D1089C2B) in `gfsh`. -- Perform certain disk operations like disk-store compaction across a member group. See [Disk Store Commands](../../tools_modules/gfsh/quick_ref_commands_by_area.html#topic_1ACC91B493EE446E89EC7DBFBBAE00EA) for a list of commands. -- Manage specific indexes or regions across all members of a group. -- Start and stop multi-site (WAN) services such as gateway senders and gateway receivers across a member group. -- Deploy or undeploy JAR applications on all members in a group. -- Execute functions on all members of a specific group. - -You define group names in the `groups` property of your member's `gemfire.properties` file or upon member startup in `gfsh`. - -**Note:** -Any roles defined in the currently existing `roles` property will now be considered a group. If you wish to add membership roles to your distributed system, you should add them as member groups in the `groups` property. The `roles` property has been deprecated in favor of using the `groups` property. - -To add a member to a group, add the name of a member group to the `gemfire.properties` file of the member prior to startup or you can start up a member in `gfsh` and pass in the `--group` argument at startup time. - -A single member can belong to more than one group. - -Member groups can also be used to organize members from either a client's perspective or from a peer member's perspective. See [Organizing Peers into Logical Member Groups](../../topologies_and_comm/p2p_configuration/configuring_peer_member_groups.html) and [Organizing Servers Into Logical Member Groups](../../topologies_and_comm/cs_configuration/configure_servers_into_logical_groups.html) for more information. On the client side, you can supply the member group name when configuring a client's connection pool. Use the <pool server-group> element in the client's cache.xml. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/ff80a931/geode-docs/configuring/running/change_file_spec.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/configuring/running/change_file_spec.html.md.erb b/geode-docs/configuring/running/change_file_spec.html.md.erb deleted file mode 100644 index 8edb68b..0000000 --- a/geode-docs/configuring/running/change_file_spec.html.md.erb +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: Changing the File Specifications ---- - -You can change all file specifications in the `gemfire.properties` file and at the command line. - -**Note:** -Geode applications can use the API to pass `java.lang.System properties` to the distributed system connection. This changes file specifications made at the command line and in the `gemfire.properties`. You can verify an applicationâs property settings in the configuration information logged at application startup. The configuration is listed when the `gemfire.properties` `log-level` is set to `config` or lower. - -This invocation of the application, `testApplication.TestApp1`, provides non-default specifications for both the `cache.xml` and `gemfire.properties`: - -``` pre -java -Dgemfire.cache-xml-file= -/gemfireSamples/examples/dist/cacheRunner/queryPortfolios.xml --DgemfirePropertyFile=defaultConfigs/gemfire.properties -testApplication.TestApp1 -``` - -The gfsh start server command can use the same specifications: - -``` pre -gfsh>start server --J-Dgemfire.cache-xml-file=/gemfireSamples/examples/dist/cacheRunner/queryPortfolios.xml --J-DgemfirePropertyFile=defaultConfigs/gemfire.properties -``` - -You can also change the specifications for the `cache.xml` file inside the `gemfire.properties` file. - -**Note:** -Specifications in `gemfire.properties` files cannot use environment variables. - -Example `gemfire.properties` file with non-default `cache.xml` specification: - -``` pre -#Tue May 09 17:53:54 PDT 2006 -mcast-address=192.0.2.0 -mcast-port=10333 -locators= -cache-xml-file=/gemfireSamples/examples/dist/cacheRunner/queryPortfolios.xml -``` http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/ff80a931/geode-docs/configuring/running/default_file_specs.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/configuring/running/default_file_specs.html.md.erb b/geode-docs/configuring/running/default_file_specs.html.md.erb deleted file mode 100644 index 37f9ee3..0000000 --- a/geode-docs/configuring/running/default_file_specs.html.md.erb +++ /dev/null @@ -1,59 +0,0 @@ ---- -title: Default File Specifications and Search Locations ---- - -Each file has a default name, a set of file search locations, and a system property you can use to override the defaults. - -To use the default specifications, place the file at the top level of its directory or jar file. The system properties are standard file specifications that can have absolute or relative pathnames and filenames. - -**Note:** -If you do not specify an absolute file path and name, the search examines all search locations for the file. - -<table> -<colgroup> -<col width="33%" /> -<col width="33%" /> -<col width="33%" /> -</colgroup> -<thead> -<tr class="header"> -<th>Default File Specification</th> -<th>Search Locations for Relative File Specifications</th> -<th>Available Property for File Specification</th> -</tr> -</thead> -<tbody> -<tr class="odd"> -<td><code class="ph codeph">gemfire.properties</code></td> -<td><ol> -<li>current directory</li> -<li>home directory</li> -<li>CLASSPATH</li> -</ol></td> -<td>As a Java system property, use <code class="ph codeph">gemfirePropertyFile</code></td> -</tr> -<tr class="even"> -<td><code class="ph codeph">cache.xml</code></td> -<td><ol> -<li>current directory</li> -<li>CLASSPATH</li> -</ol></td> -<td>In <code class="ph codeph">gemfire.properties</code>, use the <code class="ph codeph">cache-xml-file</code> property</td> -</tr> -</tbody> -</table> - -Examples of valid `gemfirePropertyFile` specifications: - -- `/zippy/users/jpearson/gemfiretest/gemfire.properties` -- `c:\gemfiretest\gemfire.prp` -- `myGF.properties` -- `test1/gfprops` - -For the `test1/gfprops` specification, if you launch your Geode system member from `/testDir` in a Unix file system, Geode looks for the file in this order until it finds the file or exhausts all locations: - -1. `/testDir/test1/gfprops` -2. `<yourHomeDir>/test1/gfprops` -3. under every location in your `CLASSPATH` for `test1/gfprops` - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/ff80a931/geode-docs/configuring/running/deploy_config_files_intro.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/configuring/running/deploy_config_files_intro.html.md.erb b/geode-docs/configuring/running/deploy_config_files_intro.html.md.erb deleted file mode 100644 index 758b25a..0000000 --- a/geode-docs/configuring/running/deploy_config_files_intro.html.md.erb +++ /dev/null @@ -1,17 +0,0 @@ ---- -title: Main Steps to Deploying Configuration Files ---- - -These are the basic steps for deploying configuration files, with related detail in sections that follow. - -1. Determine which configuration files you need for your installation. -2. Place the files in your directories or jar files. -3. For any file with a non-default name or location, provide the file specification in the system properties file and/or in the member `CLASSPATH.` - -## <a id="concept_337B365782E44951B73F33E1E17AB07B__section_53C98F9DB1584E3BABFA315CDF254A92" class="no-quick-link"></a>Geode Configuration Files - -- `gemfire.properties`. Contains the settings required by members of a distributed system. These settings include licensing, system member discovery, communication parameters, logging, and statistics. See the [Reference](../../reference/book_intro.html#reference). -- **`gfsecurity.properties`**. An optional separate file that contains security-related (`security-*`) settings that are otherwise defined in `gemfire.properties`. Placing these member properties into a separate file allows you to restrict user access to those specific settings. See the [Reference](../../reference/book_intro.html#reference). -- `cache.xml`. Declarative cache configuration file. This file contains XML declarations for cache, region, and region entry configuration. You also use it to configure disk stores, database login credentials, server and remote site location information, and socket information. See [cache.xml](../../reference/topics/chapter_overview_cache_xml.html#cache_xml). - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/ff80a931/geode-docs/configuring/running/deploying_config_files.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/configuring/running/deploying_config_files.html.md.erb b/geode-docs/configuring/running/deploying_config_files.html.md.erb deleted file mode 100644 index 76c036a..0000000 --- a/geode-docs/configuring/running/deploying_config_files.html.md.erb +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: Deploying Configuration Files without the Cluster Configuration Service ---- - -You can deploy your Apache Geode configuration files in your system directory structure or in jar files. You determine how you want to deploy your configuration files and set them up accordingly. - -**Note:** -If you use the cluster configuration service to create and manage your Apache Geode cluster configuration, the procedures described in this section are not needed because Geode automatically manages the distribution of the configuration files and jar files to members of the cluster. See [Overview of the Cluster Configuration Service](../cluster_config/gfsh_persist.html). - -You can use the procedures described in this section to distribute configurations that are member-specific, or for situations where you do not want to use the cluster configuration service. - -- **[Main Steps to Deploying Configuration Files](../../configuring/running/deploy_config_files_intro.html)** - - These are the basic steps for deploying configuration files, with related detail in sections that follow. - -- **[Default File Specifications and Search Locations](../../configuring/running/default_file_specs.html)** - - Each file has a default name, a set of file search locations, and a system property you can use to override the defaults. - -- **[Changing the File Specifications](../../configuring/running/change_file_spec.html)** - - You can change all file specifications in the `gemfire.properties` file and at the command line. - -- **[Deploying Configuration Files in JAR Files](../../configuring/running/deploying_config_jar_files.html)** - - This section provides a procedure and an example for deploying configuration files in JAR files. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/ff80a931/geode-docs/configuring/running/deploying_config_jar_files.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/configuring/running/deploying_config_jar_files.html.md.erb b/geode-docs/configuring/running/deploying_config_jar_files.html.md.erb deleted file mode 100644 index bf855c6..0000000 --- a/geode-docs/configuring/running/deploying_config_jar_files.html.md.erb +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: Deploying Configuration Files in JAR Files ---- - -This section provides a procedure and an example for deploying configuration files in JAR files. - -**Procedure** - -1. Jar the files. -2. Set the Apache Geode system properties to point to the files as they reside in the jar file. -3. Include the jar file in your `CLASSPATH.` -4. Verify the jar file copies are the only ones visible to the application at runtime. Geode searches the `CLASSPATH` after searching other locations, so the files cannot be available in the other search areas. -5. Start your application. The configuration file is loaded from the jar file. - -**Example of Deploying a Configuration JAR** - -The following example deploys the cache configuration file, `myCache.xml`, in `my.jar`. The following displays the contents of `my.jar`: - -``` pre -% jar -tf my.jar -META-INF -META-INF/MANIFEST.MF -myConfig/ -myConfig/myCache.xml -``` - -In this example, you would perform the following steps to deploy the configuration jar file: - -1. Set the system property, `gemfire.cache-xml-file`, to `myConfig/myCache.xml` -2. Set your `CLASSPATH` to include `my.jar`. -3. Verify there is no file named `myCache.xml` in `./myConfig/myCache.xml`, the current directory location of the file - -When you start your application, the configuration file is loaded from the jar file. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/ff80a931/geode-docs/configuring/running/firewall_ports_config.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/configuring/running/firewall_ports_config.html.md.erb b/geode-docs/configuring/running/firewall_ports_config.html.md.erb deleted file mode 100644 index 4f90602..0000000 --- a/geode-docs/configuring/running/firewall_ports_config.html.md.erb +++ /dev/null @@ -1,15 +0,0 @@ ---- -title: Firewall Considerations ---- - -You can configure and limit port usage for situations that involve firewalls, for example, between client-server or server-server connections. - -- **[Firewalls and Connections](../../configuring/running/firewalls_connections.html)** - - Be aware of possible connection problems that can result from running a firewall on your machine. - -- **[Firewalls and Ports](../../configuring/running/firewalls_ports.html)** - - Make sure your port settings are configured correctly for firewalls. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/ff80a931/geode-docs/configuring/running/firewalls_connections.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/configuring/running/firewalls_connections.html.md.erb b/geode-docs/configuring/running/firewalls_connections.html.md.erb deleted file mode 100644 index 3ae6bb1..0000000 --- a/geode-docs/configuring/running/firewalls_connections.html.md.erb +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: Firewalls and Connections ---- - -Be aware of possible connection problems that can result from running a firewall on your machine. - -Apache Geode is a network-centric distributed system, so if you have a firewall running on your machine it could cause connection problems. For example, your connections may fail if your firewall places restrictions on inbound or outbound permissions for Java-based sockets. You may need to modify your firewall configuration to permit traffic to Java applications running on your machine. The specific configuration depends on the firewall you are using. - -As one example, firewalls may close connections to Geode due to timeout settings. If a firewall senses no activity in a certain time period, it may close a connection and open a new connection when activity resumes, which can cause some confusion about which connections you have. - -For more information on how Geode client and servers connect, see the following topics: - -- [How Client/Server Connections Work](../../topologies_and_comm/topology_concepts/how_the_pool_manages_connections.html#how_the_pool_manages_connections) -- [Socket Communication](../../managing/monitor_tune/socket_communication.html) -- [Controlling Socket Use](../../managing/monitor_tune/performance_controls_controlling_socket_use.html#perf) -- [Setting Socket Buffer Sizes](../../managing/monitor_tune/socket_communication_setting_socket_buffer_sizes.html) - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/ff80a931/geode-docs/configuring/running/firewalls_multisite.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/configuring/running/firewalls_multisite.html.md.erb b/geode-docs/configuring/running/firewalls_multisite.html.md.erb deleted file mode 100644 index ace18d7..0000000 --- a/geode-docs/configuring/running/firewalls_multisite.html.md.erb +++ /dev/null @@ -1,70 +0,0 @@ ---- -title: Firewalls and Ports in Multi-Site (WAN) Configurations ---- - -Make sure your port settings are configured correctly for firewalls. - -<a id="concept_pfs_sf4_ft__section_alm_2g4_ft"></a> -Each gateway receiver uses a port to listen for incoming communication from one or more gateway senders communication between GemFire sites. The full range of port values for gateway receivers must be made accessible within the firewall from across the WAN. - -## **Properties for Firewall and Port Configuration in Multi-Site (WAN) Configurations** - -This table contains properties potentially involved in firewall behavior, with a brief description of each property. Click on a property name for a link to the [gemfire.properties and gfsecurity.properties (GemFire Properties)](../../reference/topics/gemfire_properties.html#gemfire_properties) reference topic. - -<table> -<colgroup> -<col width="33%" /> -<col width="33%" /> -<col width="33%" /> -</colgroup> -<thead> -<tr class="header"> -<th>Configuration Area</th> -<th><strong>Property or Setting</strong></th> -<th><strong>Definition</strong></th> -</tr> -</thead> -<tbody> -<tr class="odd"> -<td>multi-site (WAN) config</td> -<td><p>[hostname-for-senders](../../reference/topics/gfe_cache_xml.html#gateway-receiver)</p></td> -<td><p>Hostname or IP address of the gateway receiver used by gateway senders to connect.</p></td> -</tr> -<tr class="even"> -<td>multi-site (WAN) config</td> -<td>[remote-locators](../../reference/topics/gemfire_properties.html#gemfire_properties)</td> -<td><p>List of locators (and their ports) that are available on the remote WAN site.</p></td> -</tr> -<tr class="odd"> -<td>multi-site (WAN) config</td> -<td><p>[start-port](../../reference/topics/gfe_cache_xml.html#gateway-receiver) and [end-port](../../reference/topics/gfe_cache_xml.html#gateway-receiver) (cache.xml) or <code class="ph codeph">--start-port</code> and <code class="ph codeph">--end-port</code> parameters to the gfsh start gateway receiver command</p></td> -<td><p>Port range that the gateway receiver can use to listen for gateway sender communication.</p></td> -</tr> -</tbody> -</table> - -## Default Port Configuration - -<table> -<colgroup> -<col width="33%" /> -<col width="33%" /> -<col width="33%" /> -</colgroup> -<thead> -<tr class="header"> -<th><p><strong>Port Name</strong></p></th> -<th>Related Configuration Setting</th> -<th><p><strong>Default Port</strong></p></th> -</tr> -</thead> -<tbody> -<tr class="odd"> -<td><p>Gateway Receiver</p></td> -<td><p>[start-port](../../reference/topics/gfe_cache_xml.html#gateway-receiver) and [end-port](../../reference/topics/gfe_cache_xml.html#gateway-receiver) (cache.xml) or <code class="ph codeph">--start-port</code> and <code class="ph codeph">--end-port</code> parameters to the <code class="ph codeph">gfsh start gateway receiver</code> command</p></td> -<td><em>not set</em> Each gateway receiver uses a single port to accept connections from gateway senders in other systems. However, the configuration of a gateway receiver specifies a range of possible port values to use. GemFire selects an available port from the specified range when the gateway receiver starts. Configure your firewall so that the full range of possible port values is accessible by gateway senders from across the WAN.</td> -</tr> -</tbody> -</table> - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/ff80a931/geode-docs/configuring/running/firewalls_ports.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/configuring/running/firewalls_ports.html.md.erb b/geode-docs/configuring/running/firewalls_ports.html.md.erb deleted file mode 100644 index e278e5c..0000000 --- a/geode-docs/configuring/running/firewalls_ports.html.md.erb +++ /dev/null @@ -1,229 +0,0 @@ ---- -title: Firewalls and Ports ---- - -Make sure your port settings are configured correctly for firewalls. - -<a id="concept_5ED182BDBFFA4FAB89E3B81366EBC58E__section_F9C1D7419F954DC1A305C34714C8615C"></a> -There are several different port settings that need to be considered when using firewalls: - -- Port that the cache server listens on. This is configurable using the `cache-server` element in cache.xml, on the CacheServer class in Java APIs, and as a command line option to the `gfsh start server` command. - - By default, if not otherwise specified, Geode clients and servers discover each other on a pre-defined port (**40404**) on the localhost. - -- Locator port. Geode clients can use the locator to automatically discover cache servers. The locator port is configurable as a command-line option to the `gfsh start locator` command. Locators are used in the peer-to-peer cache deployments to discover other processes. They can be used by clients to locate servers as an alternative to configuring clients with a collection of server addresses and ports. - - By default, if not otherwise specified, Geode locators use the default multicast port **10334**. - -- Since locators start up the distributed system, locators must also have their ephemeral port range and TCP port accessible to other members through the firewall. -- For clients, you configure the client to connect to servers using the client's pool configuration. The client's pool configuration has two options: you can create a pool with either a list of server elements or a list of locator elements. For each element, you specify the host and port. The ports specified must be made accessible through your firewall. - -## **Limiting Ephemeral Ports for Peer-to-Peer Membership** - -By default, Geode assigns *ephemeral* ports, that is, temporary ports assigned from a designated range, which can encompass a large number of possible ports. When a firewall is present, the ephemeral port range usually must be limited to a much smaller number, for example six. If you are configuring P2P communications through a firewall, you must also set the TCP port for each process and ensure that UDP traffic is allowed through the firewall. - -## **Properties for Firewall and Port Configuration** - -This table contains properties potentially involved in firewall behavior, with a brief description of each property. Click on a property name for a link to the reference topic. - -<table> -<colgroup> -<col width="33%" /> -<col width="33%" /> -<col width="34%" /> -</colgroup> -<thead> -<tr class="header"> -<th><strong>Configuration area</strong></th> -<th><strong>Property or Setting</strong></th> -<th><strong>Definition</strong></th> -</tr> -</thead> -<tbody> -<tr class="odd"> -<td>peer-to-peer config</td> -<td><p><code class="ph codeph">conserve-sockets</code></p></td> -<td><p>Specifies whether sockets are shared by the system member's threads.</p></td> -</tr> -<tr class="even"> -<td>peer-to-peer config</td> -<td><p><code class="ph codeph">locators</code></p></td> -<td><p>The list of locators used by system members. The list must be configured consistently for every member of the distributed system.</p></td> -</tr> -<tr class="odd"> -<td>peer-to-peer config</td> -<td><p><code class="ph codeph">mcast-address</code></p></td> -<td><p>Address used to discover other members of the distributed system. Only used if mcast-port is non-zero. This attribute must be consistent across the distributed system.</p></td> -</tr> -<tr class="even"> -<td>peer-to-peer config</td> -<td><p><code class="ph codeph">mcast-port</code></p></td> -<td><p>Port used, along with the mcast-address, for multicast communication with other members of the distributed system. If zero, multicast is disabled for data distribution.</p></td> -</tr> -<tr class="odd"> -<td>peer-to-peer config</td> -<td><p><code class="ph codeph">membership-port-range</code></p></td> -<td><p>The range of ephemeral ports available for unicast UDP messaging and for TCP failure detection in the peer-to-peer distributed system.</p></td> -</tr> -<tr class="even"> -<td>peer-to-peer config</td> -<td><p><code class="ph codeph">tcp-port</code></p></td> -<td><p>The TCP port to listen on for cache communications.</p></td> -</tr> -</tbody> -</table> - -<table> -<colgroup> -<col width="33%" /> -<col width="33%" /> -<col width="33%" /> -</colgroup> -<thead> -<tr class="header"> -<th>Configuration Area</th> -<th><strong>Property or Setting</strong></th> -<th><strong>Definition</strong></th> -</tr> -</thead> -<tbody> -<tr class="odd"> -<td>cache server config</td> -<td><p><code class="ph codeph">hostname-for-clients</code></p></td> -<td><p>Hostname or IP address to pass to the client as the location where the server is listening.</p></td> -</tr> -<tr class="even"> -<td>cache server config</td> -<td><p><code class="ph codeph">max-connections</code></p></td> -<td><p>Maximum number of client connections for the server. When the maximum is reached, the server refuses additional client connections.</p></td> -</tr> -<tr class="odd"> -<td>cache server config</td> -<td><p><code class="ph codeph">port</code> (cache.xml) or <code class="ph codeph">--port</code> parameter to the <code class="ph codeph">gfsh start server</code> command</p></td> -<td><p>Port that the server listens on for client communication.</p></td> -</tr> -</tbody> -</table> - -## Default Port Configurations - -<table> -<colgroup> -<col width="33%" /> -<col width="33%" /> -<col width="33%" /> -</colgroup> -<thead> -<tr class="header"> -<th><p><strong>Port Name</strong></p></th> -<th>Related Configuration Setting</th> -<th><p><strong>Default Port</strong></p></th> -</tr> -</thead> -<tbody> -<tr class="odd"> -<td><p>Cache Server</p></td> -<td><p><code class="ph codeph">port</code> (cache.xml)</p></td> -<td>40404</td> -</tr> -<tr class="even"> -<td><p>HTTP</p></td> -<td><code class="ph codeph">http-service-port</code></td> -<td>7070</td> -</tr> -<tr class="odd"> -<td><p>Locator</p></td> -<td><code class="ph codeph">start-locator</code> (for embedded locators) or <code class="ph codeph">--port</code> parameter to the <code class="ph codeph">gfsh start locator</code> command.</td> -<td><em>if not specified upon startup or in the start-locator property, uses default multicast port 10334</em></td> -</tr> -<tr class="even"> -<td><p>Membership Port Range</p></td> -<td><code class="ph codeph">membership-port-range</code></td> -<td>1024 to 65535</td> -</tr> -<tr class="odd"> -<td><p>Memcached Port</p></td> -<td><code class="ph codeph">memcached-port</code></td> -<td><em>not set</em></td> -</tr> -<tr class="even"> -<td><p>Multicast</p></td> -<td><code class="ph codeph">mcast-port</code></td> -<td>10334</td> -</tr> -<tr class="odd"> -<td><p>RMI</p></td> -<td><code class="ph codeph">jmx-manager-port</code></td> -<td>1099</td> -</tr> -<tr class="even"> -<td><p>TCP</p></td> -<td><code class="ph codeph">tcp-port</code></td> -<td>ephemeral port</td> -</tr> -</tbody> -</table> - -## **Properties for Firewall and Port Configuration in Multi-Site (WAN) Configurations** - -Each gateway receiver uses a port to listen for incoming communication from one or more gateway senders communication between Geode sites. The full range of port values for gateway receivers must be made accessible within the firewall from across the WAN. - -This table contains properties potentially involved in firewall behavior, with a brief description of each property. Click on a property name for a link to the [gemfire.properties and gfsecurity.properties (Geode Properties)](../../reference/topics/gemfire_properties.html#gemfire_properties) reference topic. - -<table> -<colgroup> -<col width="33%" /> -<col width="33%" /> -<col width="33%" /> -</colgroup> -<thead> -<tr class="header"> -<th>Configuration Area</th> -<th><strong>Property or Setting</strong></th> -<th><strong>Definition</strong></th> -</tr> -</thead> -<tbody> -<tr class="odd"> -<td>multi-site (WAN) config</td> -<td><p>[hostname-for-senders](../../reference/topics/gfe_cache_xml.html#gateway-receiver)</p></td> -<td><p>Hostname or IP address of the gateway receiver used by gateway senders to connect.</p></td> -</tr> -<tr class="even"> -<td>multi-site (WAN) config</td> -<td>[remote-locators](../../reference/topics/gemfire_properties.html#gemfire_properties)</td> -<td><p>List of locators (and their ports) that are available on the remote WAN site.</p></td> -</tr> -<tr class="odd"> -<td>multi-site (WAN) config</td> -<td><p>[start-port](../../reference/topics/gfe_cache_xml.html#gateway-receiver) and [end-port](../../reference/topics/gfe_cache_xml.html#gateway-receiver) (cache.xml) or <code class="ph codeph">--start-port</code> and <code class="ph codeph">--end-port</code> parameters to the <code class=" ph codeph">gfsh start gateway receiver</code> command</p></td> -<td><p>Port range that the gateway receiver can use to listen for gateway sender communication.</p></td> -</tr> -</tbody> -</table> - -## Default Port Configuration - -<table> -<colgroup> -<col width="33%" /> -<col width="33%" /> -<col width="33%" /> -</colgroup> -<thead> -<tr class="header"> -<th><p><strong>Port Name</strong></p></th> -<th>Related Configuration Setting</th> -<th><p><strong>Default Port</strong></p></th> -</tr> -</thead> -<tbody> -<tr class="odd"> -<td><p>Gateway Receiver</p></td> -<td><p>[start-port](../../reference/topics/gfe_cache_xml.html#gateway-receiver) and [end-port](../../reference/topics/gfe_cache_xml.html#gateway-receiver) (cache.xml) or <code class="ph codeph">--start-port</code> and <code class="ph codeph">--end-port</code> parameters to the <code class="ph codeph">gfsh start gateway receiver</code> command</p></td> -<td><em>not set</em> Each gateway receiver uses a single port to accept connections from gateway senders in other systems. However, the configuration of a gateway receiver specifies a range of possible port values to use. Geode selects an available port from the specified range when the gateway receiver starts. Configure your firewall so that the full range of possible port values is accessible by gateway senders from across the WAN.</td> -</tr> -</tbody> -</table> - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/ff80a931/geode-docs/configuring/running/managing_output_files.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/configuring/running/managing_output_files.html.md.erb b/geode-docs/configuring/running/managing_output_files.html.md.erb deleted file mode 100644 index 59f48aa..0000000 --- a/geode-docs/configuring/running/managing_output_files.html.md.erb +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: Managing System Output Files ---- - -Geode output files are optional and can become quite large. Work with your system administrator to determine where to place them to avoid interfering with other system activities. - -<a id="managing_output_files__section_F0CEA4299D274801B9AB700C074F178F"></a> -Geode includes several types of optional output files as described below. - -- **Log Files**. Comprehensive logging messages to help you confirm system configuration and to debug problems in configuration and code. Configure log file behavior in the `gemfire.properties` file. See [Logging](../../managing/logging/logging.html#concept_30DB86B12B454E168B80BB5A71268865). - -- **Statistics Archive Files**. Standard statistics for caching and distribution activities, which you can archive on disk. Configure statistics collection and archival in the `gemfire.properties`, `archive-disk-space-limit` and `archive-file-size-limit`. See the [Reference](../../reference/book_intro.html#reference). - -- **Disk Store Files**. Hold persistent and overflow data from the cache. You can configure regions to persist data to disk for backup purposes or overflow to disk to control memory use. The subscription queues that servers use to send events to clients can be overflowed to disk. Gateway sender queues overflow to disk automatically and can be persisted for high availability. Configure these through the `cache.xml`. See [Disk Storage](../../managing/disk_storage/chapter_overview.html). - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/ff80a931/geode-docs/configuring/running/running_the_cacheserver.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/configuring/running/running_the_cacheserver.html.md.erb b/geode-docs/configuring/running/running_the_cacheserver.html.md.erb deleted file mode 100644 index 9de1189..0000000 --- a/geode-docs/configuring/running/running_the_cacheserver.html.md.erb +++ /dev/null @@ -1,182 +0,0 @@ ---- -title: Running Geode Server Processes ---- - -A Geode server is a process that runs as a long-lived, configurable member of a client/server system. - -<a id="running_the_cacheserver__section_6C2B495518C04064A181E7917CA81FC1"></a> -The Geode server is used primarily for hosting long-lived data regions and for running standard Geode processes such as the server in a client/server configuration. You can start and stop servers using the following methods: - -- The `gfsh` tool allows you to manage Geode server processes from the command line. -- You can also start, stop and manage the Geode servers through the `org.apache.geode.distributed.ServerLauncher` API. The `ServerLauncher` API can only be used for Geode Servers that were started with `gfsh` or with the `ServerLauncher` class itself. See the JavaDocs for additional specifics on using the `ServerLauncher` API. - -## <a id="running_the_cacheserver__section_E15FB1B039CE4F6CB2E4B5618D7ECAA1" class="no-quick-link"></a>Default Server Configuration and Log Files - -The `gfsh` utility uses a working directory for its configuration files and log files. These are the defaults and configuration options: - -- When you start a standalone server using `gfsh`, `gfsh` will automatically load the required JAR files `$GEMFIRE/lib/server-dependencies.jar` and `$JAVA_HOME/lib/tools.jar` into the CLASSPATH of the JVM process. If you start a standalone server using the ServerLauncher API, you must specify `$GEMFIRE/lib/server-dependencies.jar` inside your command to launch the process. For more information on CLASSPATH settings in Geode, see [Setting Up the CLASSPATH](../../getting_started/setup_classpath.html). -- Servers are configured like any other Geode process, with `gemfire.properties` and shared cluster configuration files. It is not programmable except through application plug-ins. Typically, you provide the `gemfire.properties` file and the `gfsecurity.properties` file (if you are using a separate, restricted access security settings file). You can also specify a `cache.xml` file in the cache serverâs working directory. -- By default, a new server started with `gfsh` receives its initial cache configuration from the cluster configuration service, assuming the locator is running the cluster configuration service. If you specify a group when starting the server, the server also receives configurations that apply to a group. The shared configuration consists of `cache.xml` files, `gemfire.properties` files, and deployed jar files. You can disable use of the cluster configuration service by specifying `--use-cluster-configuration=false` when starting the server using `gfsh`. - - See [Overview of the Cluster Configuration Service](../cluster_config/gfsh_persist.html#concept_r22_hyw_bl). - -- If you are using the Spring Framework, you can specify a Spring ApplicationContext XML file when starting up your server in `gfsh` by using the `--spring-xml-location` command-line option. This option allows you to bootstrap your Geode server process with your Spring application's configuration. See [Spring documentation](http://docs.spring.io/spring/docs/3.2.x/spring-framework-reference/html/resources.html#resources-app-ctx) for more information on this file. -- For logging output, log file output defaults to `server_name.log` in the cache server's working directory. If you restart a server with the same server name, the existing *server\_name*.log file is automatically renamed for you (for example, `server1-01-01.log` or `server1-02-01.log`). You can modify the level of logging details in this file by specifying a level in the `--log-level` argument when starting up the server. -- By default, the server will start in a subdirectory (named after the server's specified `--name`) under the directory where `gfsh` is executed. This subdirectory is considered the current working directory. You can also specify a different working directory when starting the cache server in `gfsh`. -- By default, a server process that has been shutdown and disconnected due to a network partition event or member unresponsiveness will restart itself and automatically try to reconnect to the existing distributed system. See [Handling Forced Cache Disconnection Using Autoreconnect](../../managing/autoreconnect/member-reconnect.html#concept_22EE6DDE677F4E8CAF5786E17B4183A9) for more details. -- You can pass JVM parameters to the server's JVM by using the `--J=-Dproperty.name=value` upon server startup. These parameters can be Java properties or Geode configuration properties such as `gemfire.jmx-manager`. For example: - - ``` pre - gfsh>start server --name=server1 --J=-Dgemfire.jmx-manager=true \ - --J=-Dgemfire.jmx-manager-start=true --J=-Dgemfire.http-port=8080 - ``` - -- We recommend that you do not use the `-XX:+UseCompressedStrings` and `-XX:+UseStringCache` JVM configuration properties when starting up servers. These JVM options can cause issues with data corruption and compatibility. - -## <a id="running_the_cacheserver__section_07001480D33745139C3707EDF8166D86" class="no-quick-link"></a>Start the Server - -The startup syntax for Geode servers in `gfsh` is: - -``` pre -start server --name=value [--assign-buckets(=value)] [--bind-address=value] - [--cache-xml-file=value] [--classpath=value] [--disable-default-server(=value)] - [--disable-exit-when-out-of-memory(=value)] [--enable-time-statistics(=value)] - [--force(=value)] [--include-system-classpath(=value)] [--properties-file=value] - [--security-properties-file=value] - [--group=value] [--locators=value] [--locator-wait-time=value] [--log-level=value] - [--mcast-address=value] [--mcast-port=value] [--memcached-port=value] - [--memcached-protocol=value] [--rebalance(=value)] [--server-bind-address=value] - [--server-port=value] [--spring-xml-location=value] - [--statistic-archive-file=value] [--dir=value] [--initial-heap=value] - [--max-heap=value] [--use-cluster-configuration(=value)] [--J=value(,value)*] - [--critical-heap-percentage=value] [--critical-off-heap-percentage=value] - [--eviction-heap-percentage=value] [--eviction-off-heap-percentage=value] - [--hostname-for-clients=value] [--max-connections=value] - [--message-time-to-live=value] [--max-message-count=value] [--max-threads=value] - [--socket-buffer-size=value] [--lock-memory=value] [--off-heap-memory-size=value] -``` - -**Note:** -When both `--max-heap` and `--initial-heap` are specified during server startup, additional GC parameters are specified internally by Geode's Resource Manager. If you do not want the additional default GC properties set by the Resource Manager, then use the `-Xms` & `-Xmx` JVM options. See [Controlling Heap Use with the Resource Manager](../../managing/heap_use/heap_management.html#configuring_resource_manager) for more information. - -The following `gfsh start server` start sequences specify a `cache.xml` file for cache configuration, and use different incoming client connection ports: - -``` pre -gfsh>start server --name=server1 --mcast-port=10338 \ ---cache-xml-file=../ServerConfigs/cache.xml --server-port=40404 - -gfsh>start server --name=server2 --mcast-port=10338 \ ---cache-xml-file=../ServerConfigs/cache.xml --server-port=40405 -``` - -Here is a portion of a `gemfire.properties` file that sets the location of a`cache.xml` file for the server and sets the mcast-port: - -``` pre -mcast-port=10338 -cache-xml-file=D:\gfeserver\cacheCS.xml -``` - -To start the server using this `gemfire.properties` file, enter: - -``` pre -gfsh>start server --name=server1 \ ---properties-file=D:\gfeserver\gemfire.properties -``` - -To start a server with an embedded JMX Manager, you can enter the following command: - -``` pre -gfsh>start server --name=server2 \ ---J=-Dgemfire.jmx-manager=true --J=-Dgemfire.jmx-manager-start=true -``` - -To start a server and provide JVM configuration settings, you can issue a command like the following: - -``` pre -gfsh>start server --name=server3 \ ---J=-Xms80m,-Xmx80m --J=-XX:+UseConcMarkSweepGC,-XX:CMSInitiatingOccupancyFraction=65 -``` - -## Start the Server Programmatically - -Use `org.apache.geode.distributed.ServerLauncher` API to start the cache server process inside your code. Use the `ServerLauncher.Builder` class to construct an instance of the `ServerLauncher`, and then use the `start()` method to start the server service. The other methods in the `ServerLauncher` class provide status information about the server and allow you to stop the server. - -``` pre -import org.apache.geode.distributed.ServerLauncher; - - public class MyEmbeddedServer { - - public static void main(String[] args){ - ServerLauncher serverLauncher = new ServerLauncher.Builder() - .setMemberName("server1") - .setServerPort(40405) - .set("jmx-manager", "true") - .set("jmx-manager-start", "true") - .build(); - - serverLauncher.start(); - - System.out.println("Cache server successfully started"); - } - } -``` - -## <a id="running_the_cacheserver__section_F58F229D5C7048E9915E0EC470F9A923" class="no-quick-link"></a>Check Server Status - -If you are connected to the distributed system in `gfsh`, you can check the status of a running cache server by providing the server name. For example: - -``` pre -gfsh>status server --name=server1 -``` - -If you are not connected to a distributed system, you can check the status of a local cache server by providing the process ID or the server's current working directory. For example: - -``` pre -gfsh>status server --pid=2484 -``` - -or - -``` pre -% gfsh status server --dir=<server_working_directory> -``` - -where <*server\_working\_directory*> corresponds to the local working directory where the cache server is running. - -If successful, the command returns the following information (with the JVM arguments that were provided at startup): - -``` pre -% gfsh status server --dir=server4 -Server in /home/user/server4 on ubuntu.local[40404] as server4 is currently online. -Process ID: 3324 -Uptime: 1 minute 5 seconds -GemFire Version: 8.0.0 -Java Version: 1.7.0_65 -Log File: /home/user/server4/server4.log -JVM Arguments: -... -``` - -## <a id="running_the_cacheserver__section_0E4DDED6AB784B0CAFBAD538B227F487" class="no-quick-link"></a>Stop Server - -If you are connected to the distributed system in `gfsh`, you can stop a running cache server by providing the server name. For example: - -``` pre -gfsh>stop server --name=server1 -``` - -If you are not connected to a distributed system, you can stop a local cache server by specify the server's current working directory or the process ID. For example: - -``` pre -gfsh>stop server --pid=2484 -``` - -or - -``` pre -gfsh>stop server --dir=<server_working_directory> -``` - -where <*server\_working\_directory*> corresponds to the local working directory where the cache server is running. - -You can also use the `gfsh` `shutdown` command to shut down all cache servers in an orderly fashion. This is useful if you are using persistent regions. See [Starting Up and Shutting Down Your System](starting_up_shutting_down.html) for more details.
