LATEST VERSION: 8.2.5 - CHANGELOG
Pivotal GemFire® v8.2

Running GemFire Server Processes

Running GemFire Server Processes

A Pivotal GemFire server is a process that runs as a long-lived, configurable member of a distributed system.

The GemFire server is used primarily for hosting long-lived data regions and for running standard GemFire 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 GemFire server processes from the command line.
  • You can also start, stop and manage the GemFire servers through the com.gemstone.gemfire.distributed.ServerLauncher API. The ServerLauncher API can only be used for GemFire Servers that were started with gfsh or with the ServerLauncher class itself. See the JavaDocs for additional specifics on using the ServerLauncher API.

Default Server Configuration and Log Files

The gfsh server commands use 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-- assuming JAVA_HOME points to an installed JDK) into the CLASSPATH of the JVM process. If you start a standalone server using the ServerLauncher API, you must $GEMFIRE/lib/server-dependencies.jar inside your command to launch the process. For more information on CLASSPATH settings in GemFire, see CLASSPATH Settings for GemFire Processes.
  • Servers are configured like any other GemFire 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 server has been started in a distributed system that contains a locator 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.

    SeeOverview of the Cluster Configuration Service.

  • 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 GemFire server process with your Spring application's configuration. See Spring documentation 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 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 GemFire configuration properties such as gemfire.jmx-manager. For example:
    gfsh>start server --name=server1 --J=-Dgemfire.jmx-manager=true \
    --J=-Dgemfire.jmx-manager-start=true --J=-Dgemfire.http-port=8080
  • Pivotal recommends 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.

Start the Server

The startup syntax for GemFire servers in gfsh is:
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)?] [--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] [--eviction-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]
See start server for a detailed reference on all the parameters of the command.
Note: When both --max-heap and --initial-heap are specified during Server startup, additional GC parameters are specified internally by GemFire'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 Control Heap Use with the Resource Manager for more information.
These following gfsh start server start sequences specify a cache.xml file for cache configuration, different incoming client connection ports, and use a multicast port for peer discovery:
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
Note that since the servers are using multicast, the servers do not use the cluster configuration service for initial cache configuration. To use the cluster configuration service, you must first start a locator running the cluster configuration service first.
Here, the multicast port and cache.xml file specifications are in a gemfire.properties file:
#contents of D:\gfeserver\gemfire.properties 
#Tue May 09 17:53:54 PDT 2006 
mcast-port=10338 
cache-xml-file=D:\gfeserver\cacheCS.xml
To start the server using this gemfire.properties file, you can enter the following command:
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:
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:
gfsh>start server --name=server3 \
--J=-Xms80m,-Xmx80m --J=-XX:+UseConcMarkSweepGC,-XX:CMSInitiatingOccupancyFraction=65
Note:

Start the Server Programmatically

Use com.gemstone.gemfire.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 a server service embedded in your Java application process. The other methods in the ServerLauncher class provide status information about the server and allow you to stop the server.
import com.gemstone.gemfire.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");
        }
    }

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:
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:
gfsh>status server --pid=2484
or
$ 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):
stymon@ubuntu:~$ gfsh status server --dir=server4
Server in /home/stymon/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/stymon/server4/server4.log
JVM Arguments: 
...

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:
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:
gfsh>stop server --pid=2484
or
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 Shutting Down the System for more details.