[Building Sakai] Sakai multiple nodes such session sharing

[Robert Long]

Kurosch,

If you are using 10.x, session failover is generally in place. It’s not 100% failover, but the user will not have to re-login. Their session will be transferred to another server and will be taken back to the site and tool they were currently in (tool state will vary). 

You will need to install a Terracotta server first, then in sakai.properties, enable the properties you require:

# CLUSTER CACHING (KNL-1184)
# WARNING: this requires an external distributed caching server
# Enable distributed caching
# DEFAULT: false
#memory.cluster.enabled=true

# The URLs of the distributed cache servers
#memory.cluster.server.urls.count=2
#memory.cluster.server.urls.1={CACHE_SERVER_URL_1}:9510
#memory.cluster.server.urls.2={CACHE_SERVER_URL_2}:9511

## The caches that will be using the distributed cache.
## The only ones known to be safe are listed:
## EVENTS clustering: org.sakaiproject.event.impl.ClusterEventTracking.eventsCache, org.sakaiproject.event.impl.ClusterEventTracking.eventLastCache
## (events caching shown below as example)
## Events caching uses a distributed cache to propagate events, rather than reading from the database, events are still stored in the database
## SESSION failover: org.sakaiproject.tool.impl.RebuildBreakdownService.cache
## PERFORMANCE: org.sakaiproject.authz.impl.DbAuthzGroupService.realmRoleGroupCache
#memory.cluster.names.count=1
#memory.cluster.names.1=org.sakaiproject.tool.impl.RebuildBreakdownService.cache

## Any Cache properties below that are not set will use the default values
# Valid properties include: maxSize, timeToIdle, timeToLive, eternal
# Defaults: maxSize=10000, timeToIdle=600, timeToLive=600, eternal=false
# Configure cluster caches using: memory.cluster.{cacheName}.{property)={value}

# Session replication caching properties
#memory.cluster.org.sakaiproject.tool.impl.RebuildBreakdownService.cache.maxSize=50000
#memory.cluster.org.sakaiproject.tool.impl.RebuildBreakdownService.cache.timeToIdle=3600
#memory.cluster.org.sakaiproject.tool.impl.RebuildBreakdownService.cache.timeToLive=10800

## Session Replication settings
## WARNING: This requires a distribution mechanism of some kind (currently requires a distributed cache)
## NOTES:
## cache: org.sakaiproject.tool.impl.RebuildBreakdownService.cache must be set to a distributed cache (see memory.cluster)
## cache: org.sakaiproject.tool.impl.RebuildBreakdownService.stash should be configured to last as long
##        as your user might need to navigate to JSF or other on-demand session tools after landing on a new server
# Enable session cluster replication (see notes above)
# Default: false
#session.cluster.replication=true
## Performance tuning settings below - be careful with these numbers as adjusting them downward can create heavy load
# Tuning setting, minimum seconds old the session must be before it will be replicated
# Default: 20
#session.cluster.minSecsOldToStore=20
# Tuning setting, minimum seconds that must pass before session data is updated (since last store)
# NOTE: certain events will cause the session data to be updated in the store regardless of this setting
# Default: 10
#session.cluster.minSecsBetweenStores=10
# Tuning setting, minimum seconds after a session has been rebuilt from the store before it can be updated in the storage again
# Default: 30
#session.cluster.minSecsAfterRebuild=30

—Bob

----
Robert Long
Software Engineer
Technical Account Manager - Sakai
Unicon, Inc.

----
M.A., Instructional Technology
Saginaw Valley State University

On Aug 27, 2014, at 5:28 AM, kurosch.petzold at fu-berlin.de wrote:

> Hello,
> 
> I would like to know how sakai sessions are handled between different nodes. I.e. If I have a configuration with 2 nodes (X & Y) and take down node X for upgrading sakai are the users loged in into node X then served by node Y or do they loose their current session and need to login again (into node Y)?
> 
> Best regards, 
> Kurosch 
> 
> -- 
> Sent from my Jolla
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> 
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"