unable to load incommon metadata
Lee Foltz
foltz2 at oakland.edu
Fri Feb 28 10:57:13 EST 2020
We switched over our test boxes with plan do move prod next week for the
new InCommon MDQ service. Java heap size went from 4GB to 1GB or less all
the time and the IDP starts up faster.
In case you missed this announcement below.
On January 30th, 2020, the InCommon Federation Technical Advisory
Committee approved
the production release <http://doi.org/10.26869/TI.142.1> of the new
InCommon metadata distribution service, featuring per-entity metadata.
InCommon strongly recommends you switch your SAML software to use the
metadata query or “MDQ” features in our new metadata service.
The InCommon “main” metadata aggregate is now almost 70MB in size, and
requires several gigabytes of memory to parse. This results in enormous
memory footprints and lengthy start-up times for your SAML software. MDQ
prevents your software from using these resources by allowing it to only
fetch the metadata it needs, when it needs it. You can also read about the
improvements we made with this service in a recent blog post by me
<https://incommon.org/news/organizations-urged-to-move-to-metadata-query-service/>
.
Moving to MDQ will require you to update the configuration of your SAML
software to point to a new metadata location and to verify the metadata
using a new public key. The details of all of this are in our new metadata
distribution service documentation, available in our wiki
<https://spaces.at.internet2.edu/x/2wR0C>. Make sure you look at the
documentation for Production rather than the Technical Preview (the latter
is the new version of the old “preview” metadata aggregate service).
Over the next year, we will work with you to transition all InCommon
federation SAML software to the new service; changing to the new service
sooner rather than later is recommended.
Best Regards,
Nick Roy on behalf of InCommon Operations
On Fri, Feb 28, 2020 at 10:00 AM Karla Borecky <kborecky at smith.edu> wrote:
> The InCommon metadata is big - everyone I know (including me) had to
> increase their Java heap size to accommodate it.
>
> On Fri, Feb 28, 2020 at 9:47 AM Peter Schober <peter.schober at univie.ac.at>
> wrote:
>
>> * Ramaiah, Vanna G. <ramaiah at musc.edu> [2020-02-28 15:38]:
>> > After fixing permission denied error, here is the new error - java
>> > memory.
>>
>> And what's the question about that that a web search wouldn't answer?
>>
>> > Also, Should I create an empty InCommon metadada file or the system
>> > will create one?
>>
>> Why would you want an empty file to be created, either manually or by
>> the software?
>> So no, you shouldn't have to create that. Of course you do need to
>> give the user your JVM is running as permissions to write that
>> metadata to the configured location.
>>
>> -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
>>
>
>
> --
> Karla Borecky
> Systems Administrator, ITS
> Smith College
>
> Pronouns: she, her, hers
>
> --
> 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
--
Lee Foltz
Oakland University - UTS
Senior Identity and Access Management Engineer
248-370-2675
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20200228/e6c23fe3/attachment.html>
More information about the users
mailing list