This topic explains how to run VMware Tanzu GemFire server processes.

A Tanzu GemFire server is a process that runs as a long-lived, configurable member of a client/server 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 gfsh command-line tool.

Start a Server with gfsh

Assuming that you have already used gfsh to start a locator, this example uses the gfsh start server command to start a default server named “server1”:

gfsh>start server --name=server1

See the gfsh start server reference page for command syntax.

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:

  • A server is 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. You can also specify a cache.xml file in the cache server’s working directory.

  • A new server receives its initial cache configuration from the cluster configuration service, assuming the locator is running the cluster configuration service (the default). The shared configuration consists of cache.xml files, gemfire.properties files, and deployed jar files. You can deactivate use of the cluster configuration service by specifying the --use-cluster-configuration=false parameter. See Overview 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 by using the --spring-xml-location parameter. This parameter allows you to bootstrap your server process with your Spring application’s configuration. See Spring documentation for more information about this file.

  • Log file output defaults to server-name.log in the cache server’s working directory. If you restart a server with a previously used server name, the existing log file is automatically renamed, for example, server1-01-01.log becomes server1-02-01.log. You can modify the level of logging details in this file by specifying the desired level with the --log-level parameter.

  • By default, the server starts in a subdirectory, named after the server, under the current working directory of the gfsh process. This subdirectory is considered the server’s current working directory. You can also specify a different working directory with the --dir parameter.

  • By default, a server process that has been shut down and disconnected due to a network partition event or member unresponsiveness restarts and tries to reconnect to the existing cluster. See Handling Forced Cache Disconnection Using Auto-reconnect for more details.

  • You can pass JVM parameters to the server’s JVM with the --J parameter. The JVM parameters you specify can be any Java command-line argument including, but not limited to, system 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

  • When both --max-heap and --initial-heap are specified during server startup, additional GC parameters are specified on your behalf. If you do not want additional default GC properties set, then use the -Xms and -Xmx JVM options to set only these parameters. For more information, see Controlling Heap Use with the Resource Manager in Managing Heap Memory.

    To start a server providing GC configuration settings:

    gfsh>start server --name=server3 \
--J=-Xms80m,-Xmx80m,-XX:+UseConcMarkSweepGC,-XX:CMSInitiatingOccupancyFraction=65

  • 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.

Check Server Status

Once connected to the cluster in gfsh, check the status of a running cache server by providing the server name:

gfsh>status server --name=server1

If you are not connected to a cluster, 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=server1

If successful, the output provides information as in this sample:

% gfsh status server --dir=server4
Server in /home/username/server4 on 192.0.2.0[40404] as server4 is currently online.
Process ID: 49008
Uptime: 2 minutes 4 seconds
Tanzu GemFire Version: 10.0
Java Version: 1..0_361
Log File: /home/username/server4/server4.log
JVM Arguments: 
...

Stop a Server

When connected to the cluster in gfsh, stop a running cache server by providing the server name:

gfsh>stop server --name=server1

If not connected, 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=server1

You can also use the gfsh shutdown command to shut down all cache servers in an orderly fashion. Doing a shutdown is the correct approach for systems with persistent regions. See Starting Up and Shutting Down Your System for more details.

Start a Server Programmatically

Running your servers standalone, as described above, provides the highest reliability and availability. But in some situations, you may choose to run an embedded server.

To start the server programmatically use the 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.

import org.apache.geode.distributed.ServerLauncher;

public class ExampleServerApplication {
  public static void main(final String[] args) {
    final ServerLauncher serverLauncher = new ServerLauncher.Builder()
      .setMemberName("server1")
      .setServerPort(40405).set("jmx-manager", "true")
      .set("jmx-manager-start", "true")
      .set("log-file", "").build();

    serverLauncher.start();

    System.out.println("Cache server successfully started");
    System.out.println(args[0]);
  }
}

This example demonstrates how to start a GemFire server embedded in your own Java application via the ServerLauncher utilizing the GemFire Bootstrap. Using the GemFire Bootstrap is necessary to load GemFire Extensions, like GemFire Search, and isolate GemFire from other loaded application classes. When using the GemFire Bootstrap, you must be sure to define a GEMFIRE_HOME environment variable or a gemfire.home system property that points to the VMware GemFire top-level installation directory.

The class com.examples.ExampleServerApplication has a static void main(String[]) method, like any other Java application. It uses the org.apache.geode.distributed.ServerLauncher to embed a GemFire server in the Java application.

The Java application is executed through GemFire Bootstrap’s com.vmware.gemfire.bootstrap.Main Java application class. The command includes only the GemFire Bootstrap jar in the Java classpath. Your application classes and jars can be added via the --automatic-module-classpath argument. You should not include any other jars in the Java classpath directly.

$ java -classpath gemfire-bootstrap.jar com.vmware.gemfire.bootstrap.Main \
    com.examples.ExampleServerApplication \
    --automatic-module-classpath <classes:jar:...> \
    [application arguments ...]
check-circle-line exclamation-circle-line close-line
Scroll to top icon