[ https://issues.apache.org/jira/browse/SLING-11113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Carsten Ziegeler resolved SLING-11113. -------------------------------------- Resolution: Fixed > 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 > Reporter: Julian Reschke > Assignee: Carsten Ziegeler > Priority: Major > Fix For: Resource Resolver 1.8.4 > > Attachments: SLING-11113.diff > > Time Spent: 2.5h > 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)