shibboleth-embedded-ds, shibd, and json cache file name
Rod Widdowson
rdw at steadingsoftware.com
Tue Aug 13 06:35:23 EDT 2019
I'm not sure if this helps but..
> I found an error "cannot access [long file name]". The file did not exist... because somethings not using the correct cache file
name.
The cache name is an encoding of the SP Application and the metadata "generation" (it changes every time the metadata is reloaded).
The bit you are seeing change is this second one, which argues that it is because the metadata is being reloaded.
> Why are the filenames changing and, if it's just a cache, why doesn't the process recreate it rather fail and log "cannot access
..."?
Consider that someone is downloading the JSON when a metadata reload happens. You don't want that to get garbage. So we create a
new file every time. And updates the pointers to it _after the file has been fully populated_ and the population will run only after
the metadata has been successfully reloaded.
> I see more files and I think the cache changes when the source metadata file changes. But all of the above cache files have the
same
> content.
Well, not everything in the metadata ends up in the JSON and there is no way of knowing what has changed.
> My fear is a metadata file update will unpredictably break my /DiscoFeed service.
Precisely not, for the reasons I describe above. Additionally, if the metadata update fails then a new JSON file isn't created and
the last good one continues to be used.
But why the file is being lost is not clear from reading the code.
More information about the users
mailing list