RedisStorageService

[Marvin Addison]

On Wed, Mar 29, 2017 at 10:29 AM Cantor, Scott <cantor.2 at osu.edu> wrote:

> I had thought there already had been something done, but if you can't find
> anything, then short of just a quick double check on users (higher traffic,
> so more likely to get seen), I guess not.


Will do.


> Is there a compare/contrast of this with Hazelcast? Unicon has that one
> mostly done, though I think it needs some shoring up if it were to be
> pulled in.
>

No comparison that I'm aware of. While I have no objections to Hazelcast
and know it's well regarded by the Unicon folks, Redis seems far more
widespread. To me the scale of deployment is relevant because it relates to
the amount of tuning and support documentation available on the Web.

This is one of those faddish areas where people seem to glom onto things
> all the time and not just stick with a solution, which makes supporting
> things difficult.
>

I'm coming around to the reality that constant change is the new normal in
IT.

It's premature to be talking about it, but longer term I think I'd be
> happier if we had a smaller set of better choices and eventually deprecate
> the memcache code so we can stop supporting it at some point.
>

Agree. I looked at the memcached project around the end of 2016 and it was
looking fairly inactive in terms of commits, which was surprising. There's
been a healthy amount of activity recently and in fact a release just a few
days ago, so perhaps I just caught it in a lull. Project health aside I
think we can do better for a general-purpose storage platform than
memcached these days. Shoot, I'd rather pull in Unicon's Hazelcast and a
new Redis component than get deadlocked about which is best, assuming of
course the support and development goals could be met with both.

Best,
M <dev-unsubscribe at shibboleth.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20170329/0fa02e60/attachment-0001.html>