From a8002bdbe663574559f419b61115c334c9affa92 Mon Sep 17 00:00:00 2001 From: Steve Hiehn Date: Wed, 19 Jul 2017 16:15:42 -0400 Subject: [PATCH] Adds Pivotal Cloud Cache session state caching details. Signed-off-by: Peter Tran --- docs/container-tomcat.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/docs/container-tomcat.md b/docs/container-tomcat.md index 0808db831e..f758edf8e0 100644 --- a/docs/container-tomcat.md +++ b/docs/container-tomcat.md @@ -91,6 +91,21 @@ By default, the Tomcat instance is configured to store all Sessions and their da ### Redis To enable Redis-based session replication, simply bind a Redis service containing a name, label, or tag that has `session-replication` as a substring. +### Pivotal Cloud Cache +To enable session state caching on 'Pivotal Cloud Cache', bind to a 'Pivotal Cloud Cache' service instance who's name either ends in `-session-replication` or is tagged with `session-replication`. + +Service instances can be created with a tag: + +```sh +$ cf create-service p-cloudcache my-service-instance -t session-replication +``` + +or existing service instances can be given a tag: + +```sh +$ cf update-service new-service-instance -t session-replication +``` + ## Managing Entropy Entropy from `/dev/random` is used heavily to create session ids, and on startup for initializing `SecureRandom`, which can then cause instances to fail to start in time (see the [Tomcat wiki]). Also, the entropy is shared so it's possible for a single app to starve the DEA of entropy and cause apps in other containers that make use of entropy to be blocked. If this is an issue then configuring `/dev/urandom` as an alternative source of entropy may help. It is unlikely, but possible, that this may cause some security issues which should be taken in to account.