LATEST VERSION: 8.1.0 - CHANGELOG
Pivotal GemFire® v8.1

Common GemFire Configuration Changes for AppServers

Common GemFire Configuration Changes for AppServers

Using a Different Multicast Port

For a GemFire peer-to-peer member to communicate on a different multicast port than the default (10334), use the mcast-port property in the web.xml file either by manual configuration or by using -p gemfire.property.mcast-port=10445 option to the modify_war script.

<filter>
    <filter-name>gemfire-session-filter</filter-name>
    <filter-class>
      com.gemstone.gemfire.modules.session.filter.SessionCachingFilter
    </filter-class>
    <init-param>
        <param-name>cache-type</param-name>
        <param-value>peer-to-peer</param-value>
    </init-param>
    <init-param>
        <param-name>gemfire.property.mcast-port</param-name>
        <param-value>10445</param-value>
    </init-param>
</filter>

This example uses port 10445 as the multicast port.

Overriding Region Attributes

When using the HTTP Session Management Module, you cannot override region attributes directly on the cache server. You must place all region attribute definitions in the region attributes template that you customize within the application server. For example, to specify a different name for the region's disk store, you could add the new disk-store-name specification to the region attributes template and then reference the template on the cache server.
<region-attributes id="MY_SESSIONS" refid="PARTITION_REDUNDANT_PERSISTENT_OVERFLOW" 
disk-store-name="mystore">
  ...
</region-attributes>
Then on the cache server side, reference the modified region attributes template to allow the region to use the disk-store-name attribute:
<region name="gemfire_modules_sessions" refid="MY_SESSIONS"/>
Next, you must specify the region attributes ID as a value for the region_attributes_id parameter in web.xml. For example, if you want to enable the region-attributes in the above example for a specific Web application, you would configure the Web application's web.xml in the following manner:
<filter>
  ...
    <init-param>
        <param-name>gemfire.cache.region_attributes_id</param-name>
        <param-value>MY_SESSIONS</param-value>
    </init-param>
  ...
</filter>

Peer-to-Peer Configuration Using Locators

By default, GemFire peers discover each other using multicast communication on a known port (as specified by the mcast-port system parameter). Alternatively, you can configure member discovery using one or more dedicated locators. A locator provides both discovery and load balancing services.



To run GemFire with one or more locators instead of a multicast port, use the locators property in the web.xml file or the -p gemfire.property.locators=hostname[10334] option to the modify_war script:
<filter>
    <filter-name>gemfire-session-filter</filter-name>
    <filter-class>
      com.gemstone.gemfire.modules.session.filter.SessionCachingFilter
    </filter-class>
    <init-param>
        <param-name>cache-type</param-name>
        <param-value>peer-to-peer</param-value>
    </init-param>
    <init-param>
        <param-name>gemfire.property.locators</param-name>
        <param-value>hostname[10334]</param-value>
    </init-param>
</filter> 

This example uses a locator at hostname on port 10334.

You must be sure when you specify a locator that you specifically launch a locator correctly at this location. You can do this using the gemfire command-line tool found in the bin subdirectory of the HTTP module distribution.

In Unix:
  ./gemfire.sh start-locator -port=10334
  
In Windows:
  gemfire.bat start-locator -port=10334

This example starts a locator that listens on port 10334.

Client/Server Configuration Using Locators

By default, GemFire clients and servers discover each other on a pre-defined port on the localhost. This is not typically the way you would deploy a client/server configuration. A preferred solution is to use one or more dedicated locators. A locator provides both discovery and load balancing services.



To run GemFire with one or more locators instead of a multicast port, add locator information to the cache-client.xml file in the AppServer module instance's conf subdirectory:

  <pool name="sessions">
    <locator host="hostname" port="10334"/>
  </pool>

This example tells the GemFire client (which is the process running the application server) to use a locator at hostname on port 10334.

You must now launch a locator correctly at this location. You can do this using the gemfire command-line tool found in the bin subdirectory of the HTTP module distribution.

./gemfire start-locator -port=10334

This example starts a locator that listens on port 10334.

You also need to tell the GemFire server to use a locator when you launch the server. You can do this through a command-line argument when you start up the server with the script provided in the bin subdirectory wherever you installed the GemFire HTTP module:

In Unix: 
  prompt$ ./cacheserver.sh start locators=hostname[port]
  
In Windows:
  prompt> cacheserver.bat start locators=hostname[port]

If you are running more than one locator, use a comma-separated list of locators.

Multisite Setup



For information on when to use this topology, refer to Common Topologies for HTTP Session Management. To enable gateway communication between sites, add the following line to the web application's web.xml file or use the -p gemfire.cache.enable_gateway_replication=true option of the modify_war script:

<filter>
    <filter-name>gemfire-session-filter</filter-name>
    <filter-class>
      com.gemstone.gemfire.modules.session.filter.SessionCachingFilter
    </filter-class>
    <init-param>
        <param-name>cache-type</param-name>
        <param-value>peer-to-peer</param-value>
    </init-param>
    <init-param>
        <param-name>gemfire.cache.enable_gateway_replication</param-name>
        <param-value>true</param-value>
    </init-param>
</filter>

You will now need to modify the GemFire configuration file (either cache-peer.xml for a peer-to-peer configuration or cache-server.xml for a client/server configuration) in the conf subdirectory of the HTTP module instance that will operate as the gateway hub. For example, if you were setting up a gateway between a site named "SITE1" and a site named "SITE2", this is how you would set up the information for site 1:

<gateway-hub id="SITE1" port="22222" socket-buffer-size="256000">
    <gateway id="SITE2_CLUSTERA" socket-buffer-size="256000">
        <gateway-endpoint id="SITE2_CLUSTERA_server1" host="site2_hostname" 
            port="22222"/>
    </gateway>
</gateway-hub>

And at site 2, you would need to set up another gateway hub that communicates with site 1. Notice that the endpoint for site 1 references information about site 2 while the endpoint for site 2 references information about site 1.

<gateway-hub id="SITE2" port="22222" socket-buffer-size="256000">
    <gateway id="SITE1_CLUSTERA" socket-buffer-size="256000">
        <gateway-endpoint id="SITE1_CLUSTERA_server1" host="site1_hostname" 
            port="22222"/>
    </gateway>
</gateway-hub>
Note: To successfully run a configuration using a multi-site topology, you must start at least one server and one client in each site before creating or accessing your session. If a GemFire client is not started in one site, the region data containing the session information will not get initialized. This means that a web server must be started on each site before creating or accessing session data.
See Multi-site (WAN) Configuration for more information.