Apache Geode CHANGELOG

Setting Up the HTTP Module for AppServers

To use the module, you need to modify your application’s web.xml files. Configuration is slightly different depending on the topology you are setting up.

Refer to Common Topologies for HTTP Session Management for more information. Modifying the war file can be done manually or with the modify_war script. To see the command line options for the modify_war script, invoke:

$ modify_war -h

Manual Configuration

To modify your war or ear file manually, make the following updates:

  • web.xml needs a filter and listener added as follows. If you have your own filters, the Geode Module filter must be the first one.

  • Add the following jar files from the AppServer.zip to the WEB-INF/lib directory of the war:

    • geode-modules jar
    • geode-modules-session-internal jar
    • geode-modules-session jar
    • slf4j-api jar
    • slf4j-jdk14 jar
  • Add the following jar files from the $GEODE/lib directory to the WEB-INF/lib directory of the war, where $GEODE is set to the Geode product installation:

    • antlr jar
    • fastutil jar
    • geode-core jar
    • geode-json jar
    • javax.transaction-api jar
    • jgroups jar
    • log4j-api jar
    • log4j-core jar
    • log4j-jul jar

If you are deploying an ear file:

  • Copy all the dependent files, given above, to the lib directory of the ear.
  • Modify each embedded war file’s manifest by adding a Class-Path entry which references the shared jars added in the previous step. For example:

    Manifest-Version: 1.0
    Built-By: joe
    Build-Jdk: 1.8.0_77
    Created-By: Apache Maven
    Archiver-Version: Plexus Archiver
    Class-Path: lib/geode-modules-1.0.0.jar

Peer-to-Peer Setup

To run Geode in a peer-to-peer configuration, use the modify_war script with options -t peer-to-peer, -p gemfire.property.locators=localhost[10334], and -p gemfire.propery.cache-xml-file=<moduleDir>/conf/cache-peer.xml to result in the following web.xml content:


Client/Server Setup

To run Geode in a client/server configuration, you make the application server operate as a Geode client. Use the -t client-server option to the modify_war script. This adds the following filter to application server’s web.xml file:

To run Geode in a client/server configuration, you make the application server operate as a Geode client. Use the modify_war script with options -t client-server and -p gemfire.property.cache-xml-file=<module dir>/conf/cache-client.xml to result in the following web.xml content:

        <param-value>module dir/conf/cache-client.xml</param-value>

The cache-client.xml file contains a <pool> element pointing at the locator. Its default value is localhost[10334].

Starting the Application Server

After you update the configuration, you are now ready to start your application server instance. Instantiate the locator first:

$ gfsh start locator --name=locator1

Then start the server:

$ gfsh start server \
    --name=server1 \
    --server-port=0 \
    --locators=localhost[10334] \

Once the application server is started, the Geode client will automatically launch within the application server process.

Verifying that Geode Started

You can verify that Geode has successfully started by inspecting the application server log file. For example:

info 2016/04/18 10:04:18.685 PDT <localhost-startStop-2> tid=0x1a]
Initializing Geode Modules
Java version:   1.0.0 user1 041816 2016-11-18 08:46:17 -0700
javac 1.8.0_92
Native version: native code unavailable
Source revision: 19dd8eb1907e0beb2aa3e0a17d5f12c6cbec6968
Source repository: develop
Running on: /, 8 cpu(s), x86_64 Mac OS X 10.11.4

Information is also logged within the Geode log file, which by default is named gemfire_modules.<date>.log.

Configuring Non-Sticky Session Replication

Some situations require sessions to be ‘non-sticky’, which means that client requests can be directed to any server in a cluster of application servers instead of the same server each time. To achieve this, you must configure your deployment as described for the following topologies.


No additional configuration is required.


For client-server topologies, the local client cache must be empty. Ensure that the filter property gemfire.cache.enable_local_cache=false is set. This effectively sets the local client cache to be a PROXY cache.

Note: Non-sticky sessions affect performance because sessions need to be re-created every time a request hits a different server. This may not be noticeable when the session attributes are small, but may become more evident as the session attributes increase in size and/or number.