click here for details... Sakai Executive Director Position Search now open
Issue Details (XML | Word | Printable)

Key: SAK-13324
Type: Branch Branch
Status: Open Open
Priority: Major Major
Assignee: Daniel McCallum
Reporter: Daniel McCallum
Votes: 0
Watchers: 2
Operations

If you were logged in you would be able to see more operations.
Sakai

Add session clustering capability

Created: 04-Apr-2008 10:42   Updated: 09-Apr-2008 14:21
Component/s: Tool service (Pre-K1/2.6)
Affects Version/s: branch
Fix Version/s: None

Time Tracking:
Issue & Sub-Tasks
Issue Only
Not Specified

Sub-Tasks  All   Open   

 Description  « Hide
This is intended as an umbrella ticket collecting work related to user session clustering as described in more detail here: http://confluence.sakaiproject.org/confluence/x/iwACAQ

At this writing, we're looking at clustering Sakai sessions by replicating session attributes (and possibly other fields) via a distributed cache, probably implemented by ehcache.

Subtickets may be associated with any number of Jira components. I chose to associate this ticket with the "Tool (SVN module)," though, since that's where Sakai's SessionManager is currently factored, and it seemed worthwhile to pick at least one Jira component so as not to drop out of filters someone might construct to look for session-related issues in general. There is a "Clustering (SVN module)" component, that might _seem_ like a better choice, at least w/r/t its name, but as it currently stands that module is mainly concerned with maintaining a registry of Sakai instances associated with a cluster rather than replicating/sharing data (user-scoped or otherwise) within a cluster, which is what we're most interested in at the moment.


 All   Comments   Work Log   Change History   Subversion Commits   git Commits      Sort Order: Ascending order - Click to sort in descending order
Daniel McCallum added a comment - 09-Apr-2008 14:21
As Josh observed in SAK-13330, Sakai-managed ClassLoaders pose interesting problems for distributed session caching. I brainstormed a little bit in that ticket about possible workarounds, all of which reinvent Terracotta's distributed ClassLoader support to some extent. After presenting the problem on the Terracotta forums (http://forums.terracotta.org/forums/posts/list/962.page), it _sounds_ as if Terracotta just might turn out to be the best solution, or at least a solution which involves far less custom plumbing than would any "standard" distributed cache solution. I don't expect it to be entirely painless, but for the time being, we're moving forward with a Terracotta proof-of-concept, which may end up recharacterizing several of the subtasks already created.

And of course, if anyone wants to raise Terracotta red flags, please do. I know there's been concern in the past about the deployment complexity, and I'm not 100% confident on license compatibility...