Common Configuration Changes (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 modify_war:

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

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. -p gemfire.property.locators=hostname[10334]:
<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.

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

./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 GemFire:

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. See vFabric GemFire cacheserver for more information on using this script.

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 using the modify_war script: -p gemfire.cache.enable_gateway_replication=true.

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