I'm a +1 as long as it fits into the release strategy, and doesn't substantially delay the 3/20 RC1 target.
I think it's consistent with an evolutionary improvement. It would require deployer configuration changes due constructor/naming changes, but I would estimate those at fairly minor. Also the scope of affected deployers would be limited to memcached users.
As far as timelines and readiness, the code I cited is a pull away from going into master. It's already running in our dev environment.
Curious if you've considered RMI replicated Ehcache as well.
I have not, although the same issues that affect memcached with respect to serialization would affect a replicated Ehcache solution.
We're going with memcached because it suits my personal preference for scaling out with simple, single-purpose components. Additionally, the failure mode of memcached is perfectly suited to the needs of a CAS ticket registry that isn't concerned with long-term authentication, which is our case. I'd be pleased to hear that Ehcache is similar, but we've already invested in memcached and are going ahead with it.
M -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
