[jira] [Updated] (OAK-5958) Document Metrics related classes and interfaces
[
https://issues.apache.org/jira/browse/OAK-5958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-5958:
--
Fix Version/s: 1.14.0
> Document Metrics related classes and interfaces
> ---
>
> Key: OAK-5958
> URL: https://issues.apache.org/jira/browse/OAK-5958
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Michael Dürig
>Assignee: Chetan Mehrotra
>Priority: Major
> Labels: documentation, technical_debt
> Fix For: 1.12.0, 1.14.0
>
>
> The Metrics related classes and interfaces in
> {{org.apache.jackrabbit.oak.stats}} and
> {{org.apache.jackrabbit.oak.plugins.metric}} are largely undocumented.
> Specifically it is not immediately how they should be used, how a new
> {{Stats}} instance should be added, what the effect this would have and how
> it would (or would) not be exposed (e.g. via JMX).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-6914) Improve indexing progress estimates with multiple includes
[ https://issues.apache.org/jira/browse/OAK-6914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6914: -- Fix Version/s: 1.14.0 > Improve indexing progress estimates with multiple includes > -- > > Key: OAK-6914 > URL: https://issues.apache.org/jira/browse/OAK-6914 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: 1.12.0, 1.14.0 > > > With OAK-5970 support was added for providing ETA as indexing progresses. > However as discussed in the issue this estimate might not be good if indexes > have multiple include and excludes > Purpose of this task is to look for ways to improve it -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-5782) Test failure: persistentCache.BroadcastTest.broadcastTCP
[ https://issues.apache.org/jira/browse/OAK-5782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-5782: -- Fix Version/s: 1.14.0 > Test failure: persistentCache.BroadcastTest.broadcastTCP > - > > Key: OAK-5782 > URL: https://issues.apache.org/jira/browse/OAK-5782 > Project: Jackrabbit Oak > Issue Type: Bug > Components: cache, continuous integration, core >Affects Versions: 1.6.0 >Reporter: Hudson >Assignee: Thomas Mueller >Priority: Major > Labels: test-failure, ubuntu > Fix For: 1.12.0, 1.14.0 > > > Jenkins CI failure: > https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/ > The build Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.8 > (latest),nsfixtures=SEGMENT_TAR,profile=unittesting #1447 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.8 (latest),nsfixtures=SEGMENT_TAR,profile=unittesting > #1447|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=SEGMENT_TAR,profile=unittesting/1447/] > [console > log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=SEGMENT_TAR,profile=unittesting/1447/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-5121) review CommitInfo==null in BackgroundObserver with isExternal change
[ https://issues.apache.org/jira/browse/OAK-5121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-5121: -- Fix Version/s: 1.14.0 > review CommitInfo==null in BackgroundObserver with isExternal change > > > Key: OAK-5121 > URL: https://issues.apache.org/jira/browse/OAK-5121 > Project: Jackrabbit Oak > Issue Type: Task > Components: core >Affects Versions: 1.5.13 >Reporter: Stefan Egli >Assignee: Chetan Mehrotra >Priority: Major > Fix For: 1.12.0, 1.14.0 > > Attachments: OAK-5121.patch > > > OAK-4898 changes CommitInfo to be never null. This is the case outside of the > BackgroundObserver - but in the BackgroundObserver itself it is explicitly > set to null when compacting. > Once OAK-4898 is committed this task is about reviewing the implications in > BackgroundObserver wrt compaction and CommitInfo==null -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-5367) Strange path parsing
[
https://issues.apache.org/jira/browse/OAK-5367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-5367:
--
Fix Version/s: 1.14.0
> Strange path parsing
>
>
> Key: OAK-5367
> URL: https://issues.apache.org/jira/browse/OAK-5367
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.12.0, 1.14.0
>
> Attachments: JcrPathParserTest.java
>
>
> Incorrect handling of path with "\{" was fixed in OAK-5260, but the behavior
> of the JcrPathParser is still strange. For example:
> * the root node, "/", is mapped to "/", and the current node, "." is mapped
> to "". But "/." is mapped to the current node (should be root node).
> * "/parent/./childA2" is mapped to "/parent/childA2" (which is fine), but
> "/parent/.}/childA2" is also mapped to "/parent/childA2".
> * "\}\{" and "}\[" and "}}[" are mapped to the current node. So are ".[" and
> "/[" and ".}". And "}\{test" is mapped to "}\{test", which is
> inconsistent-weird.
> * "x\[1\]}" is mapped to "x".
> All that weirdness should be resolved. Some seem to be just weird, but some
> look like they could become a problem at some point ("}\{").
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-3141) Oak should warn when too many ordered child nodes
[ https://issues.apache.org/jira/browse/OAK-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-3141: -- Fix Version/s: 1.14.0 > Oak should warn when too many ordered child nodes > - > > Key: OAK-3141 > URL: https://issues.apache.org/jira/browse/OAK-3141 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Affects Versions: 1.0.16 >Reporter: Jörg Hoh >Assignee: Thomas Mueller >Priority: Major > Fix For: 1.12.0, 1.14.0 > > > When working with the RDBMK we came into situations, that large documents did > not fit into the provided db columns, there was an overflow, which caused oak > not to persist the change. We fixed it by increasing the size of the column. > But it would be nice if Oak could warn if a document exceeds a certain size > (for example 2 megabytes); because this warning indicates, that on a JCR > level there might be a problematic situation, for example: > * ordered node with a large list of childnodes > * or longstanding sessions with lots of changes, which accumulate to large > documents. > It's certainly nice to know if there's a node/document with such a problem, > before the exceptions actually happens and an operation breaks. > This message should be a warning, and should contain the JCR path of the node > plus the current size. To avoid that this message is overseen, it would be > good if it is written everyonce in a while (every 10 minutes?) if this > condition persists. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7224) oak-run check should have an option to check the segments checksums
[
https://issues.apache.org/jira/browse/OAK-7224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-7224:
--
Fix Version/s: 1.14.0
> oak-run check should have an option to check the segments checksums
> ---
>
> Key: OAK-7224
> URL: https://issues.apache.org/jira/browse/OAK-7224
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: run, segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
> Labels: tooling
> Fix For: 1.12.0, 1.14.0
>
>
> {{oak-run check}} does currently *not* check the checksums of the segments.
> As a consequence, there is no quick way of determining the state of the
> repository (corrupt/valid), after corrupting some random node record, as we
> currently do in {{CheckRepositoryTestBase#corruptRecord}}. To determine that,
> there needs to be an attempt to read the corrupt record as part of a
> traversal.
> An easier way would be to have a new dedicated option for this (i.e.,
> {{--segments}}) which checks by default the content of segments against the
> checksums from all the tar files in the specified location. Additionally, it
> could accept as an argument a list of tar files, the segments of which to be
> checked.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-6766) Convert oak-lucene to OSGi R6 annotations
[ https://issues.apache.org/jira/browse/OAK-6766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6766: -- Fix Version/s: 1.14.0 > Convert oak-lucene to OSGi R6 annotations > - > > Key: OAK-6766 > URL: https://issues.apache.org/jira/browse/OAK-6766 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: lucene >Reporter: Robert Munteanu >Priority: Major > Fix For: 1.12.0, 1.14.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6501) Support adding or updating index definitions via oak-run: JSON data format
[
https://issues.apache.org/jira/browse/OAK-6501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-6501:
--
Fix Version/s: 1.14.0
> Support adding or updating index definitions via oak-run: JSON data format
> --
>
> Key: OAK-6501
> URL: https://issues.apache.org/jira/browse/OAK-6501
> Project: Jackrabbit Oak
> Issue Type: Improvement
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.12.0, 1.14.0
>
>
> In OAK-6471 we have support for index definitions via JSON.
> I'm not happy with the escaping (OAK-6476) ("If the string starts with
> namespace..."), I think it's a bit dangerous. Need to investigate whether
> this prevents importing index definitions exported via JSON
> (localhost:/oak:index/lucene.tidy.-1.json).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-3866) Sorting on relative properties doesn't work in Solr
[
https://issues.apache.org/jira/browse/OAK-3866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-3866:
--
Fix Version/s: 1.14.0
> Sorting on relative properties doesn't work in Solr
> ---
>
> Key: OAK-3866
> URL: https://issues.apache.org/jira/browse/OAK-3866
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: solr
>Affects Versions: 1.0.22, 1.2.9, 1.3.13
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
>Priority: Major
> Fix For: 1.12.0, 1.14.0
>
>
> Executing a query like
> {noformat}
> /jcr:root/content/foo//*[(@sling:resourceType = 'x' or @sling:resourceType =
> 'y') and jcr:contains(., 'bar*~')] order by jcr:content/@jcr:primaryType
> descending
> {noformat}
> would assume sorting on the _jcr:primaryType_ property of resulting nodes'
> _jcr:content_ children.
> That is currently not supported in Solr, while it is in Lucene as the latter
> supports index time aggregation.
> We should inspect if it's possible to extend support for Solr too, most
> probably via index time aggregation.
> The query should not fail but at least log a warning about that limitation
> for the time being.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-6836) OnRC report
[
https://issues.apache.org/jira/browse/OAK-6836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-6836:
--
Fix Version/s: 1.14.0
> OnRC report
> ---
>
> Key: OAK-6836
> URL: https://issues.apache.org/jira/browse/OAK-6836
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Valentin Olteanu
>Priority: Minor
> Labels: production
> Fix For: 1.12.0, 1.14.0
>
> Attachments: gcreport.png
>
>
> Currently, the information regarding an online revision cleanup execution is
> scattered across multiple log lines and partially available in the attributes
> of {{SegmentRevisionGarbageCollection}} MBean.
> While useful for debugging, this is hard to grasp for users that need to
> understand the full process to be able to read it.
> The idea would be to create a "report" with all the details of an execution
> and output it at the end - write to log, but also store it in the MBean, from
> where it can be consumed by monitoring and health checks.
> In the MBean, this would replace the _Last*_ attributes.
> In the logs, this could replace all the intermediary logs (switch them to
> DEBUG).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-5159) Killing the process may stop async index update to to 30 minutes, for DocumentStore (MongoDB, RDB)
[ https://issues.apache.org/jira/browse/OAK-5159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-5159: -- Fix Version/s: 1.14.0 > Killing the process may stop async index update to to 30 minutes, for > DocumentStore (MongoDB, RDB) > -- > > Key: OAK-5159 > URL: https://issues.apache.org/jira/browse/OAK-5159 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing >Reporter: Thomas Mueller >Priority: Major > Labels: resilience > Fix For: 1.12.0, 1.14.0 > > > Same as OAK-2108, when using a DocumentStore based repository (MongoDB, > RDBMK). This is also a problem in the single-cluster-node case, not just when > using multiple cluster node. > When killing a node that is running the sync index update, then this async > index update will not run for up to 15 minutes, because the lease time is set > to 15 minutes. > We could probably use Oak / Sling Discovery to improve the situation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-2182) Specify collection to be used by Solr index
[ https://issues.apache.org/jira/browse/OAK-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-2182: -- Fix Version/s: 1.14.0 > Specify collection to be used by Solr index > --- > > Key: OAK-2182 > URL: https://issues.apache.org/jira/browse/OAK-2182 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: solr >Affects Versions: 1.1.0 >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili >Priority: Major > Fix For: 1.12.0, 1.14.0 > > > Currently all the information to hit a Solr server is hold by the singleton > SolrServerProvider while there are some use cases where more than one query > index definition for a Solr index may be done, targeting different content, > and therefore it'd be good to be able to specify which collection should be > used by each of these indexes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7106) Index Tooling for Oak 1.10
[ https://issues.apache.org/jira/browse/OAK-7106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7106: -- Fix Version/s: 1.14.0 > Index Tooling for Oak 1.10 > -- > > Key: OAK-7106 > URL: https://issues.apache.org/jira/browse/OAK-7106 > Project: Jackrabbit Oak > Issue Type: Epic > Components: indexing, run >Reporter: Chetan Mehrotra >Priority: Major > Fix For: 1.12.0, 1.14.0 > > > Epic to track tooling work for Oak 1.10 release -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6515) Decouple indexing and upload to datastore
[ https://issues.apache.org/jira/browse/OAK-6515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6515: -- Fix Version/s: 1.14.0 > Decouple indexing and upload to datastore > - > > Key: OAK-6515 > URL: https://issues.apache.org/jira/browse/OAK-6515 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: indexing, lucene, query >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Minor > Fix For: 1.12.0, 1.14.0 > > > Currently the default async index delay is 5 seconds. Using a larger delay > (e.g. 15 seconds) reduces index related growth, however diffing is delayed 15 > seconds, which can reduce indexing performance. > One option (which might require bigger changes) is to index every 5 seconds, > and store the index every 5 seconds in the local directory, but only write to > the datastore / nodestore every 3rd time (that is, every 15 seconds). > So that other cluster nodes will only see the index update every 15 seconds. > The diffing is done every 5 seconds, and the local index could be used every > 5 or every 15 seconds. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6566) Generate markdown files from metatype description
[ https://issues.apache.org/jira/browse/OAK-6566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6566: -- Fix Version/s: 1.14.0 > Generate markdown files from metatype description > - > > Key: OAK-6566 > URL: https://issues.apache.org/jira/browse/OAK-6566 > Project: Jackrabbit Oak > Issue Type: Task > Components: doc >Reporter: Chetan Mehrotra >Priority: Major > Fix For: 1.12.0, 1.14.0 > > > Currently we maintain some documentation around supporting configuration > options for few components at [1]. Same information is also captured in > metatype annotation. > We should look into generating these md file from metatype. This can possibly > be done via a new maven plugin [2] > [1] http://jackrabbit.apache.org/oak/docs/osgi_config.html > [2] https://github.com/TouK/metatype-exporter-maven-plugin -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-4177) Tests on Mongo should fail if mongo is not available
[
https://issues.apache.org/jira/browse/OAK-4177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-4177:
--
Fix Version/s: 1.14.0
> Tests on Mongo should fail if mongo is not available
>
>
> Key: OAK-4177
> URL: https://issues.apache.org/jira/browse/OAK-4177
> Project: Jackrabbit Oak
> Issue Type: Test
>Reporter: Davide Giannella
>Assignee: Davide Giannella
>Priority: Major
> Fix For: 1.12.0, 1.14.0
>
>
> Most if not all of the IT/UT that run against mongodb have an
> assumption at class level that if mongodb is not available the tests
> are skipped.
> The tests should fail instead if mongodb is not available and we
> explicitly said that, via the {{nsfixtures}} flags, we want to run the
> tests against mongodb.
> We currently have 4 fixtures/flags: DOCUMENT_NS, SEGMENT_MK,
> DOCUMENT_RDB, MEMORY_NS.
> https://github.com/apache/jackrabbit-oak/blob/f957b6787eb7a70eba454ceb1cae90bd4d47f15c/oak-commons/src/test/java/org/apache/jackrabbit/oak/commons/FixturesHelper.java#L46
> We may have the need to introduce a new Fixture/Flag that indicate
> that we want to run the tests against Document using the in-memory
> implementation. For example: DOCUMENT_NS_IM.
> This will be useful on the Apache Jenkins as we don't have mongo there
> but we still want to run all the possible Document NS tests against
> the in-memory implementation when this is possible.
> /cc [~mreutegg]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7671) [oak-run] Deprecate the datastorecheck command in favor of datastore
[
https://issues.apache.org/jira/browse/OAK-7671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-7671:
--
Fix Version/s: 1.14.0
> [oak-run] Deprecate the datastorecheck command in favor of datastore
>
>
> Key: OAK-7671
> URL: https://issues.apache.org/jira/browse/OAK-7671
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: run
>Reporter: Amit Jain
>Assignee: Amit Jain
>Priority: Major
> Fix For: 1.12.0, 1.14.0
>
>
> With the introduction of \{{datastore}} command which supports both garbage
> collection as well as consistency check the \{{datastorecheck}} command
> should be deprecated and delegated internally to use that implementation.
> Besides some options which are currently not supported by the new command
> should also be implemented e.g. --ids, --refs
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7193) DataStore: API to retrieve statistic (file headers, size estimation)
[
https://issues.apache.org/jira/browse/OAK-7193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-7193:
--
Fix Version/s: 1.14.0
> DataStore: API to retrieve statistic (file headers, size estimation)
>
>
> Key: OAK-7193
> URL: https://issues.apache.org/jira/browse/OAK-7193
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: blob
>Reporter: Thomas Mueller
>Priority: Major
> Fix For: 1.12.0, 1.14.0
>
>
> Extension of OAK-6254: in addition to retrieving the size, it would be good
> to retrieve the estimated number and total size per file type. A simple (and
> in my view sufficient) solution is to use the first few bytes ("magic
> numbers", 2 bytes should be enough) to get the file type. That would allow to
> estimate, for example, the number of, and total size, of PDF files, JPEG,
> Lucene index and so on. A histogram would be nice as well, but I think is not
> needed.
> To speed up calculation, the blob ID could be extended with the first 2 bytes
> of the file content, that is: #@ where magic is the
> first two bytes, in hex. That would allow to quickly get the data from the
> blob ids (no need to actually read content).
> Sampling should be enough. The longer it takes, the more accurate the data.
> We could store the data while doing datastore GC, in which case the returned
> data would be somewhat stale; that's OK.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7660) Refactor AzureCompact and Compact
[
https://issues.apache.org/jira/browse/OAK-7660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-7660:
--
Fix Version/s: 1.14.0
> Refactor AzureCompact and Compact
> -
>
> Key: OAK-7660
> URL: https://issues.apache.org/jira/browse/OAK-7660
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
> Labels: tech-debt, technical_debt, tooling
> Fix For: 1.12.0, 1.14.0
>
>
> {{AzureCompact}} in {{oak-segment-azure}} follows closely the structure and
> logic of {{Compact}} in {{oak-segment-tar}}. Since the only thing which
> differs is the underlying persistence used (remote in Azure vs. local in TAR
> files), the common logic should be extracted in a super-class, extended by
> both.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7212) Document the document order traversal option
[ https://issues.apache.org/jira/browse/OAK-7212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7212: -- Fix Version/s: 1.14.0 > Document the document order traversal option > > > Key: OAK-7212 > URL: https://issues.apache.org/jira/browse/OAK-7212 > Project: Jackrabbit Oak > Issue Type: Documentation > Components: doc, run >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Major > Fix For: 1.12.0, 1.14.0 > > > Document the doc-order-traversal option introduced with OAK-6353 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6166) Support versioning in the composite node store
[ https://issues.apache.org/jira/browse/OAK-6166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6166: -- Fix Version/s: 1.14.0 > Support versioning in the composite node store > -- > > Key: OAK-6166 > URL: https://issues.apache.org/jira/browse/OAK-6166 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: composite >Reporter: Tomek Rękawek >Priority: Minor > Fix For: 1.12.0, 1.14.0 > > > The mount info provider should affect the versioning code as well, so version > histories for the mounted paths are stored separately. Similarly to what we > have in the indexing, let's store the mounted version histories under: > /jcr:system/jcr:versionStorage/:oak:mount-MOUNTNAME -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-5924) Prevent long running query from delaying refresh of index
[
https://issues.apache.org/jira/browse/OAK-5924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-5924:
--
Fix Version/s: 1.14.0
> Prevent long running query from delaying refresh of index
> -
>
> Key: OAK-5924
> URL: https://issues.apache.org/jira/browse/OAK-5924
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Major
> Fix For: 1.12.0, 1.14.0
>
>
> Whenever the index gets updated {{IndexTracker}} detects the changes and open
> new {{IndexNode}} and closes old index nodes. This flow would block untill
> all old IndexNode are closed.
> IndexNode close itself relies on a writer lock. It can happen that a long
> running query i.e. a query which is about to read a page of large is
> currently executing on the old IndexNode instance. This query is trying load
> 100k docs and is very slow (due to loading of excerpt) then such a query
> would prevent the IndexNode from getting closed. This in turn would prevent
> the index from seeing latest data and become stale.
> To make query and indexing more resilient we should look if current IndexNode
> being used for query is closing or not. If closing then query should open a
> fresh searcher
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-3236) integration test that simulates influence of clock drift
[ https://issues.apache.org/jira/browse/OAK-3236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-3236: -- Fix Version/s: 1.14.0 > integration test that simulates influence of clock drift > > > Key: OAK-3236 > URL: https://issues.apache.org/jira/browse/OAK-3236 > Project: Jackrabbit Oak > Issue Type: Test > Components: core >Affects Versions: 1.3.4 >Reporter: Stefan Egli >Priority: Major > Fix For: 1.12.0, 1.14.0 > > > Spin-off of OAK-2739 [of this > comment|https://issues.apache.org/jira/browse/OAK-2739?focusedCommentId=14693398&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14693398] > - ie there should be an integration test that show cases the issues with > clock drift and why it is a good idea to have a lease-check (that refuses to > let the document store be used any further once the lease times out locally) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-3717) Make it possible to declare SynonymFilter within Analyzer with WN dictionary
[
https://issues.apache.org/jira/browse/OAK-3717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-3717:
--
Fix Version/s: 1.14.0
> Make it possible to declare SynonymFilter within Analyzer with WN dictionary
>
>
> Key: OAK-3717
> URL: https://issues.apache.org/jira/browse/OAK-3717
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
>Priority: Major
> Fix For: 1.12.0, 1.14.0
>
>
> Currently one can compose Lucene Analyzers via
> [composition|http://jackrabbit.apache.org/oak/docs/query/lucene.html#Create_analyzer_via_composition]
> within an index definition. It'd be good to be able to also use
> {{SynonymFIlter}} in there, eventually decorated with
> {{WordNetSynonymParser}} to leverage WordNet synonym files.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-5984) Property indexes can get ouf of sync
[ https://issues.apache.org/jira/browse/OAK-5984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-5984: -- Fix Version/s: 1.14.0 > Property indexes can get ouf of sync > > > Key: OAK-5984 > URL: https://issues.apache.org/jira/browse/OAK-5984 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: property-index >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Major > Fix For: 1.12.0, 1.14.0 > > > Property indexes can get out of sync for the following reasons: > * the index was disabled for some time > * the property index component was not started / configured > * the index definition was changed without reindexing -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6165) Create compound index on _sdType and _sdMaxRevTime (RDB)
[ https://issues.apache.org/jira/browse/OAK-6165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6165: -- Fix Version/s: 1.14.0 > Create compound index on _sdType and _sdMaxRevTime (RDB) > > > Key: OAK-6165 > URL: https://issues.apache.org/jira/browse/OAK-6165 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: rdbmk >Reporter: Chetan Mehrotra >Assignee: Julian Reschke >Priority: Major > Fix For: 1.12.0, 1.14.0 > > > Clone for OAK-6129 for RDB i.e. create index on OAK-6129on _sdType and > _sdMaxRevTime. This is required to run queries issued by the Revision GC > efficiently. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7744) Persistent cache for the Segment Node Store
[
https://issues.apache.org/jira/browse/OAK-7744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-7744:
--
Fix Version/s: 1.14.0
> Persistent cache for the Segment Node Store
> ---
>
> Key: OAK-7744
> URL: https://issues.apache.org/jira/browse/OAK-7744
> Project: Jackrabbit Oak
> Issue Type: Story
> Components: segment-tar
>Reporter: Tomek Rękawek
>Assignee: Tomek Rękawek
>Priority: Major
> Fix For: 1.12.0, 1.14.0
>
> Attachments: OAK-7744.patch
>
>
> With the introduction of custom, remote persistence mechanisms for the
> SegmentMK (namely the Azure Segment Store), it makes sense to create another
> level of cache, apart from the on-heap segment cache which is currently used.
> Let's implement the persistent cache, using the existing {{TarFiles}} class
> and storing the processed segments on disk. It may be created as a
> pass-through {{SegmentNodeStorePersistence}} implementation, so it can be
> composed with other existing persistence implementations, eg. [split
> persistence|OAK-7735].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-6387) Building an index (new index + reindex): temporarily store blob references
[ https://issues.apache.org/jira/browse/OAK-6387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6387: -- Fix Version/s: 1.14.0 > Building an index (new index + reindex): temporarily store blob references > -- > > Key: OAK-6387 > URL: https://issues.apache.org/jira/browse/OAK-6387 > Project: Jackrabbit Oak > Issue Type: Bug > Components: lucene, query >Reporter: Thomas Mueller >Priority: Major > Fix For: 1.12.0, 1.14.0 > > > If reindexing a Lucene index takes multiple days, and if datastore garbage > collection (DSGC) is run during that time, then DSGC may remove binaries of > that index because they are not referenced. > It would be good if all binaries that are needed, and that are older than > (for example) one hour, are referenced during reindexing (for example in a > temporary location). So that DSGC will not remove them. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-4934) Query shapes for JCR Query
[
https://issues.apache.org/jira/browse/OAK-4934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-4934:
--
Fix Version/s: 1.14.0
> Query shapes for JCR Query
> --
>
> Key: OAK-4934
> URL: https://issues.apache.org/jira/browse/OAK-4934
> Project: Jackrabbit Oak
> Issue Type: Wish
> Components: query
>Reporter: Chetan Mehrotra
>Priority: Major
> Fix For: 1.12.0, 1.14.0
>
>
> For certain requirements it would be good to have a notion/support to deduce
> query shape [1]
> {quote}
> A combination of query predicate, sort, and projection specifications.
> For the query predicate, only the structure of the predicate, including the
> field names, are significant; the values in the query predicate are
> insignificant. As such, a query predicate \{ type: 'food' \} is equivalent to
> the query predicate \{ type: 'utensil' \} for a query shape.
> {quote}
> So transforming that to Oak the shape should represent a JCR-SQL2 query
> string (xpath query gets transformed to SQL2) which is a *canonical*
> representation of actual query ignoring the property restriction values.
> Example we have 2 queries
> * SELECT * FROM [app:Asset] AS a WHERE a.[jcr:content/metadata/status] =
> 'published'
> * SELECT * FROM [app:Asset] AS a WHERE a.[jcr:content/metadata/status] =
> 'disabled'
> The query shape would be
> SELECT * FROM [app:Asset] AS a WHERE a.[jcr:content/metadata/status] = 'A'.
> The plan for query having given shape would remain same irrespective of value
> of property restrictions. Path restriction can cause some difference though
> The shape can then be used for
> * Stats Collection - Currently stats collection gets overflown if same query
> with different value gets invoked
> * Allow configuring hints - See support in Mongo [2] for an example. One
> specify via config that for a query of such and such shape this index should
> be used
> * Less noisy diagnostics - If a query gets invoked with bad plan the QE can
> log the warning once instead of logging it for each query invocation
> involving different values.
> [1] https://docs.mongodb.com/manual/reference/glossary/#term-query-shape
> [2] https://docs.mongodb.com/manual/reference/command/planCacheSetFilter/
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7166) Union with different selector names
[
https://issues.apache.org/jira/browse/OAK-7166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-7166:
--
Fix Version/s: 1.14.0
> Union with different selector names
> ---
>
> Key: OAK-7166
> URL: https://issues.apache.org/jira/browse/OAK-7166
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.12.0, 1.14.0
>
>
> The following query returns the wrong nodes:
> {noformat}
> /jcr:root/libs/(* | */* | */*/* | */*/*/* | */*/*/*/*)/install
> select b.[jcr:path] as [jcr:path], b.[jcr:score] as [jcr:score], b.* from
> [nt:base] as a
> inner join [nt:base] as b on ischildnode(b, a)
> where ischildnode(a, '/libs') and name(b) = 'install'
> union select c.[jcr:path] as [jcr:path], c.[jcr:score] as [jcr:score], c.*
> from [nt:base] as a
> inner join [nt:base] as b on ischildnode(b, a)
> inner join [nt:base] as c on ischildnode(c, b)
> where ischildnode(a, '/libs') and name(c) = 'install'
> union select d.[jcr:path] as [jcr:path], d.[jcr:score] as [jcr:score], d.*
> from [nt:base] as a
> inner join [nt:base] as b on ischildnode(b, a)
> inner join [nt:base] as c on ischildnode(c, b)
> inner join [nt:base] as d on ischildnode(d, c)
> where ischildnode(a, '/libs') and name(d) = 'install'
> {noformat}
> If I change the selector name to "x" in each subquery, then it works. There
> is no XPath version of this workaround:
> {noformat}
> select x.[jcr:path] as [jcr:path], x.[jcr:score] as [jcr:score], x.* from
> [nt:base] as a
> inner join [nt:base] as x on ischildnode(x, a)
> where ischildnode(a, '/libs') and name(x) = 'install'
> union select x.[jcr:path] as [jcr:path], x.[jcr:score] as [jcr:score], x.*
> from [nt:base] as a
> inner join [nt:base] as b on ischildnode(b, a)
> inner join [nt:base] as x on ischildnode(x, b)
> where ischildnode(a, '/libs') and name(x) = 'install'
> union select x.[jcr:path] as [jcr:path], x.[jcr:score] as [jcr:score], x.*
> from [nt:base] as a
> inner join [nt:base] as b on ischildnode(b, a)
> inner join [nt:base] as c on ischildnode(c, b)
> inner join [nt:base] as x on ischildnode(x, c)
> where ischildnode(a, '/libs') and name(x) = 'install'
> {noformat}
> Need to check if this is a Oak bug, or a bug in the query tool I use.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-5858) Lucene index may return the wrong result if path is excluded
[
https://issues.apache.org/jira/browse/OAK-5858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-5858:
--
Fix Version/s: 1.14.0
> Lucene index may return the wrong result if path is excluded
>
>
> Key: OAK-5858
> URL: https://issues.apache.org/jira/browse/OAK-5858
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Thomas Mueller
>Priority: Major
> Fix For: 1.12.0, 1.14.0
>
>
> If a query uses a Lucene index that has "excludedPaths", the query result may
> be wrong (not contain all matching nodes). This is case even if there is a
> property index available for the queried property. Example:
> {noformat}
> Indexes:
> /oak:index/resourceType/type = "property"
> /oak:index/lucene/type = "lucene"
> /oak:index/lucene/excludedPaths = ["/etc"]
> /oak:index/lucene/indexRules/nt:base/properties/resourceType
> Query:
> /jcr:root/etc//*[jcr:like(@resourceType, "x%y")]
> Index cost:
> cost for /oak:index/resourceType is 1602.0
> cost for /oak:index/lucene is 1001.0
> Result:
> (empty)
> Expected result:
> /etc/a
> /etc/b
> {noformat}
> Here, the lucene index is picked, even thought the query explicitly queries
> for /etc, and the lucene index has this path excluded.
> I think the lucene index should not be picked in case the index does not
> match the query path.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7098) Refactor common logic between IndexUpdate and DocumentStoreIndexer
[ https://issues.apache.org/jira/browse/OAK-7098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7098: -- Fix Version/s: 1.14.0 > Refactor common logic between IndexUpdate and DocumentStoreIndexer > -- > > Key: OAK-7098 > URL: https://issues.apache.org/jira/browse/OAK-7098 > Project: Jackrabbit Oak > Issue Type: Task > Components: indexing, run >Reporter: Chetan Mehrotra >Priority: Major > Fix For: 1.12.0, 1.14.0 > > > DocumentStoreIndexer implements an alternative way of indexing which differs > from diff based indexing done by IndexUpdate. However some part of logic is > commong > We should refactor them and abstract them out so both can share same logic -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6187) Index usage analysis (which index was used when and how)
[ https://issues.apache.org/jira/browse/OAK-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6187: -- Fix Version/s: 1.14.0 > Index usage analysis (which index was used when and how) > > > Key: OAK-6187 > URL: https://issues.apache.org/jira/browse/OAK-6187 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: query >Reporter: Thomas Mueller >Priority: Minor > Fix For: 1.12.0, 1.14.0 > > > In order to reduce space usage, unused indexes should be removed or trimmed. > Trimmed, because an index definition might contain "too much" (specially > Lucene indexes, which index multiple properties and can be very large). > One solution is to > * log each query (avoiding duplicates), > * include which indexes were used, > * from that generate the minimum index definitions, > * compared with existing indexes, get the list of unused indexes and index > features since day X. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6773) Convert oak-store-composite to OSGi R6 annotations
[ https://issues.apache.org/jira/browse/OAK-6773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6773: -- Fix Version/s: 1.14.0 > Convert oak-store-composite to OSGi R6 annotations > -- > > Key: OAK-6773 > URL: https://issues.apache.org/jira/browse/OAK-6773 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: composite >Reporter: Robert Munteanu >Priority: Major > Fix For: 1.12.0, 1.14.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6597) rep:excerpt not working for content indexed by aggregation in lucene
[
https://issues.apache.org/jira/browse/OAK-6597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-6597:
--
Fix Version/s: 1.14.0
> rep:excerpt not working for content indexed by aggregation in lucene
>
>
> Key: OAK-6597
> URL: https://issues.apache.org/jira/browse/OAK-6597
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.6.1, 1.7.6, 1.8.0
>Reporter: Dirk Rudolph
>Assignee: Chetan Mehrotra
>Priority: Major
> Labels: excerpt
> Fix For: 1.12.0, 1.14.0
>
> Attachments: excerpt-with-aggregation-test.patch
>
>
> I mentioned that properties that got indexed due to an aggregation are not
> considered for excerpts (highlighting) as they are not indexed as stored
> fields.
> See the attached patch that implements a test for excerpts in
> {{LuceneIndexAggregationTest2}}.
> It creates the following structure:
> {code}
> /content/foo [test:Page]
> + bar (String)
> - jcr:content [test:PageContent]
> + bar (String)
> {code}
> where both strings (the _bar_ property at _foo_ and the _bar_ property at
> _jcr:content_) contain different text.
> Afterwards it queries for 2 terms ("tinc*" and "aliq*") that either exist in
> _/content/foo/bar_ or _/content/foo/jcr:content/bar_ but not in both. For the
> former one the excerpt is properly provided for the later one it isn't.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-6767) Remove felix SCR annotation support from parent pom
[ https://issues.apache.org/jira/browse/OAK-6767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6767: -- Fix Version/s: 1.14.0 > Remove felix SCR annotation support from parent pom > --- > > Key: OAK-6767 > URL: https://issues.apache.org/jira/browse/OAK-6767 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: parent >Reporter: Robert Munteanu >Priority: Major > Fix For: 1.12.0, 1.14.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6772) Convert oak-solr-core to OSGi R6 annotations
[ https://issues.apache.org/jira/browse/OAK-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6772: -- Fix Version/s: 1.14.0 > Convert oak-solr-core to OSGi R6 annotations > > > Key: OAK-6772 > URL: https://issues.apache.org/jira/browse/OAK-6772 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: solr >Reporter: Robert Munteanu >Priority: Major > Fix For: 1.12.0, 1.14.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-3658) Test failures: JackrabbitNodeTest#testRename and testRenameEventHandling
[
https://issues.apache.org/jira/browse/OAK-3658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-3658:
--
Fix Version/s: 1.14.0
> Test failures: JackrabbitNodeTest#testRename and testRenameEventHandling
>
>
> Key: OAK-3658
> URL: https://issues.apache.org/jira/browse/OAK-3658
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Reporter: Amit Jain
>Assignee: Amit Jain
>Priority: Minor
> Fix For: 1.12.0, 1.14.0
>
>
> Tests fail regularly on trunk - {{JackrabbitNodeTest#testRename}} and
> {{JackrabbitNodeTest#testRenameEventHandling}}.
> {noformat}
> Test set: org.apache.jackrabbit.oak.jcr.JackrabbitNodeTest
> ---
> Tests run: 8, Failures: 1, Errors: 1, Skipped: 0, Time elapsed: 0.106 sec <<<
> FAILURE!
> testRenameEventHandling(org.apache.jackrabbit.oak.jcr.JackrabbitNodeTest)
> Time elapsed: 0.01 sec <<< ERROR!
> javax.jcr.nodetype.ConstraintViolationException: Item is protected.
> at
> org.apache.jackrabbit.oak.jcr.session.ItemImpl$ItemWriteOperation.checkPreconditions(ItemImpl.java:98)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.prePerform(SessionDelegate.java:614)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:270)
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl.rename(NodeImpl.java:1485)
> at
> org.apache.jackrabbit.oak.jcr.JackrabbitNodeTest.testRenameEventHandling(JackrabbitNodeTest.java:124)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at
> org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:464)
> at junit.framework.TestSuite.runTest(TestSuite.java:252)
> at junit.framework.TestSuite.run(TestSuite.java:247)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> testRename(org.apache.jackrabbit.oak.jcr.JackrabbitNodeTest) Time elapsed:
> 0.007 sec <<< FAILURE!
> junit.framework.ComparisonFailure: expected:<[a]> but was:<[rep:policy]>
> at junit.framework.Assert.assertEquals(Assert.java:100)
> at junit.framework.Assert.assertEquals(Assert.java:107)
> at junit.framework.TestCase.assertEquals(TestCase.java:269)
> at
> org.apache.jackrabbit.oak.jcr.JackrabbitNodeTest.testRename(JackrabbitNodeTest.java:74)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.ja
[jira] [Updated] (OAK-2777) Minimize the cost calculation for queries using reference restrictions.
[ https://issues.apache.org/jira/browse/OAK-2777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-2777: -- Fix Version/s: 1.14.0 > Minimize the cost calculation for queries using reference restrictions. > --- > > Key: OAK-2777 > URL: https://issues.apache.org/jira/browse/OAK-2777 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, query >Affects Versions: 1.1.2, 1.2 >Reporter: Przemo Pakulski >Assignee: Thomas Mueller >Priority: Major > Labels: performance > Fix For: 1.12.0, 1.14.0 > > Attachments: oak-2777.patch > > > According to the javadocs (QueryIndex) minimum cost for index is 1. Currently > ReferenceIndex returns this minimum value, when it can be used for the query. > But even then cost for remaining indexes is still calculated. We could skip > cost calculation of remaining indexes if we achieved the minimum cost already. > It will speed up all queries which can leverage the reference Index. > Example query: > SELECT * FROM [nt:base] WHERE PROPERTY([rep:members], 'WeakReference') = > '345bef9b-ffa1-3e09-85df-1e03cfa0fb37' -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6062) Test failure: CopyBinariesTest.validateMigration
[
https://issues.apache.org/jira/browse/OAK-6062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-6062:
--
Fix Version/s: 1.14.0
> Test failure: CopyBinariesTest.validateMigration
>
>
> Key: OAK-6062
> URL: https://issues.apache.org/jira/browse/OAK-6062
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration, documentmk
>Reporter: Hudson
>Priority: Major
> Labels: CI, flaky-test, jenkins, test-failure
> Fix For: 1.12.0, 1.14.0
>
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #146 has failed.
> First failed run: [Jackrabbit Oak
> #146|https://builds.apache.org/job/Jackrabbit%20Oak/146/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/146/console]
> The test failure is:
> {noformat}
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest
> validateMigration[Copy references, no blobstores defined, document ->
> segment-tar](org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest)
> Time elapsed: 2.534 sec <<< ERROR!
> javax.jcr.RepositoryException: Failed to copy content
> at
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.prepare(CopyBinariesTest.java:183)
> Caused by: java.lang.IllegalStateException: Branch with failed reset
> at
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.prepare(CopyBinariesTest.java:183)
> Caused by: org.apache.jackrabbit.oak.api.CommitFailedException: OakOak0100:
> Branch reset failed
> at
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.prepare(CopyBinariesTest.java:183)
> Caused by: org.apache.jackrabbit.oak.plugins.document.DocumentStoreException:
> Empty branch cannot be reset
> at
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.prepare(CopyBinariesTest.java:183)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-5950) XPath: stack overflow for large combination of "or" and "and"
[
https://issues.apache.org/jira/browse/OAK-5950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-5950:
--
Fix Version/s: 1.14.0
> XPath: stack overflow for large combination of "or" and "and"
> -
>
> Key: OAK-5950
> URL: https://issues.apache.org/jira/browse/OAK-5950
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Thomas Mueller
>Priority: Critical
> Fix For: 1.12.0, 1.14.0
>
>
> The following query returns in a stack overflow:
> {noformat}
> xpath2sql /jcr:root/home//element(*,rep:Authorizable)[(@a1=1 or @a2=1 or
> @a3=1 or @a4=1 or @a5=1 or @a6=1 or @a7=1 or @a8=1)
> and (@b1=1 or @b2=1 or @b3=1 or @b4=1 or @b5=1 or @b6=1 or @b7=1 or @b8=1)
> and (@c1=1 or @c2=1 or @c3=1 or @c4=1 or @c5=1 or @c6=1 or @c7=1 or @c8=1)
> and (@d1=1 or @d2=1 or @d3=1 or @d4=1 or @d5=1 or @d6=1 or @d7=1 or @d8=1)]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-6760) Convert oak-blob-cloud to OSGi R6 annotations
[ https://issues.apache.org/jira/browse/OAK-6760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6760: -- Fix Version/s: 1.14.0 > Convert oak-blob-cloud to OSGi R6 annotations > - > > Key: OAK-6760 > URL: https://issues.apache.org/jira/browse/OAK-6760 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: blob-cloud >Reporter: Robert Munteanu >Priority: Major > Fix For: 1.12.0, 1.14.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7941) Test failure: IndexCopierTest.directoryContentMismatch_COR
[
https://issues.apache.org/jira/browse/OAK-7941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-7941:
--
Fix Version/s: 1.14.0
> Test failure: IndexCopierTest.directoryContentMismatch_COR
> --
>
> Key: OAK-7941
> URL: https://issues.apache.org/jira/browse/OAK-7941
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration, lucene
>Reporter: Hudson
>Priority: Major
> Fix For: 1.12.0, 1.14.0
>
>
> No description is provided
> The build Jackrabbit Oak #1830 has failed.
> First failed run: [Jackrabbit Oak
> #1830|https://builds.apache.org/job/Jackrabbit%20Oak/1830/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/1830/console]
> {noformat}
> [ERROR] Tests run: 24, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 0.832 s <<< FAILURE! - in
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopierTest
> [ERROR]
> directoryContentMismatch_COR(org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopierTest)
> Time elapsed: 0.08 s <<< FAILURE!
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopierTest.readAndAssert(IndexCopierTest.java:1119)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopierTest.directoryContentMismatch_COR(IndexCopierTest.java:1081)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-6628) More precise indexRules support via filtering criteria on property
[
https://issues.apache.org/jira/browse/OAK-6628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-6628:
--
Fix Version/s: 1.14.0
> More precise indexRules support via filtering criteria on property
> --
>
> Key: OAK-6628
> URL: https://issues.apache.org/jira/browse/OAK-6628
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Chetan Mehrotra
>Priority: Major
> Fix For: 1.12.0, 1.14.0
>
>
> For Lucene index we currently support indexRules based on nodetype. Here the
> recommendation is that users must use most precise nodeType/mixinType to
> target the indexing rule so that only relevant nodes are indexed.
> For many Sling based applications its being seen that lots of content is
> nt:unstructured and it uses {{sling:resourceType}} property to distinguish
> various such nt:unstructured nodes. Currently its not possible to target
> index definition to index only those nt:unstructured which have specific
> {{sling:resourceType}}. Which makes it harder to provide a more precise index
> definitions.
> To help such cases we can generalize the indexRule support via a filtering
> criteria
> {noformat}
> activityIndex
> - type = "lucene"
> + indexRules
> + nt:unstructured
> - filter-property = "sling:resourceType"
> - filter-value = "app/activitystreams/components/activity"
> + properties
> - jcr:primaryType = "nt:unstructured"
> + verb
> - propertyIndex = true
> - name = "verb"
> {noformat}
> So indexRule would have 2 more config properties
> * filter-property - Name of property to match
> * filter-value - The value to match
> *Indexing*
> At time of indexing currently LuceneIndexEditor does a
> {{indexDefinition.getApplicableIndexingRule}} passing it the NodeState.
> Currently this checks only for jcr:PrimaryType and jxr:mixins to find
> matching rule.
> This logic would need to be extended to also check if any filter-property is
> defined in definition. If yes then check if NodeState has that value
> *Querying*
> On query side we need to change the IndexPlanner where it currently use query
> nodetype for finding matching indexRule. In addition it would need to pass on
> the property restrictions and the rule only be matched if the property
> restriction matches the filter
> *Open Item*
> # How to handle change in filter-property value. I think we have similar
> problem currently if an index nodes nodeType gets changed. In such a case we
> do not remove it from index. So we need to solve that for both
> # Ensure that all places where rules are matched account for this filter
> concept
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-5291) Per-Query Limits (nodes read, nodes read in memory)
[
https://issues.apache.org/jira/browse/OAK-5291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-5291:
--
Fix Version/s: 1.14.0
> Per-Query Limits (nodes read, nodes read in memory)
> ---
>
> Key: OAK-5291
> URL: https://issues.apache.org/jira/browse/OAK-5291
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.12.0, 1.14.0
>
>
> In OAK-1395 we added limits for long running queries. In OAK-1571 we added
> OSGi configuration. In OAK-5237 we change the default settings.
> It would be nice to be able to define the limits per query, similar to
> OAK-4888. The query would look like (for example, to limit reading to 1
> million nodes, even if the default query limit is lower):
> {noformat}
> select * from [nt:base]
> where ischildnode('/oak:index')
> order by name()
> option(traversal ok, limit 100)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-6892) Query: ability to "nicely" traverse
[
https://issues.apache.org/jira/browse/OAK-6892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-6892:
--
Fix Version/s: 1.14.0
> Query: ability to "nicely" traverse
> ---
>
> Key: OAK-6892
> URL: https://issues.apache.org/jira/browse/OAK-6892
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.12.0, 1.14.0
>
>
> Currently, queries that traverse many nodes log a warning, or can even fail
> (if configured). This is to ensure system resources are not blocked (CPU,
> I/O, memory).
> But there are cases where it doesn't make sense to create an index, but
> traverse (a certain path structure, or sometimes even the whole repository).
> For example, finding a text with "like '%xxx%'". The problem isn't that it's
> slow; the problem is that it's blocking / slowing down other users. Another
> example is during migration, where the alternative is to create an index
> (which also traverses the repository).
> One option is to allow such queries to run, but throttle them. We could add
> the hint {{option(traversal throttle)}} to do that. Throttle means: don't use
> up all I/O, but yield to other tasks depending on config settings (during
> migration, yield is not needed). As a rule of thumb, the longer the query
> runs, the more should it yield (up to some value).
> It would be good to allow stopping such queries, and get progress
> information. The easiest solution might be over JMX, and a more advanced
> solution is using new API (like, using an interface QueryTraversalObserver,
> and have our QueryResult implement that interface).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-3437) Regression in org.apache.jackrabbit.core.query.JoinTest#testJoinWithOR5 when enabling OAK-1617
[
https://issues.apache.org/jira/browse/OAK-3437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-3437:
--
Fix Version/s: 1.14.0
> Regression in org.apache.jackrabbit.core.query.JoinTest#testJoinWithOR5 when
> enabling OAK-1617
> --
>
> Key: OAK-3437
> URL: https://issues.apache.org/jira/browse/OAK-3437
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: solr
>Reporter: Davide Giannella
>Assignee: Tommaso Teofili
>Priority: Major
> Fix For: 1.12.0, 1.14.0
>
>
> When enabling OAK-1617 (still to be committed) there's a regression in the
> {{oak-solr-core}} unit tests
> - {{org.apache.jackrabbit.core.query.JoinTest#testJoinWithOR3}}
> - {{org.apache.jackrabbit.core.query.JoinTest#testJoinWithOR4}}
> - {{org.apache.jackrabbit.core.query.JoinTest#testJoinWithOR5}}
> The WIP of the feature can be found in
> https://github.com/davidegiannella/jackrabbit-oak/tree/OAK-1617 and a full
> patch will be attached shortly for review in OAK-1617 itself.
> The feature is currently disabled, in order to enable it for unit testing an
> approach like this can be taken
> https://github.com/davidegiannella/jackrabbit-oak/blob/177df1a8073b1237857267e23d12a433e3d890a4/oak-core/src/test/java/org/apache/jackrabbit/oak/query/SQL2OptimiseQueryTest.java#L142
> or setting the system property {{-Doak.query.sql2optimisation}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7116) Use JMX mode to reindex on SegmentNodeStore without requiring manual steps
[ https://issues.apache.org/jira/browse/OAK-7116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7116: -- Fix Version/s: 1.14.0 > Use JMX mode to reindex on SegmentNodeStore without requiring manual steps > -- > > Key: OAK-7116 > URL: https://issues.apache.org/jira/browse/OAK-7116 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: run >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Major > Fix For: 1.12.0, 1.14.0 > > > oak-run indexing for SegmentNodeStore currently require following steps while > performing indexing against a repository which is in use [1] > # Create checkpoint via MBean and pass it as part of cli args > # Perform actual indexing with read only access to repo > # Import the index via MBean operation > As per current documented steps #1 and #3 are manual. This can potentially be > simplified by directly using JMX operation from within oak-run as currently > for accessing SegmentNodeStore oak-run needs to run on same host as actual > application > *JMX Access* > JMX access can be done via following ways > # Application using Oak has JMX remote > ## Enabled and same info provided as cli args > ## Not enabled - In such a case we can rely on > ### pid and [local > connection|https://stackoverflow.com/questions/13252914/how-to-connect-to-a-local-jmx-server-by-knowing-the-process-id] > or [attach|https://github.com/nickman/jmxlocal] > ### Or query all running java prcess jmx and check if SegmentNodeStore repo > path is same as one provided in cli > # Application using OAk > *Proposed Approach* > # Establish the JMX connection > # Create checkpoint using the JMX connection programatically > # Perform indexing with read only access > # Import the index via JMX access > With this indexing support for SegmentNodeStore would be at par with > DocumentNodeStore in terms of ease of use > [1] https://jackrabbit.apache.org/oak/docs/query/oak-run-indexing.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7691) Remove deprecated ValueFactoryImpl methods
[ https://issues.apache.org/jira/browse/OAK-7691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7691: -- Fix Version/s: 1.14.0 > Remove deprecated ValueFactoryImpl methods > -- > > Key: OAK-7691 > URL: https://issues.apache.org/jira/browse/OAK-7691 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: store-spi >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.12.0, 1.14.0 > > > The deprecated static methods on ValueFactoryImpl are not used anymore and > can be removed. See also OAK-7688. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-1838) NodeStore API: divergence in contract and implementations
[ https://issues.apache.org/jira/browse/OAK-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-1838: -- Fix Version/s: 1.14.0 > NodeStore API: divergence in contract and implementations > - > > Key: OAK-1838 > URL: https://issues.apache.org/jira/browse/OAK-1838 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: Michael Dürig >Assignee: Marcel Reutegger >Priority: Major > Fix For: 1.12.0, 1.14.0 > > > Currently there is a gap between what the API mandates and what the document > and kernel node stores implement. This hinders further evolution of the Oak > stack as implementers must always be aware of non explicit design > requirements. We should look into ways we could close this gap by bringing > implementation and specification closer towards each other. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6098) Build timeout
[
https://issues.apache.org/jira/browse/OAK-6098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-6098:
--
Fix Version/s: 1.14.0
> Build timeout
> -
>
> Key: OAK-6098
> URL: https://issues.apache.org/jira/browse/OAK-6098
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
>Priority: Major
> Labels: CI, jenkins, test-failure
> Fix For: 1.12.0, 1.14.0
>
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #175 has failed.
> First failed run: [Jackrabbit Oak
> #175|https://builds.apache.org/job/Jackrabbit%20Oak/175/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/175/console]
> This build timed out on node https://builds.apache.org/computer/H10. Usually
> the build takes around 40mins.
> {code}
> Build timed out (after 60 minutes). Marking the build as failed.
> {code}
> Also timed out on https://builds.apache.org/computer/cassandra5. See
> https://builds.apache.org/view/J/job/Jackrabbit%20Oak/208/
> Also timed out on https://builds.apache.org/computer/ubuntu-eu2. See
> https://builds.apache.org/job/Jackrabbit%20Oak/246/
> Also timed out on https://builds.apache.org/computer/ubuntu-2. See
> https://builds.apache.org/job/Jackrabbit%20Oak/267/
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-6619) Async indexer thread may get stuck in CopyOnWriteDirectory close method
[
https://issues.apache.org/jira/browse/OAK-6619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-6619:
--
Fix Version/s: 1.14.0
> Async indexer thread may get stuck in CopyOnWriteDirectory close method
> ---
>
> Key: OAK-6619
> URL: https://issues.apache.org/jira/browse/OAK-6619
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Critical
> Fix For: 1.12.0, 1.14.0
>
> Attachments: status-threaddump-Sep-5.txt
>
>
> With copy-on-write mode enabled at times its seen that async index thread
> remain stuck in CopyOnWriteDirectory#close method
> {noformat}
> "async-index-update-async" prio=5 tid=0xb9e63 nid=0x timed_waiting
>java.lang.Thread.State: TIMED_WAITING
> at sun.misc.Unsafe.park(Native Method)
> - waiting to lock <0x2504cd51> (a
> java.util.concurrent.CountDownLatch$Sync) owned by "null" tid=0x-1
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnWriteDirectory.close(CopyOnWriteDirectory.java:221)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.writer.DefaultIndexWriter.updateSuggester(DefaultIndexWriter.java:177)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.writer.DefaultIndexWriter.close(DefaultIndexWriter.java:121)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorContext.closeWriter(LuceneIndexEditorContext.java:136)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditor.leave(LuceneIndexEditor.java:154)
> at
> org.apache.jackrabbit.oak.plugins.index.IndexUpdate.leave(IndexUpdate.java:357)
> at
> org.apache.jackrabbit.oak.spi.commit.VisibleEditor.leave(VisibleEditor.java:60)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:56)
> at
> org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate.updateIndex(AsyncIndexUpdate.java:727)
> at
> org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate.runWhenPermitted(AsyncIndexUpdate.java:572)
> at
> org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate.run(AsyncIndexUpdate.java:431)
> - locked <0x3d542de5> (a
> org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate)
> at
> org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:245)
> at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> The thread is waiting on a latch and no other thread is going to release the
> latch.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7425) Add discovery mechanism for tooling implementations
[
https://issues.apache.org/jira/browse/OAK-7425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-7425:
--
Fix Version/s: 1.14.0
> Add discovery mechanism for tooling implementations
> ---
>
> Key: OAK-7425
> URL: https://issues.apache.org/jira/browse/OAK-7425
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Francesco Mari
>Assignee: Francesco Mari
>Priority: Major
> Labels: technical_debt
> Fix For: 1.12.0, 1.14.0
>
> Attachments: 001.patch
>
>
> This issue proposes an idea for discovering implementations of tooling for
> the Segment Store. Developing a tool for the Segment Store should include the
> following step.
> * The tool compiles against the {{NodeStore}} API and the API exposed through
> the oak-segment-tar-tool-api. In particular, the tool uses the
> {{ToolingSupportFactory}} and related interfaces to instantiate a NodeStore
> and, optionally, a {{NodeState}} for the proc tree.
> * The tool runs with an implementation-dependent uber-jar in the classpath.
> The uber-jar includes the {{ToolingSupportFactory}} API, its implementation,
> and every other class required for the implementation to work. No other JARs
> is required to use the {{ToolingSupportFactory}} API. The tool uses the
> Java's {{ServiceLoader}} to instantiate an implementation of
> {{ToolingSupportFactory}}. The uber-jar is the {{oak-segment-tar-tool}}
> module.
> The patch falls short of fully implementing the use case because
> {{oak-segment-tar-tool-api}} is not versioned independently from Oak. This
> can't happen at the moment because {{oak-store-spi}} and its dependencies are
> not independently versioned either. The workflow described above could still
> work, but only because the {{NodeStore}} and {{NodeState}} API are quite
> stable. A cleaner solution to dependency management is required in the long
> run.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7300) Lucene Index: per-column selectivity to improve cost estimation
[ https://issues.apache.org/jira/browse/OAK-7300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7300: -- Fix Version/s: 1.14.0 > Lucene Index: per-column selectivity to improve cost estimation > --- > > Key: OAK-7300 > URL: https://issues.apache.org/jira/browse/OAK-7300 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene, query >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Major > Fix For: 1.12.0, 1.14.0 > > > In OAK-6735 we have improved cost estimation for Lucene indexes, however the > following case is still not working as expected: a very common property is > indexes (many nodes have that property), and each value of that property is > more or less unique. In this case, currently the cost estimation is the total > number of documents that contain that property. Assuming the condition > "property is not null" this is correct, however for the common case "property > = x" the estimated cost is far too high. > A known workaround is to set the "costPerEntry" for the given index to a low > value, for example 0.2. However this isn't a good solution, as it affects all > properties and queries. > It would be good to be able to set the selectivity per property, for example > by specifying the number of distinct values, or (better yet) the average > number of entries for a given key (1 for unique values, 2 meaning for each > distinct values there are two documents on average). > That value can be set manually (cost override), and it can be set > automatically, e.g. when building the index, or updated from time to time > during the index update, using a cardinality > estimation algorithm. That doesn't have to be accurate; we could use an rough > approximation such as hyperbitbit. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-2727) NodeStateSolrServersObserver should be filtering path selectively
[ https://issues.apache.org/jira/browse/OAK-2727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-2727: -- Fix Version/s: 1.14.0 > NodeStateSolrServersObserver should be filtering path selectively > - > > Key: OAK-2727 > URL: https://issues.apache.org/jira/browse/OAK-2727 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: solr >Affects Versions: 1.1.8 >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili >Priority: Major > Labels: performance > Fix For: 1.12.0, 1.14.0 > > > As discussed in OAK-2718 it'd be good to be able to selectively find Solr > indexes by path, as done in Lucene index, see also OAK-2570. > This would avoid having to do full diffs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6762) Convert oak-blob to OSGi R6 annotations
[ https://issues.apache.org/jira/browse/OAK-6762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6762: -- Fix Version/s: 1.14.0 > Convert oak-blob to OSGi R6 annotations > --- > > Key: OAK-6762 > URL: https://issues.apache.org/jira/browse/OAK-6762 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: blob >Reporter: Robert Munteanu >Priority: Major > Fix For: 1.12.0, 1.14.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7321) Test failure: DocumentNodeStoreIT.modifiedResetWithDiff
[
https://issues.apache.org/jira/browse/OAK-7321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-7321:
--
Fix Version/s: 1.14.0
> Test failure: DocumentNodeStoreIT.modifiedResetWithDiff
> ---
>
> Key: OAK-7321
> URL: https://issues.apache.org/jira/browse/OAK-7321
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration, documentmk
>Reporter: Hudson
>Priority: Major
> Fix For: 1.12.0, 1.14.0
>
>
> No description is provided
> The build Jackrabbit Oak #1295 has failed.
> First failed run: [Jackrabbit Oak
> #1295|https://builds.apache.org/job/Jackrabbit%20Oak/1295/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/1295/console]
> {noformat}
> org.apache.jackrabbit.oak.plugins.document.DocumentStoreException: Configured
> cluster node id 1 already in use: machineId/instanceId do not match:
> mac:0242454078e1//home/jenkins/jenkins-slave/workspace/Jackrabbit
> Oak/oak-store-document !=
> mac:0242d5bcc8f8//home/jenkins/jenkins-slave/workspace/Jackrabbit
> Oak/oak-store-document
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreIT.modifiedResetWithDiff(DocumentNodeStoreIT.java:65)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-4581) Persistent local journal for more reliable event generation
[
https://issues.apache.org/jira/browse/OAK-4581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-4581:
--
Fix Version/s: 1.14.0
> Persistent local journal for more reliable event generation
> ---
>
> Key: OAK-4581
> URL: https://issues.apache.org/jira/browse/OAK-4581
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core
>Reporter: Chetan Mehrotra
>Priority: Major
> Labels: observation
> Fix For: 1.12.0, 1.14.0
>
> Attachments: OAK-4581.v0.patch
>
>
> As discussed in OAK-2683 "hitting the observation queue limit" has multiple
> drawbacks. Quite a bit of work is done to make diff generation faster.
> However there are still chances of event queue getting filled up.
> This issue is meant to implement a persistent event journal. Idea here being
> # NodeStore would push the diff into a persistent store via a synchronous
> observer
> # Observors which are meant to handle such events in async way (by virtue of
> being wrapped in BackgroundObserver) would instead pull the events from this
> persisted journal
> h3. A - What is persisted
> h4. 1 - Serialized Root States and CommitInfo
> In this approach we just persist the root states in serialized form.
> * DocumentNodeStore - This means storing the root revision vector
> * SegmentNodeStore - {color:red}Q1 - What does serialized form of
> SegmentNodeStore root state looks like{color} - Possible the RecordId of
> "root" state
> Note that with OAK-4528 DocumentNodeStore can rely on persisted remote
> journal to determine the affected paths. Which reduces the need for
> persisting complete diff locally.
> Event generation logic would then "deserialize" the persisted root states and
> then generate the diff as currently done via NodeState comparison
> h4. 2 - Serialized commit diff and CommitInfo
> In this approach we can save the diff in JSOP form. The diff only contains
> information about affected path. Similar to what is current being stored in
> DocumentNodeStore journal
> h4. CommitInfo
> The commit info would also need to be serialized. So it needs to be ensure
> whatever is stored there can be serialized or re calculated
> h3. B - How it is persisted
> h4. 1 - Use a secondary segment NodeStore
> OAK-4180 makes use of SegmentNodeStore as a secondary store for caching.
> [~mreutegg] suggested that for persisted local journal we can also utilize a
> SegmentNodeStore instance. Care needs to be taken for compaction. Either via
> generation approach or relying on online compaction
> h4. 2- Make use of write ahead log implementations
> [~ianeboston] suggested that we can make use of some write ahead log
> implementation like [1], [2] or [3]
> h3. C - How changes get pulled
> Some points to consider for event generation logic
> # Would need a way to keep pointers to journal entry on per listener basis.
> This would allow each Listener to "pull" content changes and generate diff as
> per its speed and keeping in memory overhead low
> # The journal should survive restarts
> [1] http://www.mapdb.org/javadoc/latest/mapdb/org/mapdb/WriteAheadLog.html
> [2]
> https://github.com/apache/activemq/tree/master/activemq-kahadb-store/src/main/java/org/apache/activemq/store/kahadb/disk/journal
> [3]
> https://github.com/elastic/elasticsearch/tree/master/core/src/main/java/org/elasticsearch/index/translog
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7328) Update DocumentNodeStore based OakFixture
[ https://issues.apache.org/jira/browse/OAK-7328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7328: -- Fix Version/s: 1.14.0 > Update DocumentNodeStore based OakFixture > - > > Key: OAK-7328 > URL: https://issues.apache.org/jira/browse/OAK-7328 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: run >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.12.0, 1.14.0 > > > The current OakFixtures using a DocumentNodeStore use a configuration / setup > which is different from what a default DocumentNodeStoreService would use. It > would be better if benchmarks run with a configuration close to a default > setup. The main differences identified are: > - Does not have a proper executor, which means some tasks are executed with > the same thread. > - Does not use a separate persistent cache for the journal (diff cache). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6759) Convert oak-blob-cloud-azure to OSGi R6 annotations
[ https://issues.apache.org/jira/browse/OAK-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6759: -- Fix Version/s: 1.14.0 > Convert oak-blob-cloud-azure to OSGi R6 annotations > --- > > Key: OAK-6759 > URL: https://issues.apache.org/jira/browse/OAK-6759 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: blob-cloud >Reporter: Robert Munteanu >Priority: Major > Fix For: 1.12.0, 1.14.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7412) Make oak-solr extend from oak-search
[ https://issues.apache.org/jira/browse/OAK-7412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7412: -- Fix Version/s: 1.14.0 > Make oak-solr extend from oak-search > > > Key: OAK-7412 > URL: https://issues.apache.org/jira/browse/OAK-7412 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: oak-search >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili >Priority: Major > Fix For: 1.12.0, 1.14.0 > > > Once Oak Search module is ready, Oak Solr should be refactored so that it > extends from oak-search SPIs. > Both implementation and extensive testing (regression, performance) should be > conducted to make sure nothing is lost during this transition. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6264) Test failure: IllegalArgumentException during upgrade tests
[
https://issues.apache.org/jira/browse/OAK-6264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-6264:
--
Fix Version/s: 1.14.0
> Test failure: IllegalArgumentException during upgrade tests
>
>
> Key: OAK-6264
> URL: https://issues.apache.org/jira/browse/OAK-6264
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration, upgrade
>Reporter: Hudson
>Priority: Major
> Labels: CI, jenkins, test-failure
> Fix For: 1.12.0, 1.14.0
>
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #338 has failed.
> First failed run: [Jackrabbit Oak
> #338|https://builds.apache.org/job/Jackrabbit%20Oak/338/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/338/console]
> {noformat}
> javax.jcr.RepositoryException: Failed to copy content
> Stacktrace
> java.lang.RuntimeException: javax.jcr.RepositoryException: Failed to copy
> content
> at
> org.apache.jackrabbit.oak.upgrade.CopyCheckpointsTest.prepare(CopyCheckpointsTest.java:141)
> Caused by: javax.jcr.RepositoryException: Failed to copy content
> at
> org.apache.jackrabbit.oak.upgrade.CopyCheckpointsTest.prepare(CopyCheckpointsTest.java:141)
> Caused by: java.lang.IllegalArgumentException
> at
> org.apache.jackrabbit.oak.upgrade.CopyCheckpointsTest.prepare(CopyCheckpointsTest.java:141)
> {noformat}
> This affects
> {noformat}
>
> org.apache.jackrabbit.oak.upgrade.CopyCheckpointsTest.validateMigration[Suppress
> the warning]
>
> org.apache.jackrabbit.oak.upgrade.CopyCheckpointsTest.validateMigration[Source
> data store defined, checkpoints migrated]
>
> org.apache.jackrabbit.oak.upgrade.IgnoreMissingBinariesTest.validateMigration
> org.apache.jackrabbit.oak.upgrade.UpgradeOldSegmentTest.upgradeFrom10
>
> org.apache.jackrabbit.oak.upgrade.cli.SegmentTarToSegmentTest.validateMigration
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToJdbcTest.validateMigration
>
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToSegmentTarTest.validateMigration
>
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToSegmentTarWithMissingDestinationDirectoryTest.validateMigration
>
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToSegmentTest.validateMigration
>
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToSegmentWithMissingDestinationDirectoryTest.validateMigration
>
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
> references, no blobstores defined, segment -> segment]
>
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
> references, no blobstores defined, segment-tar -> segment-tar]
>
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
> references, no blobstores defined, segment -> segment-tar]
>
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
> embedded to embedded, no blobstores defined]
>
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
> embedded to external, no blobstores defined]
>
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
> references, src blobstore defined]
>
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
> external to embedded, src blobstore defined]
>
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
> external to external, src blobstore defined]
> org.apache.jackrabbit.oak.upgrade.cli.blob.FbsToFbsTest.validateMigration
> org.apache.jackrabbit.oak.upgrade.cli.blob.FbsToFdsTest.validateMigration
> org.apache.jackrabbit.oak.upgrade.cli.blob.FdsToFbsTest.validateMigration
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-6408) Review package exports for o.a.j.oak.plugins.index.*
[ https://issues.apache.org/jira/browse/OAK-6408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6408: -- Fix Version/s: 1.14.0 > Review package exports for o.a.j.oak.plugins.index.* > > > Key: OAK-6408 > URL: https://issues.apache.org/jira/browse/OAK-6408 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, indexing >Reporter: angela >Priority: Major > Fix For: 1.12.0, 1.14.0 > > > while working on OAK-6304 and OAK-6355, i noticed that the > _o.a.j.oak.plugins.index.*_ contains both internal api/utilities and > implementation details which get equally exported (though without having any > package export version set). > in the light of the modularization effort, i would like to suggest that we > try to sort that out and separate the _public_ parts from implementation > details. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7256) Query: option to wait for indexes to be updated
[
https://issues.apache.org/jira/browse/OAK-7256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-7256:
--
Fix Version/s: 1.14.0
> Query: option to wait for indexes to be updated
> ---
>
> Key: OAK-7256
> URL: https://issues.apache.org/jira/browse/OAK-7256
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Minor
> Fix For: 1.12.0, 1.14.0
>
>
> Sometimes (rarely, but still) queries should include the very latest changes,
> even if the index is updated asynchronously. For example when running unit
> test: data is added, and then a query is run to check if the data is there.
> The problem with asynchronous indexes is, you don't know exactly how long you
> have to wait. Often the index is updated quickly, and sometimes it takes a
> few seconds.
> What about extending the query syntax as follows:
> Wait for all indexes (no matter which index is used for this query) - this
> would be used rarely, just for testing:
> {noformat}
> /jcr:root/*
> option(wait for all indexes timeout 60)
> {noformat}
> Wait for just those indexes (well, usually it's just one, but sometimes it's
> multiple) that are needed for the given query. This query could also be used
> in an application that strictly needs the very latest results, even for
> fulltext queries. The "timeout" would mean "wait at most 10 seconds, and if
> not up-to-date then throw an exeption", while "max 10" would mean "wait at
> most 10 seconds, but still run the query in any case".
> {noformat}
> /jcr:root/content//*[jcr:contains(., 'hello')]
> option(wait for indexes max 10)
> {noformat}
> The query would wait, and once the indexes are up-to-date, return the
> requested result.
> So the syntax is (both SQL-2 and XPath):
> {noformat}
> option(wait for [all] indexes
> { max | timeout }
> [, ] )
> {noformat}
> So other options can also be used (option traversal fail,...).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7043) Collect SegmentStore stats as part of status zip
[ https://issues.apache.org/jira/browse/OAK-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7043: -- Fix Version/s: 1.14.0 > Collect SegmentStore stats as part of status zip > > > Key: OAK-7043 > URL: https://issues.apache.org/jira/browse/OAK-7043 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: segment-tar >Reporter: Chetan Mehrotra >Priority: Major > Labels: monitoring, production > Fix For: 1.12.0, 1.14.0 > > > Many times while investigating issue we request customer to provide to size > of segmentstore and at times list of segmentstore directory. It would be > useful if there is an InventoryPrinter for SegmentStore which can include > * Size of segment store > * Listing of segment store directory > * Possibly tail of journal.log > * Possibly some stats/info from index files stored in tar files -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-3336) Abstract a full text index implementation to be extended by Lucene and Solr
[ https://issues.apache.org/jira/browse/OAK-3336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-3336: -- Fix Version/s: 1.14.0 > Abstract a full text index implementation to be extended by Lucene and Solr > --- > > Key: OAK-3336 > URL: https://issues.apache.org/jira/browse/OAK-3336 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene, query, solr >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili >Priority: Major > Fix For: 1.12.0, 1.14.0 > > > Current Lucene and Solr indexes implement quite a no. of features according > to their specific APIs, design and implementation. However in the long run, > while differences in APIs and implementations will / can of course stay, the > difference in design can make it hard to keep those features on par. > It'd be therefore nice to make it possible to abstract as much of design and > implementation bits as possible in an abstract full text implementation which > Lucene and Solr would extend according to their specifics. > An example advantage of this is that index time aggregation will be > implemented only once and therefore any bugfixes and improvements in that > area will be done in the abstract implementation rather than having to do > that in two places. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7457) "Covariant return type change detected" warnings with java10
[
https://issues.apache.org/jira/browse/OAK-7457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-7457:
--
Fix Version/s: 1.14.0
> "Covariant return type change detected" warnings with java10
>
>
> Key: OAK-7457
> URL: https://issues.apache.org/jira/browse/OAK-7457
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: documentmk, segment-tar
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
> Fix For: 1.12.0, 1.14.0
>
>
> We have quite a few warnings of type "Covariant return type change detected":
> {noformat}
> [INFO]
> C:\projects\apache\oak\trunk\oak-store-document\src\main\java\org\apache\jackrabbit\oak\plugins\document\persistentCache\broadcast\TCPBroadcaster.java:327:
> Covariant return type change detected: java.nio.Buffer
> java.nio.ByteBuffer.flip() has been changed to java.nio.ByteBuffer
> java.nio.ByteBuffer.flip()
> [INFO]
> C:\projects\apache\oak\trunk\oak-store-document\src\main\java\org\apache\jackrabbit\oak\plugins\document\persistentCache\broadcast\UDPBroadcaster.java:135:
> Covariant return type change detected: java.nio.Buffer
> java.nio.ByteBuffer.limit(int) has been changed to java.nio.ByteBuffer
> java.nio.ByteBuffer.limit(int)
> [INFO]
> C:\projects\apache\oak\trunk\oak-store-document\src\main\java\org\apache\jackrabbit\oak\plugins\document\persistentCache\broadcast\UDPBroadcaster.java:138:
> Covariant return type change detected: java.nio.Buffer
> java.nio.ByteBuffer.position(int) has been changed to java.nio.ByteBuffer
> java.nio.ByteBuffer.position(int)
> [INFO]
> C:\projects\apache\oak\trunk\oak-store-document\src\main\java\org\apache\jackrabbit\oak\plugins\document\persistentCache\broadcast\TCPBroadcaster.java:226:
> Covariant return type change detected: java.nio.Buffer
> java.nio.ByteBuffer.position(int) has been changed to java.nio.ByteBuffer
> java.nio.ByteBuffer.position(int)
> [INFO]
> C:\projects\apache\oak\trunk\oak-store-document\src\main\java\org\apache\jackrabbit\oak\plugins\document\persistentCache\broadcast\InMemoryBroadcaster.java:35:
> Covariant return type change detected: java.nio.Buffer
> java.nio.ByteBuffer.position(int) has been changed to java.nio.ByteBuffer
> java.nio.ByteBuffer.position(int)
> [INFO]
> C:\projects\apache\oak\trunk\oak-store-document\src\main\java\org\apache\jackrabbit\oak\plugins\document\persistentCache\PersistentCache.java:519:
> Covariant return type change detected: java.nio.Buffer
> java.nio.ByteBuffer.limit(int) has been changed to java.nio.ByteBuffer
> java.nio.ByteBuffer.limit(int)
> [INFO]
> C:\projects\apache\oak\trunk\oak-store-document\src\main\java\org\apache\jackrabbit\oak\plugins\document\persistentCache\PersistentCache.java:522:
> Covariant return type change detected: java.nio.Buffer
> java.nio.ByteBuffer.position(int) has been changed to java.nio.ByteBuffer
> java.nio.ByteBuffer.position(int)
> [INFO]
> C:\projects\apache\oak\trunk\oak-store-document\src\main\java\org\apache\jackrabbit\oak\plugins\document\persistentCache\PersistentCache.java:535:
> Covariant return type change detected: java.nio.Buffer
> java.nio.ByteBuffer.position(int) has been changed to java.nio.ByteBuffer
> java.nio.ByteBuffer.position(int)
> [INFO]
> C:\projects\apache\oak\trunk\oak-segment-tar\src\main\java\org\apache\jackrabbit\oak\segment\data\SegmentDataV12.java:196:
> Covariant return type change detected: java.nio.Buffer
> java.nio.ByteBuffer.position(int) has been changed to java.nio.ByteBuffer
> java.nio.ByteBuffer.position(int)
> [INFO]
> C:\projects\apache\oak\trunk\oak-segment-tar\src\main\java\org\apache\jackrabbit\oak\segment\data\SegmentDataV12.java:197:
> Covariant return type change detected: java.nio.Buffer
> java.nio.ByteBuffer.limit(int) has been changed to java.nio.ByteBuffer
> java.nio.ByteBuffer.limit(int)
> [INFO]
> C:\projects\apache\oak\trunk\oak-segment-tar\src\main\java\org\apache\jackrabbit\oak\segment\data\SegmentDataUtils.java:57:
> Covariant return type change detected: java.nio.Buffer
> java.nio.ByteBuffer.position(int) has been changed to java.nio.ByteBuffer
> java.nio.ByteBuffer.position(int)
> [INFO]
> C:\projects\apache\oak\trunk\oak-segment-tar\src\main\java\org\apache\jackrabbit\oak\segment\data\SegmentDataUtils.java:58:
> Covariant return type change detected: java.nio.Buffer
> java.nio.ByteBuffer.limit(int) has been changed to java.nio.ByteBuffer
> java.nio.ByteBuffer.limit(int)
> [INFO]
> C:\projects\apache\oak\trunk\oak-segment-tar\src\main\java\org\apache\jackrabbit\oak\segment\file\tar\index\IndexWriter.java:110:
> Covariant return type change detected: java.nio.Buffer
> java.nio.ByteBuffer.position(int) has been changed to java.nio.ByteBuffer
> java.nio.ByteBuf
[jira] [Updated] (OAK-7922) Improve the operations and the reporting of the check command
[
https://issues.apache.org/jira/browse/OAK-7922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-7922:
--
Fix Version/s: 1.14.0
> Improve the operations and the reporting of the check command
> -
>
> Key: OAK-7922
> URL: https://issues.apache.org/jira/browse/OAK-7922
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Francesco Mari
>Assignee: Francesco Mari
>Priority: Major
> Fix For: 1.12.0, 1.14.0
>
> Attachments: OAK-7922-01.patch
>
>
> The check command allows a user to check for both the head and the
> checkpoints. At the end of the execution the command outputs the consistent
> revisions for the head and the individual checkpoints, if any is found.
> Moreover, it prints an overall good revision. The consistent revisions for
> the head and the checkpoints could all be different. If both the head and all
> the checkpoints are assigned to a consistent revision, the overall good
> revision is the oldest of those revisions.
> I wonder how useful all of this information is to a user of the command:
> - I might have a revision where a checkpoint is consistent, but the head is
> not. In this case, I don't want to revert to that revision because my system
> will probably be unstable due to the inconsistent head.
> - The overall good revision might still be partially inconsistent due to the
> way the command short-circuits the consistency check on the head and the
> checkpoints. If I revert to the overall good revision, the head might still
> be inconsistent or one of the checkpoints might be missing.
> I propose to remove the {{\--checkpoints}} and the {{\--head}} flags and
> define the behaviour of the command as follows.
> - The check command checks one super-root at a time in its entirety (both
> head and referenced checkpoints).
> - The command exits as soon as a super-root is found where both the head and
> all the checkpoints are consistent.
> - While searching, the command might find a super-root with a consistent
> head but one or more inconsistent checkpoint. In this case, the first of such
> revisions is printed, specifying which checkpoints are inconsistent.
> - The user might specify a {{--no-checkpoints}} flag to skip checking the
> checkpoints in the steps above.
> The optimisations currently implemented by the check command can be
> maintained. We don't need to fully traverse the head or the checkpoints if a
> well-known corrupted path is still corrupted in the current iteration. The
> approach proposed above enables additional optimisations:
> - Since checkpoints are immutable, the command doesn't need to traverse a
> checkpoint that was inspected before. This is true regardless of the
> consistency of the checkpoint.
> - If a super-root includes a checkpoint that was previously determined
> corrupted, the command can skip that super-root without further inspection.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7634) Repository migration docs should include info on TAR <-> Azure sidegrade
[ https://issues.apache.org/jira/browse/OAK-7634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7634: -- Fix Version/s: 1.14.0 > Repository migration docs should include info on TAR <-> Azure sidegrade > > > Key: OAK-7634 > URL: https://issues.apache.org/jira/browse/OAK-7634 > Project: Jackrabbit Oak > Issue Type: Documentation > Components: doc, segment-tar >Reporter: Andrei Dulceanu >Assignee: Andrei Dulceanu >Priority: Minor > Fix For: 1.12.0, 1.14.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-5544) Improve indexing resilience
[ https://issues.apache.org/jira/browse/OAK-5544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-5544: -- Fix Version/s: 1.14.0 > Improve indexing resilience > --- > > Key: OAK-5544 > URL: https://issues.apache.org/jira/browse/OAK-5544 > Project: Jackrabbit Oak > Issue Type: Epic > Components: lucene >Reporter: Alexander Saar >Assignee: Chetan Mehrotra >Priority: Critical > Labels: resilience > Fix For: 1.12.0, 1.14.0 > > > grouping the improvements for indexer resilience in this issue for easier > tracking -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6774) Convert oak-upgrade to OSGi R6 annotations
[ https://issues.apache.org/jira/browse/OAK-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6774: -- Fix Version/s: 1.14.0 > Convert oak-upgrade to OSGi R6 annotations > -- > > Key: OAK-6774 > URL: https://issues.apache.org/jira/browse/OAK-6774 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: upgrade >Reporter: Robert Munteanu >Priority: Major > Fix For: 1.12.0, 1.14.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-3380) Property index pruning should happen asynchronously
[ https://issues.apache.org/jira/browse/OAK-3380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-3380: -- Fix Version/s: 1.14.0 > Property index pruning should happen asynchronously > --- > > Key: OAK-3380 > URL: https://issues.apache.org/jira/browse/OAK-3380 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: property-index >Affects Versions: 1.3.5 >Reporter: Vikas Saurabh >Priority: Minor > Labels: resilience > Fix For: 1.12.0, 1.14.0 > > > Following up on this (a relatively old) thread \[1], we should do pruning of > property index structure asynchronously. The thread was never concluded.. > here are a couple of ideas picked from the thread: > * Move pruning to an async thread > * Throttle pruning i.e. prune only once in a while > ** I'm not sure how that would work though -- an unpruned part would remain > as is until another index happens on that path. > Once we can move pruning to some async thread (reducing concurrent updates), > OAK-2673 + OAK-2929 can take care of add-add conflicts. > > h6. Why is this an issue despite merge retries taking care of it? > A couple of cases which have concurrent updates hitting merge conflicts in > our product (Adobe AEM): > * Some index are very volatile (in the sense that indexed property switches > its values very quickly) e.g. sling job status, AEM workflow status. > * Multiple threads take care of jobs. Although sling maintains a bucketed > structure for job storage to reduce conflicts... but inside index tree the > bucket structure, at times, gets pruned and needs to be created in the next > job status change > While retries do take care of these conflict a lot of times and even when > they don't, AEM workflows has it's own retry to work around. But, retrying, > IMHO, is just a waste of time -- more importantly in paths where application > doesn't really have a control. > h6. Would this add to cost of traversing index structure? > Yes, there'd be some left over paths in index structure between asynchronous > prunes. But, I think the cost of such wasted traversals would be covered up > with time saved in avoiding the concurrent update conflict. > > (cc [~tmueller], [~mreutegg], [~alex.parvulescu], [~chetanm]) > \[1]: > http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201506.mbox/%3ccadichf66u2vh-hlrjunansytxfidj2mt3vktr4ybkngpzy9...@mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7423) Document the proc tree
[ https://issues.apache.org/jira/browse/OAK-7423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7423: -- Fix Version/s: 1.14.0 > Document the proc tree > -- > > Key: OAK-7423 > URL: https://issues.apache.org/jira/browse/OAK-7423 > Project: Jackrabbit Oak > Issue Type: Documentation > Components: segment-tar >Reporter: Francesco Mari >Assignee: Francesco Mari >Priority: Major > Labels: technical_debt > Fix For: 1.12.0, 1.14.0 > > > The proc tree, contributed in OAK-7416, lacks Javadoc and high-level > documentation. In particular, the exposed content structure should be > described in greater detail. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6513) Journal based Async Indexer
[
https://issues.apache.org/jira/browse/OAK-6513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-6513:
--
Fix Version/s: 1.14.0
> Journal based Async Indexer
> ---
>
> Key: OAK-6513
> URL: https://issues.apache.org/jira/browse/OAK-6513
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: indexing
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Major
> Fix For: 1.12.0, 1.14.0
>
>
> Current async indexer design is based on NodeState diff. This has served us
> fine so far however off late it is not able to perform well if rate of
> repository writes is high. When changes happen faster than index-update can
> process them, larger and larger diffs will happen. These make index-updates
> slower, which again lead to the next diff being ever larger than the one
> before (assuming a constant ingestion rate).
> In current diff based flow the indexer performs complete diff for all changes
> happening between 2 cycle. It may happen that lots of writes happens but not
> much indexable content is written. So doing diff there is a wasted effort.
> In 1.6 release for NRT Indexing we implemented a journal based indexing for
> external changes(OAK-4808, OAK-5430). That approach can be generalized and
> used for async indexing.
> Before talking about the journal based approach lets see how IndexEditor work
> currently
> h4. IndexEditor
> Currently any IndexEditor performs 2 tasks
> # Identify which node is to be indexed based on some index definition. The
> Editor gets invoked as part of content diff where it determines which
> NodeState is to be indexed
> # Update the index based on node to be indexed
> For e.g. in oak-lucene we have LuceneIndexEditor which identifies the
> NodeStates to be indexed and LuceneDocumentMaker which constructs the Lucene
> Document from NodeState to be indexed. For journal based approach we can
> decouple these 2 parts and thus have
> * IndexEditor - Identifies which all paths need to be indexed for given index
> definition
> * IndexUpdater - Updates the index based on given NodeState and its path
> h4. High Level Flow
> # Session Commit Flow
> ## Each index type would provide a IndexEditor which would be invoked as part
> of commit (like sync indexes). These IndexEditor would just determine which
> paths needs to be indexed.
> ## As part of commit the paths to be indexed would be written to journal.
> # AsyncIndexUpdate flow
> ## AsyncIndexUpdate would query this journal to fetch all such indexed paths
> between the 2 checkpoints
> ## Based on the index path data it would invoke the {{IndexUpdater}} to
> update the index for that path
> ## Merge the index updates
> h4. Benefits
> Such a design would have following impact
> # More work done as part of write
> # Marking of indexable content is distributed hence at indexing time lesser
> work to be done
> # Indexing can progress in batches
> # The indexers can be called in parallel
> h4. Journal Implementation
> DocumentNodeStore currently has an in built journal which is being used for
> NRT Indexing. That feature can be exposed as an api.
> For scaling index this design is mostly required for cluster case. So we can
> possibly have both indexing support implemented and use the journal based
> support for DocumentNodeStore setups. Or we can look into implementing such a
> journal for SegmentNodeStore setups also
> h4. Open Points
> * Journal support in SegmentNodeStore
> * Handling deletes.
> Detailed proposal -
> https://wiki.apache.org/jackrabbit/Journal%20based%20Async%20Indexer
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-6911) Provide a way to tune inline size while storing binaries
[ https://issues.apache.org/jira/browse/OAK-6911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6911: -- Fix Version/s: 1.14.0 > Provide a way to tune inline size while storing binaries > > > Key: OAK-6911 > URL: https://issues.apache.org/jira/browse/OAK-6911 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar >Reporter: Chetan Mehrotra >Priority: Major > Labels: performance, scalability > Fix For: 1.12.0, 1.14.0 > > > SegmentNodeStore currently inlines binaries of size less that 16KB > (Segment.MEDIUM_LIMIT) even if external BlobStore is configured. > Due to this behaviour quite a bit of segment tar storage consist of blob > data. In one setup out of 370 GB segmentstore size 290GB is due to inlined > binary. If most of this binary content is moved to BlobStore then it would > allow same repository to work better in lesser RAM > So it would be useful if some way is provided to disable this default > behaviour and let BlobStore take control of inline size i.e. in presence of > BlobStore no inlining is attempted by SegmentWriter. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6366) Detect unsupported combination of read and write concern
[ https://issues.apache.org/jira/browse/OAK-6366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6366: -- Fix Version/s: 1.14.0 > Detect unsupported combination of read and write concern > > > Key: OAK-6366 > URL: https://issues.apache.org/jira/browse/OAK-6366 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk >Reporter: Marcel Reutegger >Priority: Minor > Fix For: 1.12.0, 1.14.0 > > > With OAK-4069 Oak will try to use a majority read concern when connected to a > replica set. The implementation should be more careful when setting a > majority read concern automatically and take the write concern into account. > It is currently possible to end up with a system that has a user configured > write concern of 1 and a majority read concern. This results in a > non-functional system and should be prevented. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7207) Define porcelain and plumbing tools for the Segment Store
[ https://issues.apache.org/jira/browse/OAK-7207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7207: -- Fix Version/s: 1.14.0 > Define porcelain and plumbing tools for the Segment Store > - > > Key: OAK-7207 > URL: https://issues.apache.org/jira/browse/OAK-7207 > Project: Jackrabbit Oak > Issue Type: Wish > Components: segment-tar >Reporter: Francesco Mari >Priority: Major > Labels: production, tooling > Fix For: 1.12.0, 1.14.0 > > > In a spirit similar to > [Git|https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain]'s, > it would be beneficial to create porcelain and plumbing tooling for the > Segment Store. > Plumbing tools expose lower level operations on the Segment Store. Knowledge > about the internals of the Segment Store is necessary to understand how > plumbing tools work. Plumbing tools communicate via a command line interface. > It must be easy to invoke plumbing tools from other tools (possibly by > shelling out). The output of plumbing tools must be easy to consume > programmatically. > Porcelain tools are written for human consumption. Their interface must be > user-friendly and should be as much as possible backwards compatible. > Porcelain tools use plumbing ones to implement their features. It should be > possible to use the same porcelain tools with different versions of the > plumbing tools, as long as the plumbing tools "speak" through an interface > that remain sufficiently compatible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7390) QueryResult.getSize() can be slow for many "or" or "union" conditions
[ https://issues.apache.org/jira/browse/OAK-7390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7390: -- Fix Version/s: 1.14.0 > QueryResult.getSize() can be slow for many "or" or "union" conditions > - > > Key: OAK-7390 > URL: https://issues.apache.org/jira/browse/OAK-7390 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Major > Fix For: 1.12.0, 1.14.0 > > > For queries with many union conditions, the "fast" getSize method can > actually be slower than iterating over the result. > The reason is, the number of index calls grows exponential with regards to > number of subqueries: (3x + x^2) / 2, where x is the number of subqueries. > For this to have a measurable affect, the number of subqueries needs to be > large (more than 100), and the index needs to be slow. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-5889) Change internal queries to use "option(traversal fail)"
[ https://issues.apache.org/jira/browse/OAK-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-5889: -- Fix Version/s: 1.14.0 > Change internal queries to use "option(traversal fail)" > --- > > Key: OAK-5889 > URL: https://issues.apache.org/jira/browse/OAK-5889 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Major > Fix For: 1.12.0, 1.14.0 > > > The Oak internal queries that use an index (that is, hopefully all of them) > should fail if no index is available. For example, it's better to fail > queries that search a node by UUID, if the UUID index is disabled, otherwise > for each such query, the complete repository is traversed. > To do that, "option(traversal fail)" can be appended to the query. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7725) Allow to have the users and groups created in the immutable part of the composite setup
[ https://issues.apache.org/jira/browse/OAK-7725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7725: -- Fix Version/s: 1.14.0 > Allow to have the users and groups created in the immutable part of the > composite setup > --- > > Key: OAK-7725 > URL: https://issues.apache.org/jira/browse/OAK-7725 > Project: Jackrabbit Oak > Issue Type: Story > Components: composite, security >Reporter: Tomek Rękawek >Assignee: Tomek Rękawek >Priority: Major > Fix For: 1.12.0, 1.14.0 > > Attachments: OAK-7725-tests.patch > > > When running the Oak with Composite Node Store, the /home subtree is always > stored in the mutable, global part. Therefore, even if we switch the > immutable part (eg. /libs), the users and groups are not affected. > This setup makes sense for the users and groups created interactively. > However, we also have the service users, which usually are not created > interactively, but are part of the application and therefore are related to > the /libs part. For such users, it'd make sense to include them dynamically, > together with the application, read-only mount. > The proposal is to allow some part of the /home (eg. /home/service) to be > mounted from the read-only partial node store. Let's consider the constraints > we need to put in place (eg. it shouldn't be possible to have inter-mounts > group memberships) and how we can implement this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-5661) Make NRT indexing resilient against unbounded growth
[ https://issues.apache.org/jira/browse/OAK-5661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-5661: -- Fix Version/s: 1.14.0 > Make NRT indexing resilient against unbounded growth > > > Key: OAK-5661 > URL: https://issues.apache.org/jira/browse/OAK-5661 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Major > Fix For: 1.12.0, 1.14.0 > > > NRT Indexes for volatile indexes [1] can grow large if async index update > faces issues. Like if it gets stuck for days or due to some bug index do not > get updates like in OAK-5649 then the sizes can grow very large. > For such cases we should add some checks in logic where system can ensure > that some cleanup is performed or writes to indexes are stopped. Also such a > situation should be flagged > [1] Indexes which see lots of addition and deletions. So effective indexing > size is smaller however if deletions are not applied (as is the case with > NRT) such indexes can grow large -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6765) Convert oak-jcr to OSGi R6 annotations
[ https://issues.apache.org/jira/browse/OAK-6765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6765: -- Fix Version/s: 1.14.0 > Convert oak-jcr to OSGi R6 annotations > -- > > Key: OAK-6765 > URL: https://issues.apache.org/jira/browse/OAK-6765 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: jcr >Reporter: Robert Munteanu >Priority: Major > Fix For: 1.12.0, 1.14.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-2976) Oak percolator
[ https://issues.apache.org/jira/browse/OAK-2976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-2976: -- Fix Version/s: 1.14.0 > Oak percolator > -- > > Key: OAK-2976 > URL: https://issues.apache.org/jira/browse/OAK-2976 > Project: Jackrabbit Oak > Issue Type: Task > Components: query >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili >Priority: Major > Fix For: 1.12.0, 1.14.0 > > > Inspired by [Elasticsearch > percolator|https://www.elastic.co/guide/en/elasticsearch/reference/current/search-percolate.html] > we may implement an Oak percolator that would basically store queries and > perform specific tasks upon indexing of documents matching those queries. > The reasons for possibly having that are that such a mechanism could be used > to run common but slow queries automatically whenever batches of matching > documents get indexed, to eventually warm up the underlying indexes caches. > Also such a percolator could be used as a notification mechanism (alerting, > monitoring). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6303) Cache in CachingBlobStore might grow beyond configured limit
[
https://issues.apache.org/jira/browse/OAK-6303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-6303:
--
Fix Version/s: 1.14.0
> Cache in CachingBlobStore might grow beyond configured limit
>
>
> Key: OAK-6303
> URL: https://issues.apache.org/jira/browse/OAK-6303
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: blob, core
>Reporter: Julian Reschke
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.12.0, 1.14.0
>
> Attachments: OAK-6303-test.diff, OAK-6303.diff
>
>
> It appears that depending on actual cache entry sizes, the {{CacheLIRS}}
> might grow beyond the configured limit.
> For {{RDBBlobStore}}, the limit is currently configured to 16MB, yet storing
> random 2M entries appears to fill the cache with 64MB of data (according to
> it's own stats).
> The attached test case reproduces this.
> (it seems this is caused by the fact that each of the 16 segments of the
> cache can hold 2 entries, no matter how big they are...)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-6758) Convert oak-authorization-cug to OSGi R6 annotations
[ https://issues.apache.org/jira/browse/OAK-6758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6758: -- Fix Version/s: 1.14.0 > Convert oak-authorization-cug to OSGi R6 annotations > > > Key: OAK-6758 > URL: https://issues.apache.org/jira/browse/OAK-6758 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: authorization-cug >Reporter: Robert Munteanu >Priority: Major > Fix For: 1.12.0, 1.14.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-5792) TarMK: Implement tooling to repair broken nodes
[
https://issues.apache.org/jira/browse/OAK-5792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-5792:
--
Fix Version/s: 1.14.0
> TarMK: Implement tooling to repair broken nodes
> ---
>
> Key: OAK-5792
> URL: https://issues.apache.org/jira/browse/OAK-5792
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: run, segment-tar
>Reporter: Michael Dürig
>Assignee: Andrei Dulceanu
>Priority: Major
> Labels: production, technical_debt, tooling
> Fix For: 1.12.0, 1.14.0
>
>
> With {{oak-run check}} we can determine the last good revision of a
> repository and use it to manually roll back a corrupted segment store.
> Complementary to this we should implement a tool to roll forward a broken
> revision to a fixed new revision. Such a tool needs to detect which items are
> affected by a corruption and replace these items with markers. With this the
> repository could brought back online and the markers could be used to
> identify the locations in the tree where further manual action might be
> needed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7635) oak-run check should support Azure Segment Store
[
https://issues.apache.org/jira/browse/OAK-7635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-7635:
--
Fix Version/s: 1.14.0
> oak-run check should support Azure Segment Store
>
>
> Key: OAK-7635
> URL: https://issues.apache.org/jira/browse/OAK-7635
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: run, segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
> Labels: tooling
> Fix For: 1.12.0, 1.14.0
>
>
> {{oak-run check}} should accept Azure URIs for the segment store in order to
> be able to check for data integrity. This will come handy in the light of
> remote compacted segment stores and/or sidegraded remote segment stores (see
> OAK-7623, OAK-7459).
> The Azure URI will be taken as argument and will have the following format:
> {{az:[https://myaccount.blob.core.windows.net/container/repo]}}, where _az_
> identifies the cloud provider. The last missing piece is the secret key which
> will be supplied as an environment variable, i.e. _AZURE_SECRET_KEY._
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7381) Reduce debug log output for queries
[ https://issues.apache.org/jira/browse/OAK-7381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7381: -- Fix Version/s: 1.14.0 > Reduce debug log output for queries > --- > > Key: OAK-7381 > URL: https://issues.apache.org/jira/browse/OAK-7381 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Major > Fix For: 1.12.0, 1.14.0 > > > When enabling the debug log level, running a query can log a lot. That can > slow down executing a large query quite a lot. The amount of logged data > should be reduced. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6805) Support read-only flag to disable any internal write in DataStore
[ https://issues.apache.org/jira/browse/OAK-6805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6805: -- Fix Version/s: 1.14.0 > Support read-only flag to disable any internal write in DataStore > - > > Key: OAK-6805 > URL: https://issues.apache.org/jira/browse/OAK-6805 > Project: Jackrabbit Oak > Issue Type: Task > Components: blob-plugins >Reporter: Amit Jain >Assignee: Amit Jain >Priority: Major > Fix For: 1.12.0, 1.14.0 > > > There should be support for a read-only flag to disable any internal writes > that happen in case the BlobStore has been initialized as read-only. > Some example of internal write can be reference.key which is written as > introduced for S3/Azure in OAK-6802 and already existing for FileDataStore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6764) Convert oak-exercise to OSGi R6 annotations
[ https://issues.apache.org/jira/browse/OAK-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6764: -- Fix Version/s: 1.14.0 > Convert oak-exercise to OSGi R6 annotations > --- > > Key: OAK-6764 > URL: https://issues.apache.org/jira/browse/OAK-6764 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: exercise >Reporter: Robert Munteanu >Priority: Major > Fix For: 1.12.0, 1.14.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6947) Add package export versions for oak-store-spi
[ https://issues.apache.org/jira/browse/OAK-6947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6947: -- Fix Version/s: 1.14.0 > Add package export versions for oak-store-spi > - > > Key: OAK-6947 > URL: https://issues.apache.org/jira/browse/OAK-6947 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: store-spi >Reporter: angela >Assignee: Michael Dürig >Priority: Major > Fix For: 1.12.0, 1.14.0 > > Attachments: OAK-6947.patch > > > [~mduerig], [~mreutegg], [~frm], [~stillalex], do you have any strong > preferences wrt to the packages we placed in the _oak-store-spi_ module? > Currently we explicitly export all packages and I think it would make sense > to enable the baseline plugin for these packages. > Any objection from your side? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-5588) Improve Session stats.
[ https://issues.apache.org/jira/browse/OAK-5588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-5588: -- Fix Version/s: 1.14.0 > Improve Session stats. > -- > > Key: OAK-5588 > URL: https://issues.apache.org/jira/browse/OAK-5588 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: Ian Boston >Priority: Major > Labels: monitoring, production > Fix For: 1.12.0, 1.14.0 > > > Currently each session has a SessionsStats MBean. Omongst other things it > records the total number or refresh operations. It also records the rate of > refresh operations, although this number in its current form is not usefull > as the rate is the number of refresh operations/session lifetime. It would > be much better to have a set of stats related to classes of users that > recorded proper metrics in a consistent way. eg 1 metric set per > service-user, 1 for the admin user and perhaps 1 for all normal users. Each > would record m1,m5,m15 rates, total count, p50,p75,p95,p99,p999 durations > with mean and stdev then 2 sets of metrics could be compared and monitored > without having to look at the code to work out how the metric was calculated. > Oak has metrics support to do this, minimal code would be required. > I dont think it would be viable to have 1 metric per unique session (too much > overhead, too much data, good for devs but bad for production), and in fact > having 1 JMX MBean per unique session is likely to cause problems with > everything connected to JMX even the ManagementServer can cope. Same goes for > the other proliferation of MBeans in the Oak 1.6. Perhaps a review of JMX in > Oak is due. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6288) Test failure: upgrade tests failing: Failed to copy content
[
https://issues.apache.org/jira/browse/OAK-6288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-6288:
--
Fix Version/s: 1.14.0
> Test failure: upgrade tests failing: Failed to copy content
> ---
>
> Key: OAK-6288
> URL: https://issues.apache.org/jira/browse/OAK-6288
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration, upgrade
>Reporter: Hudson
>Priority: Major
> Labels: CI, jenkins, test-failure
> Fix For: 1.12.0, 1.14.0
>
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #364 has failed.
> First failed run: [Jackrabbit Oak
> #364|https://builds.apache.org/job/Jackrabbit%20Oak/364/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/364/console]
> Failing tests:
> {noformat}
>
> org.apache.jackrabbit.oak.upgrade.CopyCheckpointsTest.validateMigration[Suppress
> the warning]
>
> org.apache.jackrabbit.oak.upgrade.CopyCheckpointsTest.validateMigration[Source
> data store defined, checkpoints migrated]
>
> org.apache.jackrabbit.oak.upgrade.IgnoreMissingBinariesTest.validateMigration
> org.apache.jackrabbit.oak.upgrade.UpgradeOldSegmentTest.upgradeFrom10
>
> org.apache.jackrabbit.oak.upgrade.cli.SegmentTarToSegmentTest.validateMigration
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToJdbcTest.validateMigration
>
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToSegmentTarTest.validateMigration
>
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToSegmentTarWithMissingDestinationDirectoryTest.validateMigration
>
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToSegmentTest.validateMigration
>
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToSegmentWithMissingDestinationDirectoryTest.validateMigration
>
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
> references, no blobstores defined, segment -> segment]
>
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
> references, no blobstores defined, segment-tar -> segment-tar]
>
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
> references, no blobstores defined, segment -> segment-tar]
>
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
> embedded to embedded, no blobstores defined]
>
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
> embedded to external, no blobstores defined]
>
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
> references, src blobstore defined]
>
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
> external to embedded, src blobstore defined]
>
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
> external to external, src blobstore defined]
> org.apache.jackrabbit.oak.upgrade.cli.blob.FbsToFbsTest.validateMigration
> org.apache.jackrabbit.oak.upgrade.cli.blob.FbsToFdsTest.validateMigration
> org.apache.jackrabbit.oak.upgrade.cli.blob.FdsToFbsTest.validateMigration
> {noformat}
> All seem to fail with
> {noformat}
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.737
> s <<< FAILURE! - in
> org.apache.jackrabbit.oak.upgrade.cli.SegmentTarToSegmentTest
> [ERROR]
> validateMigration(org.apache.jackrabbit.oak.upgrade.cli.SegmentTarToSegmentTest)
> Time elapsed: 3.73 s <<< ERROR!
> java.lang.RuntimeException: javax.jcr.RepositoryException: Failed to copy
> content
> Caused by: javax.jcr.RepositoryException: Failed to copy content
> Caused by: java.lang.IllegalArgumentException
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-6346) Set baseline plugin comparison for trunk to latest stable version
[ https://issues.apache.org/jira/browse/OAK-6346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6346: -- Fix Version/s: 1.14.0 > Set baseline plugin comparison for trunk to latest stable version > - > > Key: OAK-6346 > URL: https://issues.apache.org/jira/browse/OAK-6346 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Major > Fix For: 1.12.0, 1.14.0 > > Attachments: OAK-6346-v1.patch, release-process-v1.patch > > > The purpose of baseline plugin is to ensure that any change in api get > reflected in exported version of the package. Currently the baseline plugin > compares against the immediate previous version. > This causes issue with unstable branches where new features are being > implemented and which evolve over few minor release on the trunk. In such > cases its possible that a new method expose in 1.7.1 gets removed later in > 1.7.2 (as happened in OAK-6337). > It would be better to configure baseline plugin to check against releases > from stable branch so that we can ensure that package versions are properly > aligned against stable versions -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6897) XPath query: option to _not_ convert "or" to "union"
[ https://issues.apache.org/jira/browse/OAK-6897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6897: -- Fix Version/s: 1.14.0 > XPath query: option to _not_ convert "or" to "union" > > > Key: OAK-6897 > URL: https://issues.apache.org/jira/browse/OAK-6897 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Trivial > Fix For: 1.12.0, 1.14.0 > > > Right now, all XPath queries that contain "or" of the form "@a=1 or @b=2" are > converted to SQL-2 "union". In some cases, this is a problem, specially in > combination with "order by @jcr:score desc". > Now that SQL-2 "or" conditions can be converted to union (depending if union > has a lower cost), it is no longer strictly needed to do the union conversion > in the XPath conversion. Or at least emit different SQL-2 queries and take > the one with the lowest cost. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6919) SegmentCache might introduce unwanted memory references to SegmentId instances
[
https://issues.apache.org/jira/browse/OAK-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-6919:
--
Fix Version/s: 1.14.0
> SegmentCache might introduce unwanted memory references to SegmentId instances
> --
>
> Key: OAK-6919
> URL: https://issues.apache.org/jira/browse/OAK-6919
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Francesco Mari
>Assignee: Francesco Mari
>Priority: Major
> Fix For: 1.12.0, 1.14.0
>
>
> {{SegmentCache}} contains, through the underlying Guava cache, hard
> references to both {{SegmentId}} and {{Segment}} instances. Thus,
> {{SegmentCache}} contributes to the computation of in-memory references that,
> in turn, constitute the root references of the garbage collection algorithm.
> Further investigations are needed to assess this statement but, if
> {{SegmentCache}} is proved to be problematic, there are some possible
> solutions.
> For example, {{SegmentCache}} might be reworked to store references to
> MSB/LSB pairs as keys, instead of to {{SegmentId}} instances. Moreover,
> instead of referencing {{Segment}} instances as values, {{SegmentCache}}
> might hold references to their underlying {{ByteBuffer}}. With these changes
> in place, {{SegmentCache}} would not interfere with {{SegmentTracker}} and
> the garbage collection algorithm.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-6421) Phase out JCR Locking support
[ https://issues.apache.org/jira/browse/OAK-6421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6421: -- Fix Version/s: 1.14.0 > Phase out JCR Locking support > - > > Key: OAK-6421 > URL: https://issues.apache.org/jira/browse/OAK-6421 > Project: Jackrabbit Oak > Issue Type: Task > Components: jcr >Reporter: Marcel Reutegger >Priority: Major > Fix For: 1.12.0, 1.14.0 > > > Oak currently has a lot of gaps in its JCR Locking implementation (see > OAK-1962), which basically makes it non-compliant with the JCR specification. > I propose we phase out the support for JCR Locking because a proper > implementation would be rather complex with a runtime behaviour that is very > different in a standalone deployment compared to a cluster. In the standalone > case a lock could be acquired very quickly, while in the distributed case, > the operations would be multiple orders of magnitude slower, depending on how > cluster nodes are geographically distributed. > Applications that rely on strict lock semantics should use other mechanisms, > built explicitly for this purpose. E.g. Apache Zookeeper. > To ease upgrade and migration to a different lock mechanism, the proposal is > to introduce a flag or configuration that controls the level of support for > JCR Locking: > - DISABLED: the implementation does not support JCR Locking at all. Methods > will throw UnsupportedRepositoryOperationException when defined by the JCR > specification. > - DEPRECATED: the implementation behaves as right now, but logs a warn or > error message that JCR Locking does not work as specified and will be removed > in a future version of Oak. > In a later release (e.g. 1.10) the current JCR Locking implementation would > be removed entirely and unconditionally throw an exception. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-4498) Introduce lower limit for gc() maxRevisionAge
[ https://issues.apache.org/jira/browse/OAK-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-4498: -- Fix Version/s: 1.14.0 > Introduce lower limit for gc() maxRevisionAge > - > > Key: OAK-4498 > URL: https://issues.apache.org/jira/browse/OAK-4498 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, documentmk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.12.0, 1.14.0 > > > Introduce and enforce a lower limit for maxRevisionAge in > VersionGarbageCollector.gc(). > OAK-4494 changes the way documents in a cache are considered up-to-date. In > addition to the modCount value it also considers the modified timestamp. To > work properly, a new document must have a modified timestamp that is > different from a previous incarnation (i.e. before gc removed it). The > version GC should therefore not remove documents with a maxRevisionAge less > than the modified resolution (5 seconds). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7074) Ensure that all Documents are read with document order traversal indexing
[ https://issues.apache.org/jira/browse/OAK-7074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7074: -- Fix Version/s: 1.14.0 > Ensure that all Documents are read with document order traversal indexing > - > > Key: OAK-7074 > URL: https://issues.apache.org/jira/browse/OAK-7074 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk, run >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Major > Fix For: 1.12.0, 1.14.0 > > > With OAK-6353 support was added for document order traversal indexing. In > this mode we open a DB cursor and try to read all documents from it using > document order traversal. Such a cursor may remain open for long time (2-4 > hrs) and its possible that document may get reordered by the Mongo storage > engine. This would result in 2 aspects to be thought about > # Duplicate documents - Same document may appear more than once in result set > # Possibly missed document - It may be a possibility that a document got > moved and missed becoming part of cursor. > Both these aspects would need to be handled -- This message was sent by Atlassian JIRA (v7.6.3#76005)
