Redis support for StorageService in opensaml-java?

[George Wang]

I see.
I was thinking of using one of the MessageReplayHandlers that require
StorageService. There was only memcached based Storage Service, and was
thinking of using redis instead. I think in this case serverside storage is
required, unless you have any other suggestion?



George


On Wed, Aug 17, 2016 at 7:59 PM, Jonathan Johnson <jsjohnson at unicon.net>
wrote:

> I’d like to highlight and emphasize something Scott says: avoid
> server-side storage.
>
> As someone that works with server-side storage (and has written an
> implementation or two), chances are that you really want to use client
> side. It’s a lot more scalable, and for most people, sufficient. I don’t
> like to get into the details of why one might like to use server-side
> because it often elicits the “I need that!” phenomenon. In the several
> deployments of v3 that I’ve done, only a few have needed server-side, and
> most of those because of the CAS protocol support (and once that goes
> stateless, I’ll try to move those folks off server-side).
>
> As another note, it might help the developers if you could identify why
> you might want to use a server-side storage, and perhaps they or someone
> from the community might help find a good fit.
>
> -Jj
>
> On August 17, 2016 at 19:27:46, Cantor, Scott (cantor.2 at osu.edu) wrote:
>
> On 8/17/16 8:06 PM, George Wang wrote:
> > Hi all,
> >
> > I see that we have support for memcached, but not Redis.
> > Do we have any plans on supporting Redis, or was there any decisions
> > being made not to do so?
>
> We can't support every technology that comes along. We don't release
> things and abandon them without serious deliberation, so supporting
> things is not free.
>
> Nobody involved with the project has any experience with Redis, or if
> they have, they haven't said so. If somebody interested in supporting it
> shows up to do the work and support/maintain the code, it will probably
> get done. If not, probably not.
>
> My focus is on avoiding server-side storage altogether and there are
> very few use cases for non-persistent storage in Shibboleth that can't
> be handled on the client.
>
> If we were going to spend real project time in the core team on anything
> involving state management at this point, I think it should be some way
> to replicate webflow state.
>
> -- Scott
> --
> To unsubscribe from this list send an email to
> dev-unsubscribe at shibboleth.net
>
>
> --
> To unsubscribe from this list send an email to
> dev-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20160817/7d256ff3/attachment-0001.html>