[jira] [Updated] (OAK-4404) DocumentNodeState.childNodeEntries perform more fetches than required in some cacses

["Chetan Mehrotra (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OAK-4404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chetan Mehrotra updated OAK-4404:
---------------------------------
    Summary: DocumentNodeState.childNodeEntries perform more fetches than required in some cacses  (was: DocumentNodeState.childNodeEntries perform more fetches than required)

> DocumentNodeState.childNodeEntries perform more fetches than required in some cacses
> ------------------------------------------------------------------------------------
>
>                 Key: OAK-4404
>                 URL: https://issues.apache.org/jira/browse/OAK-4404
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: documentmk
>            Reporter: Chetan Mehrotra
>            Assignee: Chetan Mehrotra
>            Priority: Minor
>
> {{DocumentNodeState}} lazily fetches the child node entries in batches of increasing fetchSize starting at 100. Now we have a commit where we add 200 child nodes under /a. This list of child node entries would be cached (all 200 entries). 
> Now if the code later tries to read all these recently added child nodes then DocumentNodeState would perform a fetch for initial 100. The iterator that is returned though is not limited to 100 and returns all 200 entries. As the iterator proceeds {{currentRemaining}} moves to -100 (it starts at 100 the expected fetchSize).
> This causes hasMore to perform one more fetch which then results in a remote call as its a cache miss (cache key inlcudes the base name from where the list should start).
> This extra call can be avoided if the {{DocumentNodeStore}} can convey the information that the returned iterator is complete and in such a case DocumentNodeState does not have to rely on its internal bookkeeping.
> This change would also be required for secondary node store based persistent cache to work. In those case the cache would be able to provide complete iterator but DocumentNodeState would not be able to make best use of this if it sticks to the fetch based approach



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)