|HTTP Session Management Modules / HTTP Session Management Module for Pivotal tc Server|
By default, the tc Server HTTP module will run GemFire automatically with pre-configured settings. You can change these GemFire settings.
However, you may want to change this default configuration. For example, you might want to change the region from replicated to partitioned, or to use locators for discovery. To change GemFire settings, use the --interactive command line argument when creating your tc Server instance.
In Unix: prompt$ ./tcruntime-instance.sh create my_instance_name --template gemfire-p2p --interactive prompt$ ./tcruntime-instance.sh create my_instance_name --template gemfire-cs --interactive In Windows: prompt> tcruntime-instance.bat create my_instance_name --template gemfire-p2p --interactive prompt> tcruntime-instance.bat create my_instance_name --template gemfire-cs --interactive
In interactive mode, you will be prompted to specify a series of property values. Hit <return> for any property where you would like to use the default value.
Creating instance 'my_instance_name' ... Using separate layout Please enter a value for 'gemfire.maximum.vm.heap.size.mb'. Default '512': Please enter a value for 'gemfire.initial.vm.heap.size.mb'. Default '512': ... ...
After responding to approximately 20 prompts, you should see the following line:
For information on setting up your instance for the most common types of configurations, refer to the sections below. For more information about each interactive prompt, refer to Interactive Mode Reference.
For a GemFire peer-to-peer member to communicate on a different multicast port than the default (10334), answer the following question in the tc Server HTTP module's interactive mode:
Please enter the port used by GemFire members to discover each other using multicast networking. Default '10334': 10335
This example changes the multicast port to 10335.
You typically should change the multicast port so that you don't inadvertently join another GemFire cluster on the same network.
<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"/>
By default, GemFire peers discover each other using multicast communication on a known port. 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, turn off multicast discovery (by setting it to 0) and specify the list of locators.
Please enter the port used by GemFire members to discover each other using multicast networking. Default '10334': 0 Please enter the list of locators used by GemFire members to discover each other. The format is a comma-separated list of host[port]. Default ' ': hostname
This example turns off multicast discovery and 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.
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 GemFire cache-client.xml file in the conf subdirectory of the applicable tc Server instance.
<pool name="sessions"> <locator host="hostname" port="10334"/> </pool>
This example tells the GemFire client (which is the process running the tc Server 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.
For information on when to use this topology, refer to Common Topologies for HTTP Session Management. Setting up a gateway for multi-site communication requires a few configuration changes. You should first create an instance in interactive mode and respond to the following prompt by typing true:
Please specify whether session modifications should be replicated across the WAN. Default 'false': true
After creating the tc Server instance, you will 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 tc Server 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>