IDPv3 seems to fail to reload configuration when under heavy load.

[Ryan Tapp]

I can't remember specifically v2 behavior, but I'm pretty sure everything mostly reloaded in v3 by default EXCEPT new metadata.  Looking at the dist copy of services.properties, it's a PT0S value commented out.  I uncommented at some point and set my checkInterval to 15 minutes and when I introduce new metadata it gets picked up within 15 minutes without service disruption.  Are you sure the trouble IdPs are set to check?

Ryan Tapp
CSU Long Beach

-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of alex.samuseu
Sent: Friday, March 1, 2019 1:05 PM
To: users at shibboleth.net
Subject: IDPv3 seems to fail to reload configuration when under heavy load.

Hello.

We've been using Shibboleth IDP package in a few production setups for many years, starting with version 2.x, and recently switching it to IDPv3. We integrate the IDP in our environment without modifying anything except RemoteUser login handler we customize to redirect users for authentication to our internal identity management service. The general experience with the latest package has been more than satisfactory, so far, but one issue has started to attract more and more attention lately.

A few specialists responsible for some of the setups reported that IDP often won't reload updated configuration from disk for hours, sometimes for days - until finally they have to restart its service (basically, this means terminating the JVM where it runs, and starting it again). A few cases I'm aware of are seem to be about reloading metadata of a new SP - until they restart the service, they get the standard "The application you have accessed is not registered for use with this service" error page which is shown when metadata for a certain SP isn't yet known to IDP.

There isn't clear pattern involved, aside from the fact in all those few cases it were production instances dealing with relatively heavy load 24/7.
I also wasn't been able to reproduce this issues in my local development / QA environment using a mostly idle instance, it seems to behave the same way as IDPv2 did, with configuration reload interval never being longer than
10-20 minutes.

Is anybody aware of an issue like that, and possible solutions for it? May it be a bug of a certain version of IDPv3, which is fixed by now? Currently, the most recent IDPv3 package used in our setups seems to be version 3.3.3



--
Sent from: http://shibboleth.1660669.n2.nabble.com/Shibboleth-Users-f1660767.html
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net