Ehcache configurations for session replication
The following sections give an overview of ready to use Ehcache configurations for session replication packaged in the 3DS Server distribution.
Without replication (default):
Replication through RMI
For more information about RMI and Ehcache consult Ehcache RMI Replicated Caching page.
Replication through JGroups TCP
Replication through JGroups UDP
Verify that IP Multicasting is enabled and nodes can find them self on designated addresses and ports.NOTE: You need to set
bind_addrproperty on the
cacheManagerPeerProviderFactoryif you want to bind to a specific network interface card (NIC).
(check It doesn't work section for more details)
Use an Ehcache configuration
The use of an Ehcache configuration for session replication can be configured via 3DS Server Configuration Properties:
To use one of the packaged configurations (e.g. ehcache-rmi-sync.xml), set the property as follows:
To use a custom configuration (e.g. /etc/3dss/ehcache.xml), set the property as follows:
If you don't specify a configuration for session replication, the configuration found under
$THREEDS_CONFIG_HOME/ehcache.xml is used.
Considerations when choosing an Ehcache session replication strategy
When deciding which replication strategy to choose (RMI, JGroups TCP or JGroups UDP), consider the setup of your network infrastructure and the required features from the replication:
- Synchronous vs. asynchronous replication
- Synchronous means high data refresh with high I/O network traffic over the network.
- Asynchronous means working with old data but you save the network traffic.
- Session replication in 3DS Server happens when:
- Preparation Response data is received from the Directory Server
- 3DS Method Notification is received with information about 3DS Method Completion
- Note that if using JGroups setup synchronous session replication for Ehcache, there is a limitation of not fully synchronizing the nodes before response is returned by 3DS Server.
If immediate session synchronization between the nodes is a must, use of
ehcache-rmi-sync.xmlconfiguration is recommended.
- TCP vs. UDP replication
- TCP is fully reliable protocol, but has restriction that all the nodes in the cluster must be known and configured before starting the system.
- On the other hand, UDP protocol offers flexibility to subscribe and unsubscribe nodes at the replication service at runtime. It is not reliable protocol but JGroups has internal mechanisms that fix this feature.
- UDP uses multicasting, but Virtualization technologies like Xen and VMWare may be blocking multicast. Verify that IP Multicasting is enabled and nodes can find them self on designated addresses and ports. (check It doesn't work section for more details)
- Use of IPv6 might be source of problems, if the nodes are not able to find each other, try specifying
-Djava.net.preferIP4Stack=trueproperty when starting the nodes. (check Problems with IPv6 for more details)