<html><body><div dir="ltr">
Are you perhaps using metadata filters on each of thousands of entities in the federation aggregate rather than simply validating the signature applied to the aggregate?</div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On 13Apr2022 at 09:17:42, Siddharth Satyakam via users <<a href="mailto:users@shibboleth.net">users@shibboleth.net</a>> wrote:<br></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" type="cite">
<div>
<div>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
</div>
<div lang="EN-US" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Hello All,</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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
</p>
<p class="MsoNormal">……………………………………………………………………………………………………………………………………………………………….</p>
<p class="MsoNormal">……………………………………………………………………………………………………………………………………………………………….</p>
<p class="MsoNormal">……………………………………………………………………………………………………………………………………………………………….</p>
<p class="MsoNormal">2022-04-11 16:27:49 INFO Shibboleth.Application : auto-configuring Logout initiation for protocol (Local)</p>
<p class="MsoNormal">2022-04-11 16:27:49 INFO Shibboleth.Application : adding LogoutInitiator of type (Local) to chain (/Logout)</p>
<p class="MsoNormal">2022-04-11 16:27:49 INFO Shibboleth.Handler.DiscoveryFeed : feed files will be cached in /var/cache/shibboleth/</p>
<p class="MsoNormal">2022-04-11 16:27:49 INFO Shibboleth.Application : building MetadataProvider of type XML...</p>
<p class="MsoNormal">2022-04-11 16:27:49 INFO OpenSAML.MetadataProvider : building MetadataFilter of type RequireValidUntil</p>
<p class="MsoNormal">2022-04-11 16:27:49 INFO OpenSAML.MetadataProvider : building MetadataFilter of type Signature</p>
<p class="MsoNormal">2022-04-11 16:27:49 INFO XMLTooling.SecurityHelper : loading certificate(s) from file (/etc/shibboleth/inc-md-cert.pem)</p>
<p class="MsoNormal">2022-04-11 16:27:49 INFO XMLTooling.CredentialResolver.File : no private key resolved, usable for verification/trust only</p>
<p class="MsoNormal">2022-04-11 16:28:00 INFO OpenSAML.MetadataProvider.XML : loaded XML resource (<a href="https://md.incommon.org/InCommon/InCommon-metadata.xml">https://md.incommon.org/InCommon/InCommon-metadata.xml</a>)</p>
<p class="MsoNormal">2022-04-11 16:28:06 INFO OpenSAML.MetadataProvider : applying metadata filter (RequireValidUntil)</p>
<p class="MsoNormal">2022-04-11 16:28:06 INFO OpenSAML.MetadataProvider : applying metadata filter (Signature)</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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:</p>
<ul style="margin-top:0in" type="disc">
<li class="MsoListParagraph" style="margin-left:0in">Is this issue standard, faced by everyone??</li><li class="MsoListParagraph" style="margin-left:0in">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??</li><li class="MsoListParagraph" style="margin-left:0in">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??</li><li class="MsoListParagraph" style="margin-left:0in">Will increase in the clock rate i.e. Mhz of the CPU help in this case??</li><li class="MsoListParagraph" style="margin-left:0in">Is there a way to skip this and us to choose when to parse the newly downloaded xml, so as to reduce downtime??</li><li class="MsoListParagraph" style="margin-left:0in">And are there any other solutions that anyone has implemented that has worked around this issue??</li></ul>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Thank you for any inputs, relating to the same.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Yours Sincerely,</p>
<p class="MsoNormal">Siddharth Satyakam</p>
</div>
</div>
</div>
<div>
<div>
-- <br>For Consortium Member technical support, see <a href="https://shibboleth.atlassian.net/wiki/x/ZYEpPw">https://shibboleth.atlassian.net/wiki/x/ZYEpPw</a><br>To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</div>
</div>
</blockquote>
</div>
</div></body></html>