Announcement Announcement Module
No announcement yet.
Stopping Gemfire cache server configured through spring Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Stopping Gemfire cache server configured through spring


    We are using spring configuration to start data in gemfire cache.
    <gfe:cache cache-xml-location="classpath:gemfire-server.xml" id="gemfire-cache"/>

    Thus the cache server is started when the spring configuration is loaded. Currently we stop the cache process by using the kill commad on linux server after we grep for the server process id.

    Could you please let me know what would be the best way to gracefully shutdown the gemfire server? Like, can I get an instance of the Gemfire server and call something like shutdown or destroy method?


  • #2
    Hi Sam,

    Ideally, if you are using GemFire 7.x or above, you would be able to control the Spring-initiated GemFire peer member (Cache) in the cluster using Gfsh. However, both the LocatorLauncher and the ServerLauncher public API classes in the com.gemstone.gemfire.distributed package of the GemFire distro (which are technically used by Gfsh to start Locators and Servers, respectively) do a little bit extra work to make the Locator/Server accessible to lifecycle commands in Gfsh, such as 'start/status/stop locator/server'.

    However, this is not to say a Spring-configured GemFire member is not visible to the cluster using Gfsh, as I am sure you are quite aware. In fact, with the Spring GemFire peer member properly configured, you can issue most commands in Gfsh on that member (that are not no lifecycle related, like 'describe member', 'create region', 'create index', 'execute function', and so on).

    For the GemFire 7.5 release, we are planning on adding better support and integration for starting Servers in Gfsh using Spring XML configuration files, not just GemFire's native cache.xml configuration file.

    In addition, when Spring Data GemFire 1.3.4 is released, there will be support to bootstrap a Spring ApplicationContext from within a GemFire Server using a small snippet of cache.xml containing an Declarable (SpringContextBootstrappingInitializer) declared in an <initializer> block, like so...

    <?xml version="1.0"?>
    <!DOCTYPE cache PUBLIC "-//GemStone Systems, Inc.//GemFire Declarative Caching 7.0//EN"
        <parameter name="contextConfigLocations">
    See the PR #49 ( for more details.

    The later approach is the exact opposite of using Gfsh to start a GemFire Server with Spring XML config meta-data instead of cache.xml, and the later approach does have limitations (such as the ability to configure the GemFire Cache using the SDG XML namespace). However, it does enable the Spring GemFire peer member to be controlled using Gfsh lifecycle commands: 'start/status/stop server'.

    However, for the time being, you can do the following...

    Assume you started a Locator in Gfsh like so...

    [gfsh>start locator --name=locatorX --port=11235 --log-level=config
    Starting a GemFire Locator in /Users/jblum/vmdev/tmp/locatorX...
    Locator in /Users/jblum/vmdev/tmp/locatorX on[11235] as locatorX is currently online.
    Process ID: 68972
    Uptime: 10 seconds
    GemFire Version:
    Java Version: 1.6.0_65
    Log File: /Users/jblum/vmdev/tmp/locatorX/locatorX.log
    Successfully connected to: [host=, port=1099]
    gfsh>list members
    Name | Id
    -------- | -----------------------------------------
    locatorX | jblum-mbpro(locatorX:68972:locator):38141
    Then, assume you have a SDG XML config similar to the following...

    <?xml version="1.0" encoding="UTF-8"?>
    <beans xmlns=""
      <util:properties id="peerCacheConfigurationSettings">
        <prop key="name">springGemFirePeerCache</prop>
        <prop key="locators">localhost[11235]</prop>
        <prop key="log-level">config</prop>
        <prop key="mcast-port">0</prop>
      <gfe:cache properties-ref="peerCacheConfigurationSettings" lazy-init="false"/>
    Note, "naming" the Spring GemFire peer member is important for Gfsh and the new JMX Management functionality in GemFire 7.x+, so be sure to "name" the peer member.

    And, suppose you have an a small Java class that bootstraps the Spring ApplicationContext, GemFire Server peer member in the cluster like this...

    public class PeerCacheApp {
    public static final String DEFAULT_SERVER_CONFIGURATION_FILE = "peercache.xml";
    private static String getConfigurationFile(final String... args) {
      return (args != null && args.length > 0 ? args[0] : DEFAULT_SERVER_CONFIGURATION_FILE);
    public static void main(final String... args) {
      final ConfigurableApplicationContext applicationContext = new ClassPathXmlApplicationContext(
      System.out.printf("Press enter to continue...%n");
      Scanner in = new Scanner(;
    Note, you can block however you need to. I chose to wait for user input for my testing purposes. Clearly, this is not advisable in production environments. In addition, if you started an actual "Cache Server" (ServerSocket) for clients to connect to the GemFire Server, then you do not necessarily need to block since the ServerSocket is listening on a non-daemon Thread and will block waiting for clients to connect (although, if the ServerSocket errors out or gets closed, then the Server will exit). Otherwise, there is nothing in GemFire preventing it from falling straight through on startup.

    Once, you have started the small application, you can see the member in Gfsh...

    gfsh>list members
    Name | Id
    ---------------------- | ---------------------------------------------------
    springGemFirePeerCache | jblum-mbpro(springGemFirePeerCache:70852)<v1>:29413
    locatorX | jblum-mbpro(locatorX:68972:locator):38141
    gfsh>describe member --name=springGemFirePeerCache
    Name : springGemFirePeerCache
    Id : jblum-mbpro(springGemFirePeerCache:70852)<v1>:29413
    Host :
    Regions : 
    PID : 70852
    Groups : 
    Used Heap : 10M
    Max Heap : 123M
    Working Dir : /Users/jblum/vmdev/spring-data-gemfire-tests-workspace/spring-data-gemfire-tests/target
    Log file : /Users/jblum/vmdev/spring-data-gemfire-tests-workspace/spring-data-gemfire-tests/target
    Locators : localhost[11235]
    Now, just start jconsole. jconsole will automagically connect to the cluster to which Gfsh is connected.

    gfsh>start jconsole
    Running JDK JConsole
    Once in jsconsole, navigate to the MBeans tab, then GemFire -> Member -> springGemFirePeerCache -> Operations -> shutdownMember. Presto.

    Invoking the "shutDownMember" operation will successfully stop this Spring-initiated peer member as it appropriately calls the correct shutdown procedure defined in GemFire for a peer member, stopping distribution, JGroups and all other services.

    <<see screenshot>>

    Then, back in Gfsh...

    gfsh>list members
      Name   | Id
    -------- | -----------------------------------------
    locatorX | jblum-mbpro(locatorX:68972:locator):38141
    Last edited by John Blum; Feb 25th, 2014, 01:06 PM.