PSML Configuration

Jetspeed Cluster

Jetspeed Distributed Cache Configuration

Jetspeed can be optionally configured to use distributed cache replication with ehcache.
By default, distributed cache replication is disabled but it can be enabled through the Jetspeed configuration.
The assembly folder contains cache.xml to control the ehcache configuration via Spring.

Jetspeed uses cache-replication for managing all of its distributed caches, such as the page-manager and preferences caches.
The ehcache.xml (found in /WEB-INF/classes/) has more detailed cache configuration details.
It has been modified to enable distributed cache replication for all caches including the page manager and preferences caches.

The following examples are taken from the distributed-ehcache.xml (in /WEB-INF/classes/).
If you want to switch to complete distributed cache usage, it is easier to swap the usages of ehache.xml with
the distributed.ehcache.xml completely in cache.xml (in /WEB-INF/assembly/) as shown below.

The Listener and Provider factory caches are required for cache replication. You shouldn't have to enter values in this file but instead use the jetspeed override.properties to set them.
Below are parameters which can be set for configuring the distributed cache.
The port and hostname can be the same for all nodes in the cluster under most default configurations.

Hostnames

The host name, represented by the org.apache.jetspeed.ehcache.hostname property, is the host the listener is running on.
The host name defaults to the host name of the default interface if not specified.
You will be required to specify a host name for each node when the host is multi-homed and you want to control the interface over which cluster messages are received.
For instance, if you happen to setup your network so that the cache to cache communication is not on the default interface, then you have to set that host name property on each machine.
This requires a custom jetspeed.property file for each node.

Configuring a different hostname per node can be done through the Cache Manager configuration Spring bean combined with setting a Java System property.
In the cache.xml, you can configure the CacheManagerConfig to use a system property, in this case a property named server.ref.
This argument is populated at runtime in the portal framework via the following setting in cache.xml:

If you see the above message, check firewall settings to allow UDP/4446. That is
sometimes needed on Lunix systems if firewalls are enabled to allow UDP multicast
loopback. Some older TCP stacks do not support UDP multicast loopback at all. This
is why this test does not outright fail even though distributed caches can not be setup.

Now for the full test: setup two independent tomcat J2 images.
Edit webapps/jetspeed/WEB-INF/assembly/cache.xml for Tomcat image #1:

Startup browsers against each server. Use different host names to
ensure cookies are managed separately (i.e. '127.0.0.1' and 'localhost').
View the same page in each browser. Edit the page in one browser. Upon refresh, changes should be
visible in second browser.

When distributed caches are run on multiple virtual or physical servers, the default
port assigned above does not need to be incremented for each machine. If the servers
are deployed on multiple networks, care must be taken to ensure multicast traffic on
UDP/4446/230.0.0.1 and TCP/40001 is routed between the servers. Additionally,
multicast propagation TTL may have to be specified to enable the UDP packets to
jump between networks. The default value is "1", which is supposed to limit packets
to one subnet. (See the org.apache.jetspeed.ehcache.group.ttl property).

Here is a fully specified cacheManagerConfig bean with its distributed cache default
values for normal installation: