Clustering

Since: uPortal 4.0.6

As of 4.0.6 uPortal ships with a clustering enabled EHCache configuration using jGroups. Ehcache is configured to do replication via invalidation, meaning if object A is modified on server 1 all other servers are notified to remove object A from their caches resulting in a re-read from the database on next access. However Ehcache can also replicate certain items between servers as needed, for example to support obtaining the user's password using CAS Clearpass in a clustered uPortal environment.

Configuration

uPortal 4.0.8+: Database-backed TCP discovery and TCP replication

uportal-war/src/main/resources/properties/jgroups.xml specifies the jGroups configuration to use.

This file is based on the default jGroups tcp.xml file included with the jGroups library. This configuration uses TCP based unicast protocol. uPortal synchronizes node discovery using tables in the uPortal database. If the default TCP configuration is used the important configuration options are available from portal.properties. The configuration allows setting the TCP ports to use. Typically these values can remain at defaults.

portal.properties

################################################################################
##                                                                            ##
##                      jGroups TCP Cluster Configuration                     ##
##                                                                            ##
################################################################################
##
## The default jGroups configuration shipped with uPortal uses TCP Unicast. If
## a different jGroups configuration is needed change the contents of 
## uportal-war/src/main/resources/properties/jgroups.xml
##
## The jGroups manaul can be found here:
##  http://www.jgroups.org/manual-3.x/html/index.html
##
## Alternative configurations can be found here:
##  https://github.com/belaban/JGroups/tree/1df66514dcfd7dd3ea494709184a6430f71e3820/conf
##
##
## The port to use for the FD_SOCK protocol
## http://www.jgroups.org/manual-3.x/html/protlist.html#FD_SOCK
##
## Note that the default configuration is to use a 50 port range starting at
## the start_port. So if the specified start_port is already in use the port
## number is incremented and the next port is tried.
##
#uPortal.cacheManager.jgroups.fd_sock.start_port=
##
## The port for the TCP transport to listen on
## http://www.jgroups.org/manual-3.x/html/protlist.html#Transport
##
## Note that the default configuration is to use a 50 port range starting at
## the bind_port. So if the specified bind_port is already in use the port
## number is incremented and the next port is tried.
##
#uPortal.cacheManager.jgroups.tcp.bind_port=
##
## The length of the random token used for the AUTH protocol of the default jGroups
## configuration. Should be a value between 100 and 1000 
##
#org.jasig.portal.jgroups.auth.token_length=1000

For more information, see http://jasig.275507.n4.nabble.com/Re-uportal-dev-EhCache-and-jgroups-question-td4661918.html.
If TCP Unicast is not a viable option for your deployment there are alternate example configurations available here: https://github.com/belaban/JGroups/tree/1df66514dcfd7dd3ea494709184a6430f71e3820/conf
The jGroups manual is also a good source for additional configuration, testing, and debugging information and tools.

Other cluster-related configuration

CAS ClearPass

If you will be using CAS ClearPass to allow portlets in your environment to obtain and use the user's password for Single Sign-on Integration, see the cluster section in Caching and Re-playing Credentials.