Overloaded shibd questions

[Cantor, Scott]

On 5/19/21, 2:26 PM, "users on behalf of Nate Klingenstein" <users-bounces at shibboleth.net on behalf of ndk at signet.id> wrote:

>    1)  We have a situation in which I believe a remote, overloaded Shibboleth daemon is causing XML-RPC calls
> to it from modules to timeout or fail in other ways, resulting in no attributes being appended to the HTTP
> request by the module before passing the request along to the application for handling. 

It can't do that. They'll either be present or the request will fail, there's no path for it to get through just because the process is failing to respond. It will throw an exception and end the request.

> This is the most suspicious root cause of the looping behavior that I mentioned I was encountering earlier.

It can't loop because it's overloaded unless the client loops of its own accord, which doesn't seem very plausible. It gets back a 500 error, I don't see how that could end up going back to an IdP.

>    in both shibd.logger and native.logger?

That kind of logging distorts performance too much to help diagnose a load related issue.

>    2)  If my hunch is correct, is the addition of a SessionCache likely to change the module's behavior, 

I don't know what you mean, there's always a cache, and anything but in-memory will kill performance relative to the alternative even further....

> and if I want to persist REMOTE_USER, does that need to be done separately from the attribute used to
> populate it, and if so, what is it named?

If you mean the recovery hack, just the attribute, REMOTE_USER is populated each request based on the attribute sources specified.

-- Scott