[
https://issues.apache.org/jira/browse/SLING-11113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated SLING-11113:
-----------------------------------
Affects Version/s: Resource Resolver 1.8.2
> resource resolver: bloom filter might be out of sync on startup
> ---------------------------------------------------------------
>
> Key: SLING-11113
> URL: https://issues.apache.org/jira/browse/SLING-11113
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
> Affects Versions: Resource Resolver 1.8.2
> Reporter: Julian Reschke
> Assignee: Carsten Ziegeler
> Priority: Major
> Fix For: Resource Resolver 1.8.4
>
> Attachments: SLING-11113.diff
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> It appears that the bloom filter can be out of sync with the repo on startup.
> Upon startup, when not present, it get's created, and updated with all vanity
> paths found in the repo. If present, it is used as is.
> So for a restart of a node, there's a time window (up to save interval of 60s
> plus downtime) during which the addition of vanity paths will not be
> reflected in the bloom filter.
> Now the bloom filter is only relevant if the number of vanity paths exceeds
> the maximum number, so this problem might be hard to observe.
> AFAIU, the *intent* of persisting the bloom filter is to avoid the cost of
> re-filling it on startup. However, we already know that *finding* the vanity
> paths (doing the query, getting the resources and processing the properties)
> is already costly. It's dubious that avoiding the cost if updating the filter
> helps here.
> Proposal: get rid of the persistence of the bloom filter altogether, reducing
> the complexity of the code significantly.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
