IDP Cluster going forward (JDK 7)

[Marc Thornton]

Scott,

"Unsupported" meaning that low-level Terracotta DSO support hasn't been
implemented for JDK7 and will not be provided.  We had patiently been
waiting for Terracotta to support JDK 7 (knowning that the DSO mode
required for Shibboleth IDP didn't work) and have now realized that it is
only implemented in non-DSO mode.  DSO mode is being phased out by
Terracotta, with a migration path via BigMemory/EHCache being offered.

As an FYI, we are making use of the Hungarian U SLO at this point.  The
stateless client-side storage does sound interesting though.  We already
have a statefull solution wrapped around the SSO provided by Shibboleth IDP
& SP, so stateless isn't necessarily a requirement in our case.  As the
remainder of our solution is already JDBC-based, it wouldn't be a big reach
(at least in our case) to have that as our backing storage for the IDP.


On Mon, May 27, 2013 at 6:14 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 5/27/13 10:35 AM, "Marc Thornton" <marc.thornton at gmail.com> wrote:
>
> >The current stateful IDP clustering solution requires Terracotta DSO
> >(Distributed Shared Objects).  Terracotta has ceased development on DSO
> >going forward
> >(http://terracotta.org/confluence/pages/viewpage.action?pageId=37129634),
> >which
> > means support for JDK 7 and beyond will not be available.
>
> "Unsupported" meaning it doesn't work and can't be made to work, or
> unsupported meaning they don't fix bugs?
>
> This hasn't been identified as an issue up until now.
>
> >Are there any plans to migrate the Shibboleth IDP for compatibility with
> >either Terracotta's migration path (BigMemory) or an alternative
> >clustering solution?
>
> There were no plans for another 2.x feature release of any kind and we
> will not be using Terracotta again, or any technology like it.
>
> If Terracotta doesn't work with Java 7, then we will have to discuss what
> to do about that. The two obvious extensions one can look at are the
> memcache one, about which I know nothing, and the SSO cookie login
> extension I wrote. It's possible we might have to ship a 2.5 to add one or
> both to the core to extend the viability of the code.
>
> The hoped-for solution for 3.0 will be stateless, client-side storage.
> SAML logout is impossible with that model because cookies are much too
> size-limited, but there are no plans yet as to what might be provided as
> an alternative. Memcache is one possibility but I don't think we can do
> that as a project without a committer who has experience with it, so JDBC
> using best-effort replication is probably more likely.
>
> -- Scott
>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130527/35f98a8d/attachment.html