Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Current »

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

Other cluster-related configuration

 

TBD: JGroups often seems to select IPv6 addresses (and writes them to PHYSICAL_ADDRESS column of the UP_JGROUPS_PING table which is how the cluster nodes find and communicate with one another). There is an open question on whether IPv6 addresses work. There is a flag -Djava.net.preferIPv4Stack=true that you can set that will have JGroups select an IPv4 address instead. You can try this if your cluster doesn't appear to invalidate caches on the other machines (and let the uportal-users list know).


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.

  • No labels