Shibboleth Developers

["Scott Cantor" <>]

> If each session will have it's own context then I can use the context
> as a key to memcache and store a hashtable with the second level keys
> and values. This way I don't have to search as I have quick access to
> a whole context. What do you think?

That's what I'm currently doing in memory, but for efficiency I'm planning
to rewrite it to avoid having so many locks and extra tables. But see
below...

In your case, I'd be concerned about storing a programming object in memory
that would be shared between servers, seems like that's dependent on having
a very uniform set of servers. I don't know, maybe I'm not following what
you meant by a hashtable?

> What you're saying is that the other caches besides the session cache
> will store everything in a single context per cache? This way the
> context object will become pretty big to be stored as a whole... humm..

That's how most of the other API clients are structured, yes. Originally the
API was designed around few contexts with many records. I had to rethink the
session cache design and that put pressure on that storage model, but a
database is able to accommodate either end of that scale trivially with a
two part table key. It's the in-memory approach where it's hard to optimize
for both. I'm facing similar trade-offs.

Note that each component that uses a StorageService is given a specific
instance to use or build on. It's a manual sort of dependency injection, not
a single global instance. My point being that you could have two
implementations of the API with different performance characterstics and
configure both at once. The Shibboleth configuration allows any number to be
instantiated and you can point the higher level objects at the one you want
them to use.

Just a thought, but I may do something similar myself so that I can build
in-memory versions that perform well in both scenarios.

> As a side note. Is it possible to build the current trunk shib sp? I
> checked out all of the repositories but had some problems generating
> the makefiles...

xmltooling and opensaml2 should build. The SP builds on Windows, but the
Unix build doesn't work yet, I'll probably fix it by next week in prep for
the upcoming preview release. Patches are fine also, just report and attach
them in jira, but I'll probably get to most of them soon enough anyway.

-- Scott