Shibboleth(3.2.3) : Parsing of the Incommons-Medata.xml taking huge amount of time

Spencer Thomas Spencer.Thomas at ithaka.org
Wed Apr 13 17:32:37 UTC 2022


I suggest switching to use MDQ (metadata query service) instead of downloading the entire metadata file. See https://spaces.at.internet2.edu/display/MDQ/production-metadata

On 4/13/22, 1:18 PM, "users" <users-bounces at shibboleth.net> wrote:

Caution: This message did not originate from within ITHAKA's email system. Please use caution when opening attachments and following links within this message.
Hello All,

When we are restarting our Shibd.service during regular maintainance, we are facing a issue with the parsing of the Incommons-metadata.xml file. While checking of signature after downloading of the xml file, taking a very long peroid of time while applying metadata filter for signature i.e. close to 20 mins downtime
……………………………………………………………………………………………………………………………………………………………….
……………………………………………………………………………………………………………………………………………………………….
……………………………………………………………………………………………………………………………………………………………….
2022-04-11 16:27:49 INFO Shibboleth.Application : auto-configuring Logout initiation for protocol (Local)
2022-04-11 16:27:49 INFO Shibboleth.Application : adding LogoutInitiator of type (Local) to chain (/Logout)
2022-04-11 16:27:49 INFO Shibboleth.Handler.DiscoveryFeed : feed files will be cached in /var/cache/shibboleth/
2022-04-11 16:27:49 INFO Shibboleth.Application : building MetadataProvider of type XML...
2022-04-11 16:27:49 INFO OpenSAML.MetadataProvider : building MetadataFilter of type RequireValidUntil
2022-04-11 16:27:49 INFO OpenSAML.MetadataProvider : building MetadataFilter of type Signature
2022-04-11 16:27:49 INFO XMLTooling.SecurityHelper : loading certificate(s) from file (/etc/shibboleth/inc-md-cert.pem)
2022-04-11 16:27:49 INFO XMLTooling.CredentialResolver.File : no private key resolved, usable for verification/trust only
2022-04-11 16:28:00 INFO OpenSAML.MetadataProvider.XML : loaded XML resource (https://md.incommon.org/InCommon/InCommon-metadata.xml)
2022-04-11 16:28:06 INFO OpenSAML.MetadataProvider : applying metadata filter (RequireValidUntil)
2022-04-11 16:28:06 INFO OpenSAML.MetadataProvider : applying metadata filter (Signature)

In January last month itself we had to increase the timeout for starting of the service from 5 to 10mins and now it has increased to 20 mins in such a short time.

Moreover when we checked the CPU usage at this time of outage we saw that the shibd service was consuming 100% of the single thread CPU core consistently.

As we cannot have such a long downtime, and also at a such a constant sharp increase in the downtime. We wanted for some inputs in questions:

·         Is this issue standard, faced by everyone??

·         Is there any parameter in the shibboleth2.xml; altering which could enable the shibd.service to use more numner of CPU nodes if this issue is due to the lack of CPU resouces??

·         If not will shibd.service support the use of hyper-threading; i.e. multiple threads on a single core where the service is being started to illiminate the chance that this parsing delay is due to the CPU resouce shortage??

·         Will increase in the clock rate i.e. Mhz of the CPU help in this case??

·         Is there a way to skip this and us to choose when to parse the newly downloaded xml, so as to reduce downtime??

·         And are there any other solutions that anyone has implemented that has worked around this issue??

Thank you for any inputs, relating to the same.

Yours Sincerely,
Siddharth Satyakam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20220413/f0bd65e8/attachment.htm>


More information about the users mailing list