jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julian Reschke (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (OAK-3189) CLONE - MissingLastRevSeeker non MongoDS may fail with OOM
Date Thu, 06 Aug 2015 13:07:04 GMT

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

Julian Reschke updated OAK-3189:
--------------------------------
    Description: 
(This clones OAK-2208 as that never made it into the 1.0 branch)


This code currently has a hardwired optimization for MongoDB (returning an Iterable over a
DBCursor). For all other persistences, a java List of all matching NodeDocuments will be built.

I see two ways to address this:

1) Generalize the Mongo approach, where a query to the persistence can return a live iterator,
or

2) Stick with the public DS API, but leverage paging (get N nodes at once, and then keep calling
query() again with the right starting ID).

2) sounds simpler, but is not transactional; [~mreutegg] would that be sufficient?

  was:
This code currently has a hardwired optimization for MongoDB (returning an Iterable over a
DBCursor). For all other persistences, a java List of all matching NodeDocuments will be built.

I see two ways to address this:

1) Generalize the Mongo approach, where a query to the persistence can return a live iterator,
or

2) Stick with the public DS API, but leverage paging (get N nodes at once, and then keep calling
query() again with the right starting ID).

2) sounds simpler, but is not transactional; [~mreutegg] would that be sufficient?


> CLONE - MissingLastRevSeeker non MongoDS may fail with OOM
> ----------------------------------------------------------
>
>                 Key: OAK-3189
>                 URL: https://issues.apache.org/jira/browse/OAK-3189
>             Project: Jackrabbit Oak
>          Issue Type: Task
>          Components: core
>    Affects Versions: 1.0.18
>            Reporter: Julian Reschke
>            Assignee: Julian Reschke
>             Fix For: 1.0.19
>
>
> (This clones OAK-2208 as that never made it into the 1.0 branch)
> This code currently has a hardwired optimization for MongoDB (returning an Iterable over
a DBCursor). For all other persistences, a java List of all matching NodeDocuments will be
built.
> I see two ways to address this:
> 1) Generalize the Mongo approach, where a query to the persistence can return a live
iterator, or
> 2) Stick with the public DS API, but leverage paging (get N nodes at once, and then keep
calling query() again with the right starting ID).
> 2) sounds simpler, but is not transactional; [~mreutegg] would that be sufficient?



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

Mime
View raw message