LocalDynamic + MetadataFilters = possible bug?
Brent Putman
putmanb at georgetown.edu
Thu Jan 14 23:11:13 UTC 2021
On 1/14/21 6:00 PM, Cantor, Scott wrote:
>
> I don't see how it could be related unless there's a clear warning or error in the log. The issue I hit was not subtle, it just wasn't obvious unless I looked in the log. Certainly it could be happening, but it wouldn't be silent about it. And it wouldn't be intermittent, it was always failing.
Yes, I would think so as well. Although, it isn't clear from the
config example whether the entity attributes are applied on all
entities. The example seems obfuscated with an "always true" predicate
and dummy entity attribute value. So maybe it is always happening on
the metadata that the predicate matches, if the latter is selective.
Hopefully Steve can tell us.
>
> Mine was against a batch, so the log only noted it when the metadata was loaded, whereas this would happen at runtime when the filter runs.
Yes, it would happen when the metadata is fetched the first time, and
also later when it's fetched and updated.
>
> However, I considered/assumed that the only likely cause of this was if the LocalDynamic plugin wasn't properly isolating the cached copies in some way between the layers. It seems like there must be a race condition somewhere.
I agree that intermittent usually implies race condition. But off-hand
I don't know how that could be happening here. The dynamic metadata is
fetched and processed under a write lock over the entity ID (of a
read-write lock). Read-only access is then governed by the
corresponding read lock. So no concurrent readers and writers over the
same metadata.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20210114/1b2dee1b/attachment.htm>
More information about the users
mailing list