How to increase timeout for metadata reload?

[Scott Gilbert]

Thanks. I inherited the service and when new SP's are added they used the
reload service command for attribute-filter, attribute-resolver and
relying-party where applicable. I am assuming they thought that command
could be used also for new metadata as well. We have the incommon file
which is about 70m and around 60 individual SP metadata files in our
metadata directory. We "are" doing it wrong.

Let me know if there is a link to docs explaining how to properly do this
and/or any instructions you might have on adding a new SP with metadata to
the shib service. I will review the instructions you have already provided,
which may prove enough, thanks.


Scott Gilbert
IAM System Admin
ETS Enterprise Technology Services
University of California Santa Barbara



On Fri, Mar 6, 2020 at 10:35 AM Peter Schober <peter.schober at univie.ac.at>
wrote:

> * Scott Gilbert <sgilbert at ucsb.edu> [2020-03-06 18:17]:
> > I am getting the timeout error below on IdP v3.4.6. Is there a setting
> > where I can increase the timeout? Going to check tomcat 9 docs but if
> > anyone has run into this and have a quick fix let me know. Thanks.
> >
> > http --verify=no
> >
> https://localhost:443/idp/profile/admin/reload-service?id=shibboleth.MetadataResolverService
>
> If you have to reload the metadata resolver you're probably doing
> something wrong, such as adding a new metadata provider for each SP or
> piece of metadata. Don't do that. Instead use one of the provided
> alternatives, such as configuring /one/ metadata provider with a local
> aggregate (i.e., put all SPs into a single file and reload that
> specific metadata provider) or with localDynamic (i.e., put all SPs
> into separate files and reload that specific metadata provider).
>
> Unless you're trying to do just that?
>
> What metadata provider causes the slowness, do you know?
> What happens when you try to download all the remote metadata from all
> the other metadata providers, e.g. using `curl -m30 $URL" for each URL?
> Does that help identify the one being slow to respond?
>
> -peter
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20200310/808d5e4c/attachment.html>