[
https://issues.apache.org/jira/browse/SLING-13307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18108266#comment-18108266
]
Mohit Kataria commented on SLING-13307:
---------------------------------------
Currently we are using query:
{code:java}
ECT [sling:alias] FROM [nt:base]
WHERE NOT isdescendantnode('/jcr:system')
AND [sling:alias] IS NOT NULL
AND FIRST([sling:alias]) >= '<last FIRST(sling:alias) value seen at end of
page 5>'
ORDER BY FIRST([sling:alias]) {code}
This query is problematic as it derives its next query anchor from the first
property present on node which may not be in sync with index. The problem is we
are using 2 independent systems to fetch next element as anchor in key set
pagination.
e.g.
using query we got
/a/b/c path --> lets say index returned this path based on sling:alias =
[p,q,r]. But in mean while the content changed to sling:alias = [x,q,r].
Now the anchor for next query will be "x" thus we will be exclude all results
where first element for sling:alias is > p and < x.
So there are 2 problems we need to solve:
# handle eventual consistency of index.
# If we use index we should not skip nodes if content on node had changed in
mean while and index is still based on older data.
To tackle eventual consistency issue we can use sync=true on properties we are
using in the query. Secondly ordered jcr:path is a better option to keyset
pagination then FIRST(sling:alias) as we will only traverse content based on
indexed info.
CC: [~reschke] , [~joerghoh]
> Resource Resolver: improve alias caching / handling
> ---------------------------------------------------
>
> Key: SLING-13307
> URL: https://issues.apache.org/jira/browse/SLING-13307
> Project: Sling
> Issue Type: Wish
> Components: ResourceResolver
> Reporter: Julian Reschke
> Priority: Major
>
> Issues with Resource Resolver alias cache
> - once initialized, the cache is treated as a complete view over all aliases
> in the repo
> - cache init can result in incorrect view due how JCR queries work (for
> instance, incomplete or stale index, see
> https://issues.apache.org/jira/browse/SLING-13284)
> - Events received during cache init may be incomplete (best effort in JCR)
> - not using the cache (Osgi config) isn't really an option due to slowness
> (https://issues.apache.org/jira/browse/SLING-9535)
> Why different from vanity paths?
> - vanity path cache is (can be) size limited
> - lookup of vanity paths "fast" anyway
> Potential improvements:
> - re-build the cache regularly, making it "eventually consistent"
> - other ideas?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
