Shibboleth SP getting progressively slower

[Cantor, Scott]

On 11/5/12 10:27 AM, "Martin Haase" <Martin.Haase at DAASI.de> wrote:

>Sorry, my fault. What I wanted to say: *if* I maintain the index, shibd
>seems to not remove all sessions, but only the one associated with the
>current request.

That depends on the logout request or process. If the request from an IdP
references a specific SessionIndex (don't confuse that with IdP *or* SP
session, it's neither), then the SP is obligated to remove only the one
session. If the SP is requesting the logout, then by design it's being
asked to remove "the session that's active" for that request.

> Previous sessions are not removed. And the reverse
>index for that NameId neither.

The index is updated, it's not removed. Eventually it expires.

>You can test this also without load, just log in twice and only call
>/Logout for the latter. Then shibd logs a session removal only for the
>latter session.

That's by design, that's what that request means.

>It's the more-common monitoring, and the customer can perhaps live with
>the reverseIndex options you added. I'm just trying to understand what
>calling /Logout does and if it actually makes a difference to closing
>the browser.

Calling /Logout from a client is asking the SP to initiate a logout for
"the session associated with that request". There can never be multiple
sessions associated with a request. You're talking about older sessions
that the SP may know about, but your client has forgotten them and they
are now orphaned.

Orphaned sessions don't specifically get removed from the reverse index
but the overall record in the index for a given NameID gets purged once
the expiration for that record is reached. That's what breaks under load
testing, it just keeps pushing out the expiration for that record.

-- Scott