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