[jira] [Commented] (OAK-3054) IndexStatsMBean should provide some details if the async indexing is failing
[
https://issues.apache.org/jira/browse/OAK-3054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14968632#comment-14968632
]
Dheeraj Khanna commented on OAK-3054:
-
Hi [~edivad]
This is a regular ask by customers. There has been recent P1 because of
indexing fails and customers are asking for this feature to take corrective
actions. Requesting you to kindly bump the priority on this.
cc [~chetanm], [~alexparvulescu]
Thanks,
> IndexStatsMBean should provide some details if the async indexing is failing
>
>
> Key: OAK-3054
> URL: https://issues.apache.org/jira/browse/OAK-3054
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Chetan Mehrotra
>Priority: Minor
> Labels: resilience, tooling
> Fix For: 1.3.9, 1.2.8
>
>
> If the background indexing fails for some reason it logs the exception for
> the first time then it logs the exception like _The index update failed ..._.
> After that if indexing continues to fail then no further logging is done so
> as to avoid creating noise.
> This poses a problem on long running system where original exception might
> not be noticed and index does not show updated result. For such cases we
> should expose the indexing health as part of {{IndexStatsMBean}}. Also we can
> provide the last recorded exception.
> Administrator can then check for MBean and enable debug logs for further
> troubleshooting
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-3054) IndexStatsMBean should provide some details if the async indexing is failing
[
https://issues.apache.org/jira/browse/OAK-3054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14968632#comment-14968632
]
Dheeraj Khanna edited comment on OAK-3054 at 10/22/15 6:31 AM:
---
Hi [~edivad]
This is a regular ask by customers. Requesting you to kindly bump the priority
on this.
cc [~chetanm], [~alexparvulescu]
Thanks,
was (Author: dheerajkhanna):
Hi [~edivad]
This is a regular ask by customers. There has been recent P1 because of
indexing fails and customers are asking for this feature to take corrective
actions. Requesting you to kindly bump the priority on this.
cc [~chetanm], [~alexparvulescu]
Thanks,
> IndexStatsMBean should provide some details if the async indexing is failing
>
>
> Key: OAK-3054
> URL: https://issues.apache.org/jira/browse/OAK-3054
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Chetan Mehrotra
>Priority: Minor
> Labels: resilience, tooling
> Fix For: 1.3.9, 1.2.8
>
>
> If the background indexing fails for some reason it logs the exception for
> the first time then it logs the exception like _The index update failed ..._.
> After that if indexing continues to fail then no further logging is done so
> as to avoid creating noise.
> This poses a problem on long running system where original exception might
> not be noticed and index does not show updated result. For such cases we
> should expose the indexing health as part of {{IndexStatsMBean}}. Also we can
> provide the last recorded exception.
> Administrator can then check for MBean and enable debug logs for further
> troubleshooting
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-1617) Automatically convert "or" queries to "union" for SQL-2
[ https://issues.apache.org/jira/browse/OAK-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14967304#comment-14967304 ] Davide Giannella edited comment on OAK-1617 at 10/21/15 4:07 PM: - in trunk at https://svn.apache.org/r1709863 and docs in https://svn.apache.org/r1709875 we'll follow-up with bugs in case. was (Author: edivad): in trunk at https://svn.apache.org/r1709863 we'll follow-up with bugs in case. > Automatically convert "or" queries to "union" for SQL-2 > --- > > Key: OAK-1617 > URL: https://issues.apache.org/jira/browse/OAK-1617 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Thomas Mueller >Assignee: Davide Giannella >Priority: Minor > Fix For: 1.3.9 > > Attachments: OAK-1617-1.patch, OAK-1617-2.patch, OAK-1617-3.patch > > > XPath queries that contain "or" conditions are automatically converted to > "union" SQL-2 queries. However, SQL-2 queries that contain "or" conditions > are not (yet). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-1617) Automatically convert "or" queries to "union" for SQL-2
[ https://issues.apache.org/jira/browse/OAK-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14967304#comment-14967304 ] Davide Giannella edited comment on OAK-1617 at 10/21/15 3:20 PM: - in trunk at https://svn.apache.org/r1709863 we'll follow-up with bugs in case. was (Author: edivad): in trunk at https://svn.apache.org/r1709863 > Automatically convert "or" queries to "union" for SQL-2 > --- > > Key: OAK-1617 > URL: https://issues.apache.org/jira/browse/OAK-1617 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Thomas Mueller >Assignee: Davide Giannella >Priority: Minor > Fix For: 1.3.9 > > Attachments: OAK-1617-1.patch, OAK-1617-2.patch, OAK-1617-3.patch > > > XPath queries that contain "or" conditions are automatically converted to > "union" SQL-2 queries. However, SQL-2 queries that contain "or" conditions > are not (yet). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-1617) Automatically convert "or" queries to "union" for SQL-2
[ https://issues.apache.org/jira/browse/OAK-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella resolved OAK-1617. --- Resolution: Fixed in trunk at https://svn.apache.org/r1709863 > Automatically convert "or" queries to "union" for SQL-2 > --- > > Key: OAK-1617 > URL: https://issues.apache.org/jira/browse/OAK-1617 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Thomas Mueller >Assignee: Davide Giannella >Priority: Minor > Fix For: 1.3.9 > > Attachments: OAK-1617-1.patch, OAK-1617-2.patch, OAK-1617-3.patch > > > XPath queries that contain "or" conditions are automatically converted to > "union" SQL-2 queries. However, SQL-2 queries that contain "or" conditions > are not (yet). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-3533) Make it possible to disable LuceneIndexProviderService via OSGi configuration
[
https://issues.apache.org/jira/browse/OAK-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari resolved OAK-3533.
-
Resolution: Fixed
Fix Version/s: 1.3.9
Fixed in r1709862.
> Make it possible to disable LuceneIndexProviderService via OSGi configuration
> -
>
> Key: OAK-3533
> URL: https://issues.apache.org/jira/browse/OAK-3533
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Affects Versions: 1.3.9
>Reporter: Francesco Mari
>Assignee: Francesco Mari
> Fix For: 1.3.9
>
>
> It would be useful for testing purposes if {{LuceneIndexProviderService}}
> could react to an OSGi configuration property to disable itself. Not to break
> backwards compatibility, the service should be enabled by default.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3533) Make it possible to disable LuceneIndexProviderService via OSGi configuration
[
https://issues.apache.org/jira/browse/OAK-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari updated OAK-3533:
Issue Type: Improvement (was: Bug)
> Make it possible to disable LuceneIndexProviderService via OSGi configuration
> -
>
> Key: OAK-3533
> URL: https://issues.apache.org/jira/browse/OAK-3533
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Affects Versions: 1.3.9
>Reporter: Francesco Mari
>Assignee: Francesco Mari
>
> It would be useful for testing purposes if {{LuceneIndexProviderService}}
> could react to an OSGi configuration property to disable itself. Not to break
> backwards compatibility, the service should be enabled by default.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3506) Uniformization of compaction log messages
[
https://issues.apache.org/jira/browse/OAK-3506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14967264#comment-14967264
]
Alex Parvulescu commented on OAK-3506:
--
fyi minor issue with logging uncovered just now (missing space before 'and
space reclaimed'):
{code}
16:26:46.993 INFO [TarMK flush thread
[target/SegmentCompactionIT5813480984460923336dir], active since Wed Oct 21
16:26:46 CEST 2015, previous max duration 116ms] FileStore.java:1461 TarMK GC
#2: cleanup completed in 451,7 ms (451 ms). Post cleanup size is 86,0 MB
(86047744 bytes)and space reclaimed 228,6 MB (228586496 bytes). Compaction map
weight/depth is 0 B/1 (0 bytes/1).
{code}
> Uniformization of compaction log messages
> -
>
> Key: OAK-3506
> URL: https://issues.apache.org/jira/browse/OAK-3506
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Valentin Olteanu
>Assignee: Michael Dürig
> Labels: compaction, gc
> Fix For: 1.4
>
> Attachments: compaction_logs.git.patch
>
>
> The logs generated during different phases of tar garbage collection
> (compaction) are currently quite heterogenous and difficult to grep/parse.
> I propose with the attached patch to uniformize these logs, changing the
> following:
> # all logs start with the prefix {{TarMK GargabeCollection \{\}#:}}
> # different phases of garbage collection are easier to identify by the first
> word after prefix, e.g. estimation, compaction, cleanup
> # all values are also printed in a standard unit, with the following format:
> {{ ()}}. This makes extraction of
> information much easier.
> # messages corresponding to the same cycle (run) can be grouped by including
> the runId in the prefix.
> Note1: I don't have enough visibility, but the changes might impact any
> system relying on the old format. Yet, I've seen they have changed before so
> this might not be a real concern.
> Note2: the runId is implemented as a static variable, which is reset every
> time the class is reloaded (e.g. at restart), so it is unique only during one
> run.
> Below you can find an excerpt of old logs and new logs to compare:
> NEW:
> {code}
> 12.10.2015 16:11:56.705 *INFO* [TarMK compaction thread
> [/Users/volteanu/workspace/test/qp/quickstart-author-4502/crx-quickstart/repository/segmentstore],
> active since Mon Oct 12 16:11:56 CEST 2015, previous max duration 0ms]
> org.apache.jackrabbit.oak.plugins.segment.file.FileStore TarMK
> GarbageCollection #1: started
> 12.10.2015 16:11:56.707 *INFO* [TarMK compaction thread
> [/Users/volteanu/workspace/test/qp/quickstart-author-4502/crx-quickstart/repository/segmentstore],
> active since Mon Oct 12 16:11:56 CEST 2015, previous max duration 0ms]
> org.apache.jackrabbit.oak.plugins.segment.file.FileStore TarMK
> GarbageCollection #1: estimation started
> 12.10.2015 16:11:59.275 *INFO* [TarMK compaction thread
> [/Users/volteanu/workspace/test/qp/quickstart-author-4502/crx-quickstart/repository/segmentstore],
> active since Mon Oct 12 16:11:56 CEST 2015, previous max duration 0ms]
> org.apache.jackrabbit.oak.plugins.segment.file.FileStore TarMK
> GarbageCollection #1: estimation completed in 2.569 s (2567 ms). Gain is 16%
> or 1.1 GB/1.3 GB (1062364160/1269737472 bytes), so running compaction
> 12.10.2015 16:11:59.275 *INFO* [TarMK compaction thread
> [/Users/volteanu/workspace/test/qp/quickstart-author-4502/crx-quickstart/repository/segmentstore],
> active since Mon Oct 12 16:11:56 CEST 2015, previous max duration 0ms]
> org.apache.jackrabbit.oak.plugins.segment.file.FileStore TarMK
> GarbageCollection #1: compaction started,
> strategy=CompactionStrategy{paused=false, cloneBinaries=false,
> cleanupType=CLEAN_OLD, olderThan=3600, memoryThreshold=5,
> persistedCompactionMap=true, retryCount=5, forceAfterFail=true,
> compactionStart=1444659116706, offlineCompaction=false}
> 12.10.2015 16:12:05.839 *INFO* [TarMK compaction thread
> [/Users/volteanu/workspace/test/qp/quickstart-author-4502/crx-quickstart/repository/segmentstore],
> active since Mon Oct 12 16:11:56 CEST 2015, previous max duration 0ms]
> org.apache.jackrabbit.oak.plugins.segment.Compactor Finished compaction:
> 420022 nodes, 772259 properties, 20544 binaries.
> 12.10.2015 16:12:07.459 *INFO* [TarMK compaction thread
> [/Users/volteanu/workspace/test/qp/quickstart-author-4502/crx-quickstart/repository/segmentstore],
> active since Mon Oct 12 16:11:56 CEST 2015, previous max duration 0ms]
> org.apache.jackrabbit.oak.plugins.segment.file.FileStore TarMK
> GarbageCollection #1: compaction completed in 8.184 s (8183 ms), after 0
> cycles
> 12.10.2015 16:12:11.912 *INFO* [TarMK flush thread
> [/Users/volteanu/workspace/test/qp/quickstart-author-4502/crx-quickstart/repository/seg
[jira] [Commented] (OAK-3532) create RDB export tool
[ https://issues.apache.org/jira/browse/OAK-3532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14967234#comment-14967234 ] Julian Reschke commented on OAK-3532: - First version committed to trunk. Usage: a) build oak-run b) java -cp ... org.apache.jackrabbit.oak.plugins.document.rdb.RDBExport JDBC-URI username password tablename [whereclause] class path needs to contain JDBC driver and oak-run; whereclause is optional and inserts "where" automatically > create RDB export tool > -- > > Key: OAK-3532 > URL: https://issues.apache.org/jira/browse/OAK-3532 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: core >Reporter: Julian Reschke >Assignee: Julian Reschke > > Create a super-simple utility that can export JSON representations of > selected rows. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-3533) Make it possible to disable LuceneIndexProviderService via OSGi configuration
Francesco Mari created OAK-3533:
---
Summary: Make it possible to disable LuceneIndexProviderService
via OSGi configuration
Key: OAK-3533
URL: https://issues.apache.org/jira/browse/OAK-3533
Project: Jackrabbit Oak
Issue Type: Bug
Components: lucene
Affects Versions: 1.3.9
Reporter: Francesco Mari
Assignee: Francesco Mari
It would be useful for testing purposes if {{LuceneIndexProviderService}} could
react to an OSGi configuration property to disable itself. Not to break
backwards compatibility, the service should be enabled by default.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-3532) create RDB export tool
Julian Reschke created OAK-3532: --- Summary: create RDB export tool Key: OAK-3532 URL: https://issues.apache.org/jira/browse/OAK-3532 Project: Jackrabbit Oak Issue Type: Technical task Components: core Reporter: Julian Reschke Assignee: Julian Reschke Create a super-simple utility that can export JSON representations of selected rows. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2592) Commit does not ensure w:majority
[
https://issues.apache.org/jira/browse/OAK-2592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14966803#comment-14966803
]
Marcel Reutegger commented on OAK-2592:
---
I see the following alternatives to findAndModify():
- First ensure the document is cached and then perform a conditional update()
on the modCount. If it fails, repeat until it succeeds. This option does not
work well, when there are concurrent updates from multiple cluster nodes on the
same document and we may run into a liveness problem.
- Perform an unconditional update and then read the document from MongoDB.
Create a before document by applying the reverse operation on the document. The
document may be slightly different from what findAndModify() returns. The
assumed _modCount may not exactly match the state of the document before the
update was applied. Between the update and the read operation another update
from another cluster node may slip in and update the _modCount. This wouldn't
be a problem, because _modCount is an implementation detail of the
MongoDocumentStore. There's another problem, though. Some operations cannot be
reverted. Setting a top level property in a document overwrites the previous
value. At least for the final update on the commit root document, this wouldn't
be a problem. The only top level property changed by such a update is _modified
(in addition to the _modCount).
> Commit does not ensure w:majority
> -
>
> Key: OAK-2592
> URL: https://issues.apache.org/jira/browse/OAK-2592
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, mongomk
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
> Labels: resilience
> Fix For: 1.3.9
>
>
> The MongoDocumentStore uses {{findAndModify()}} to commit a transaction. This
> operation does not allow an application specified write concern and always
> uses the MongoDB default write concern {{Acknowledged}}. This means a commit
> may not make it to a majority of a replica set when the primary fails. From a
> MongoDocumentStore perspective it may appear as if a write was successful and
> later reverted. See also the test in OAK-1641.
> To fix this, we'd probably have to change the MongoDocumentStore to avoid
> {{findAndModify()}} and use {{update()}} instead.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3215) Solr test often fail with No such core: oak
[
https://issues.apache.org/jira/browse/OAK-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14966782#comment-14966782
]
Tommaso Teofili commented on OAK-3215:
--
unfortunately the above fix doesn't solve the problem, as such errors still
happen in
[Jenkins|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/496/]
> Solr test often fail with No such core: oak
>
>
> Key: OAK-3215
> URL: https://issues.apache.org/jira/browse/OAK-3215
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: solr
>Reporter: Chetan Mehrotra
>Assignee: Tommaso Teofili
>Priority: Minor
> Labels: CI
> Fix For: 1.3.9
>
>
> Often it can be seen that all test from oak-solr module fail. And in all such
> failure following error is reported
> {noformat}
> org.apache.solr.common.SolrException: No such core: oak
> at
> org.apache.solr.client.solrj.embedded.EmbeddedSolrServer.request(EmbeddedSolrServer.java:112)
> at
> org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:118)
> at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:116)
> at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:102)
> at
> org.apache.jackrabbit.oak.plugins.index.solr.query.SolrQueryIndexTest.testQueryOnIgnoredExistingProperty(SolrQueryIndexTest.java:330)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> {noformat}
> Most recent failure in
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/325/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-3489) DocumentStore: introduce a "NotEquals" condition
[ https://issues.apache.org/jira/browse/OAK-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14966700#comment-14966700 ] Julian Reschke edited comment on OAK-3489 at 10/21/15 12:04 PM: Proposed patch (now supporting null both for equals and notEquals, also adding method signatures for properties) - [~mreutegg] can you please review? was (Author: reschke): Proposed patch (now supporting null both for equals and notEquals, also adding method signatures for properties) > DocumentStore: introduce a "NotEquals" condition > > > Key: OAK-3489 > URL: https://issues.apache.org/jira/browse/OAK-3489 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk, rdbmk >Affects Versions: 1.0.21, 1.2.6, 1.3.7 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Attachments: OAK-3489.diff > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3489) DocumentStore: introduce a "NotEquals" condition
[ https://issues.apache.org/jira/browse/OAK-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-3489: Attachment: OAK-3489.diff Proposed patch (now supporting null both for equals and notEquals, also adding method signatures for properties) > DocumentStore: introduce a "NotEquals" condition > > > Key: OAK-3489 > URL: https://issues.apache.org/jira/browse/OAK-3489 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk, rdbmk >Affects Versions: 1.0.21, 1.2.6, 1.3.7 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Attachments: OAK-3489.diff > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3489) DocumentStore: introduce a "NotEquals" condition
[ https://issues.apache.org/jira/browse/OAK-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-3489: Attachment: (was: OAK-3489.diff) > DocumentStore: introduce a "NotEquals" condition > > > Key: OAK-3489 > URL: https://issues.apache.org/jira/browse/OAK-3489 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk, rdbmk >Affects Versions: 1.0.21, 1.2.6, 1.3.7 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Attachments: OAK-3489.diff > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2774) Invalid characters not escaped while fulltext query parsing
[
https://issues.apache.org/jira/browse/OAK-2774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14966643#comment-14966643
]
Stefan Seifert commented on OAK-2774:
-
i hit this problem today as well, same happens if e.g. a {{"}} is contained in
the fulltext query expression.
the question is if its appropriate to throw a RuntimeException if the lucene
query parsing fails. this makes it hard catching such parsing errors in the
calling code.
is it indented to support lucene query syntax features in the jcr:contains()
expression? then a proper InvalidQueryException or simular should be thrown.
otherwise escaping as recommended in this ticket should to the job.
> Invalid characters not escaped while fulltext query parsing
> ---
>
> Key: OAK-2774
> URL: https://issues.apache.org/jira/browse/OAK-2774
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.2
>Reporter: Rishabh Maurya
>
> Invalid characters such as forward slash {{/}} should be escaped, as fulltext
> search on them results in below error -
> {code}
> java.lang.RuntimeException: INVALID_SYNTAX_CANNOT_PARSE: Syntax Error, cannot
> parse /bar: Lexical error at line 1, column 5. Encountered: after :
> "/bar"
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.tokenToQuery(LucenePropertyIndex.java:1042)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$2.visitTerm(LucenePropertyIndex.java:983)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$2.visit(LucenePropertyIndex.java:978)
> at
> org.apache.jackrabbit.oak.query.fulltext.FullTextTerm.accept(FullTextTerm.java:215)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.getFullTextQuery(LucenePropertyIndex.java:933)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.getLuceneRequest(LucenePropertyIndex.java:519)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.access$200(LucenePropertyIndex.java:160)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$1.loadDocs(LucenePropertyIndex.java:321)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$1.computeNext(LucenePropertyIndex.java:274)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$1.computeNext(LucenePropertyIndex.java:265)
> at
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
> at
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$LucenePathCursor$1.hasNext(LucenePropertyIndex.java:1138)
> ...
> {code}
> http://lucene.apache.org/core/4_0_0/queryparser/org/apache/lucene/queryparser/classic/QueryParserBase.html#escape(java.lang.String)
> should be used to escape such invalid characters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-3531) Oak Explorer: add segment GC roots report
[
https://issues.apache.org/jira/browse/OAK-3531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14966597#comment-14966597
]
Alex Parvulescu edited comment on OAK-3531 at 10/21/15 10:26 AM:
-
as it turns out, this can be very expensive to run.
this is how the report will look like, given a segment UUID, it will print an
inverted index of the dependencies. it currently doesn't build the longest path
to the root, it would only pick up one link of the chain and attach segments of
dependencies to it by removing the segment from the main list until it reaches
a local root, then continues with the next link until it consumes the entire
list.
{code}
Segment GC roots:
399e26dc-330a-411c-aaee-acf93e604c87[data0b.tar]
6098dafb-cb19-41c8-abd5-0c0d32499af0[data0b.tar]
5a27494a-fe0a-4729-a1dd-bb58ee0cd029[data0b.tar]
4d4a4a70-786f-4be5-ab1c-bded9df63f28[data0b.tar]
0a0ca1bb-2780-4c41-a3c9-d24c9ac09cd8[data0b.tar]
6e9ddbf6-e3b0-4dcd-a6ad-45d31ea42437[data0b.tar]
8ba151c1-8877-48d5-a988-3e3d1a2ff77f[data0b.tar]
e1dbc39a-19af-48f1-ae4a-b423f5f5ac36[data0b.tar]
6e9ddbf6-e3b0-4dcd-a6ad-45d31ea42437[data0b.tar]
3179b1df-3a95-4806-ab36-d42c8a816ac6[data0b.tar]
20a42a8c-de49-4281-ad74-36fd8f308101[data0b.tar]
5a27494a-fe0a-4729-a1dd-bb58ee0cd029[data0b.tar]
4d4a4a70-786f-4be5-ab1c-bded9df63f28[data0b.tar]
3179b1df-3a95-4806-ab36-d42c8a816ac6[data0b.tar]
0a0ca1bb-2780-4c41-a3c9-d24c9ac09cd8[data0b.tar]
63750e35-3eb0-4601-a466-9f09538bc138[data0b.tar]
4d4a4a70-786f-4be5-ab1c-bded9df63f28[data0b.tar]
0a0ca1bb-2780-4c41-a3c9-d24c9ac09cd8[data0b.tar]
20a42a8c-de49-4281-ad74-36fd8f308101[data0b.tar]
63750e35-3eb0-4601-a466-9f09538bc138[data0b.tar]
{code}
In with rev1709789 and r1709790. the changes also included a fair amount of
refactoring.
was (Author: alex.parvulescu):
as it turns out, this can be very expensive to run.
this is how the report will look like, given a segment UUID, it will print an
inverted index of the dependencies. it currently doesn't build the longest path
to the root, it would only pick up one link of the chain and attach segments of
dependencies to it by removing the segment from the main list until it reaches
a local root, then continues with the next link until it consumes the entire
list.
{code}
Segment GC roots:
399e26dc-330a-411c-aaee-acf93e604c87[data0b.tar]
6098dafb-cb19-41c8-abd5-0c0d32499af0[data0b.tar]
5a27494a-fe0a-4729-a1dd-bb58ee0cd029[data0b.tar]
4d4a4a70-786f-4be5-ab1c-bded9df63f28[data0b.tar]
0a0ca1bb-2780-4c41-a3c9-d24c9ac09cd8[data0b.tar]
6e9ddbf6-e3b0-4dcd-a6ad-45d31ea42437[data0b.tar]
8ba151c1-8877-48d5-a988-3e3d1a2ff77f[data0b.tar]
e1dbc39a-19af-48f1-ae4a-b423f5f5ac36[data0b.tar]
6e9ddbf6-e3b0-4dcd-a6ad-45d31ea42437[data0b.tar]
3179b1df-3a95-4806-ab36-d42c8a816ac6[data0b.tar]
20a42a8c-de49-4281-ad74-36fd8f308101[data0b.tar]
5a27494a-fe0a-4729-a1dd-bb58ee0cd029[data0b.tar]
4d4a4a70-786f-4be5-ab1c-bded9df63f28[data0b.tar]
3179b1df-3a95-4806-ab36-d42c8a816ac6[data0b.tar]
0a0ca1bb-2780-4c41-a3c9-d24c9ac09cd8[data0b.tar]
63750e35-3eb0-4601-a466-9f09538bc138[data0b.tar]
4d4a4a70-786f-4be5-ab1c-bded9df63f28[data0b.tar]
0a0ca1bb-2780-4c41-a3c9-d24c9ac09cd8[data0b.tar]
20a42a8c-de49-4281-ad74-36fd8f308101[data0b.tar]
63750e35-3eb0-4601-a466-9f09538bc138[data0b.tar]
{code}
> Oak Explorer: add segment GC roots report
> -
>
> Key: OAK-3531
> URL: https://issues.apache.org/jira/browse/OAK-3531
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: run
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
>Priority: Minor
> Fix For: 1.3.9
>
>
> Improve the existing Segment reference report with some additional info about
> GC roots.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3531) Oak Explorer: add segment GC roots report
[
https://issues.apache.org/jira/browse/OAK-3531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14966597#comment-14966597
]
Alex Parvulescu commented on OAK-3531:
--
as it turns out, this can be very expensive to run.
this is how the report will look like, given a segment UUID, it will print an
inverted index of the dependencies. it currently doesn't build the longest path
to the root, it would only pick up one link of the chain and attach segments of
dependencies to it by removing the segment from the main list until it reaches
a local root, then continues with the next link until it consumes the entire
list.
{code}
Segment GC roots:
399e26dc-330a-411c-aaee-acf93e604c87[data0b.tar]
6098dafb-cb19-41c8-abd5-0c0d32499af0[data0b.tar]
5a27494a-fe0a-4729-a1dd-bb58ee0cd029[data0b.tar]
4d4a4a70-786f-4be5-ab1c-bded9df63f28[data0b.tar]
0a0ca1bb-2780-4c41-a3c9-d24c9ac09cd8[data0b.tar]
6e9ddbf6-e3b0-4dcd-a6ad-45d31ea42437[data0b.tar]
8ba151c1-8877-48d5-a988-3e3d1a2ff77f[data0b.tar]
e1dbc39a-19af-48f1-ae4a-b423f5f5ac36[data0b.tar]
6e9ddbf6-e3b0-4dcd-a6ad-45d31ea42437[data0b.tar]
3179b1df-3a95-4806-ab36-d42c8a816ac6[data0b.tar]
20a42a8c-de49-4281-ad74-36fd8f308101[data0b.tar]
5a27494a-fe0a-4729-a1dd-bb58ee0cd029[data0b.tar]
4d4a4a70-786f-4be5-ab1c-bded9df63f28[data0b.tar]
3179b1df-3a95-4806-ab36-d42c8a816ac6[data0b.tar]
0a0ca1bb-2780-4c41-a3c9-d24c9ac09cd8[data0b.tar]
63750e35-3eb0-4601-a466-9f09538bc138[data0b.tar]
4d4a4a70-786f-4be5-ab1c-bded9df63f28[data0b.tar]
0a0ca1bb-2780-4c41-a3c9-d24c9ac09cd8[data0b.tar]
20a42a8c-de49-4281-ad74-36fd8f308101[data0b.tar]
63750e35-3eb0-4601-a466-9f09538bc138[data0b.tar]
{code}
> Oak Explorer: add segment GC roots report
> -
>
> Key: OAK-3531
> URL: https://issues.apache.org/jira/browse/OAK-3531
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: run
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
>Priority: Minor
> Fix For: 1.3.9
>
>
> Improve the existing Segment reference report with some additional info about
> GC roots.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-3531) Oak Explorer: add segment GC roots report
Alex Parvulescu created OAK-3531: Summary: Oak Explorer: add segment GC roots report Key: OAK-3531 URL: https://issues.apache.org/jira/browse/OAK-3531 Project: Jackrabbit Oak Issue Type: Improvement Components: run Reporter: Alex Parvulescu Assignee: Alex Parvulescu Priority: Minor Fix For: 1.3.9 Improve the existing Segment reference report with some additional info about GC roots. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-3530) TreeTypeProvider returns wrong type for version related node type definitions
[
https://issues.apache.org/jira/browse/OAK-3530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved OAK-3530.
-
Resolution: Fixed
Fix Version/s: 1.3.9
rev. 1709750
> TreeTypeProvider returns wrong type for version related node type definitions
> -
>
> Key: OAK-3530
> URL: https://issues.apache.org/jira/browse/OAK-3530
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: angela
>Assignee: angela
> Fix For: 1.3.9
>
>
> the following paths with result in type {{VERSION}} instead of {{DEFAULT}}
> and might lead to unexpected results wrt read access:
> -
> /jcr:system/jcr:nodeTypes/rep:system/rep:namedChildNodeDefinitions/jcr:versionStorage
> -
> /jcr:system/jcr:nodeTypes/rep:system/rep:namedChildNodeDefinitions/jcr:activities
> -
> /jcr:system/jcr:nodeTypes/rep:system/rep:namedChildNodeDefinitions/jcr:configurations
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3530) TreeTypeProvider returns wrong type for version related node type definitions
[
https://issues.apache.org/jira/browse/OAK-3530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-3530:
Description:
the following paths with result in type {{VERSION}} instead of {{DEFAULT}} and
might lead to unexpected results wrt read access:
-
/jcr:system/jcr:nodeTypes/rep:system/rep:namedChildNodeDefinitions/jcr:versionStorage
-
/jcr:system/jcr:nodeTypes/rep:system/rep:namedChildNodeDefinitions/jcr:activities
-
/jcr:system/jcr:nodeTypes/rep:system/rep:namedChildNodeDefinitions/jcr:configurations
was:
the following paths with result in type {{VERSION}} instead of {{DEFAULT}} and
will most probably lead to unexpected results wrt read access:
-
/jcr:system/jcr:nodeTypes/rep:system/rep:namedChildNodeDefinitions/jcr:versionStorage
-
/jcr:system/jcr:nodeTypes/rep:system/rep:namedChildNodeDefinitions/jcr:activities
-
/jcr:system/jcr:nodeTypes/rep:system/rep:namedChildNodeDefinitions/jcr:configurations
> TreeTypeProvider returns wrong type for version related node type definitions
> -
>
> Key: OAK-3530
> URL: https://issues.apache.org/jira/browse/OAK-3530
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: angela
>Assignee: angela
>
> the following paths with result in type {{VERSION}} instead of {{DEFAULT}}
> and might lead to unexpected results wrt read access:
> -
> /jcr:system/jcr:nodeTypes/rep:system/rep:namedChildNodeDefinitions/jcr:versionStorage
> -
> /jcr:system/jcr:nodeTypes/rep:system/rep:namedChildNodeDefinitions/jcr:activities
> -
> /jcr:system/jcr:nodeTypes/rep:system/rep:namedChildNodeDefinitions/jcr:configurations
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-3530) TreeTypeProvider returns wrong type for version related node type definitions
angela created OAK-3530:
---
Summary: TreeTypeProvider returns wrong type for version related
node type definitions
Key: OAK-3530
URL: https://issues.apache.org/jira/browse/OAK-3530
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Reporter: angela
Assignee: angela
the following paths with result in type {{VERSION}} instead of {{DEFAULT}} and
will most probably lead to unexpected results wrt read access:
-
/jcr:system/jcr:nodeTypes/rep:system/rep:namedChildNodeDefinitions/jcr:versionStorage
-
/jcr:system/jcr:nodeTypes/rep:system/rep:namedChildNodeDefinitions/jcr:activities
-
/jcr:system/jcr:nodeTypes/rep:system/rep:namedChildNodeDefinitions/jcr:configurations
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2843) Broadcasting cache
[ https://issues.apache.org/jira/browse/OAK-2843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-2843: -- Fix Version/s: (was: 1.3.9) 1.4 > Broadcasting cache > -- > > Key: OAK-2843 > URL: https://issues.apache.org/jira/browse/OAK-2843 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.4 > > > In a cluster environment, we could speed up reading if the cache(s) broadcast > data to other instances. This would avoid bottlenecks at the storage layer > (MongoDB, RDBMs). > The configuration metadata (IP addresses and ports of where to send data to, > a unique identifier of the repository and the cluster nodes, possibly > encryption key) rarely changes and can be stored in the same place as we > store cluster metadata (cluster info collection). That way, in many cases no > manual configuration is needed. We could use TCP/IP and / or UDP. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-1557) Mark documents as deleted
[ https://issues.apache.org/jira/browse/OAK-1557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-1557: -- Fix Version/s: (was: 1.3.9) 1.4 > Mark documents as deleted > - > > Key: OAK-1557 > URL: https://issues.apache.org/jira/browse/OAK-1557 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk >Reporter: Marcel Reutegger >Assignee: Chetan Mehrotra > Labels: performance, resilience > Fix For: 1.4 > > > This is an improvement to make a certain use case more efficient. When there > is a parent node with frequently added and removed child nodes, the reading > of the current list of child nodes becomes inefficient because the decision > whether a node exists at a certain revision is done in the DocumentNodeStore > and no filtering is done on the MongoDB side. > So far we figured this would be solved automatically by the MVCC garbage > collection, when documents for deleted nodes are removed. However for > locations in the repository where nodes are added and deleted again > frequently (think of a temp folder), the issue pops up before the GC had a > chance to clean up. > The Document should have an additional field, which is set when the node is > deleted in the most recent revision. Based on this field the > DocumentNodeStore can limit the query to MongoDB to documents that are not > deleted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2907) Move DocumentMK to test
[ https://issues.apache.org/jira/browse/OAK-2907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-2907: -- Fix Version/s: (was: 1.3.10) 1.4 > Move DocumentMK to test > --- > > Key: OAK-2907 > URL: https://issues.apache.org/jira/browse/OAK-2907 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, mongomk >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Labels: technical_debt > Fix For: 1.4 > > > The DocumentMK class is not directly used (when using the JCR API), but it is > only really used by tests. So it should be moved to tests. > The DocumentMK.Builder class needs to be moved first (to a top level class > for example). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-1590) DocumentStore-specific test framework
[ https://issues.apache.org/jira/browse/OAK-1590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-1590: -- Fix Version/s: (was: 1.3.10) 1.4 > DocumentStore-specific test framework > - > > Key: OAK-1590 > URL: https://issues.apache.org/jira/browse/OAK-1590 > Project: Jackrabbit Oak > Issue Type: Task > Components: mongomk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: technical_debt, test > Fix For: 1.4 > > > Add tests that test DS implementations directly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2460) Resolve the base directory path of persistent cache against repository home
[
https://issues.apache.org/jira/browse/OAK-2460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-2460:
--
Fix Version/s: (was: 1.3.10)
1.4
> Resolve the base directory path of persistent cache against repository home
> ---
>
> Key: OAK-2460
> URL: https://issues.apache.org/jira/browse/OAK-2460
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: mongomk
>Reporter: Chetan Mehrotra
>Priority: Minor
> Labels: technical_debt
> Fix For: 1.4
>
>
> Currently PersistentCache uses the directory path directly. Various other
> parts in Oak which need access to the filesystem currently make use of
> {{repository.home}} framework property in OSGi env [1]
> Same should also be used in PersistentCache
> [1] http://jackrabbit.apache.org/oak/docs/osgi_config.html#SegmentNodeStore
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2744) Change default cache distribution ratio if persistent cache is enabled
[ https://issues.apache.org/jira/browse/OAK-2744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-2744: -- Fix Version/s: (was: 1.3.9) 1.4 > Change default cache distribution ratio if persistent cache is enabled > -- > > Key: OAK-2744 > URL: https://issues.apache.org/jira/browse/OAK-2744 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Labels: performance > Fix For: 1.4 > > > By default the cache memory in DocumentNodeStore is distributed in following > ratio > * nodeCache - 25% > * childrenCache - 10% > * docChildrenCache - 3% > * diffCache - 5% > * documentCache - Is given the rest i.e. 57% > However off late we have found that with persistent cache enabled we can > lower the cache allocated to Document cache. That would reduce the time spent > in invalidating cache entries in periodic reads. So far we are using > following ration in few setup and that is turning out well > * nodeCachePercentage=35 > * childrenCachePercentage=20 > * diffCachePercentage=30 > * docChildrenCachePercentage=10 > * documentCache - Is given the rest i.e. 5% > We should use the above distribution by default if the persistent cache is > found to be enabled -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2492) Flag Document having many children
[
https://issues.apache.org/jira/browse/OAK-2492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-2492:
--
Fix Version/s: (was: 1.3.9)
1.4
> Flag Document having many children
> --
>
> Key: OAK-2492
> URL: https://issues.apache.org/jira/browse/OAK-2492
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: mongomk
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Labels: performance
> Fix For: 1.4
>
>
> Current DocumentMK logic while performing a diff for child nodes works as
> below
> # Get children for _before_ revision upto MANY_CHILDREN_THRESHOLD (which
> defaults to 50). Further note that current logic of fetching children nodes
> also add children {{NodeDocument}} to {{Document}} cache and also reads the
> complete Document for those children
> # Get children for _after_ revision with limits as above
> # If the child list is complete then it does a direct diff on the fetched
> children
> # if the list is not complete i.e. number of children are more than the
> threshold then it for a query based diff (also see OAK-1970)
> So in those cases where number of children are large then all work done in #1
> above is wasted and should be avoided. To do that we can mark those parent
> nodes which have many children via special flag like {{_manyChildren}}. One
> such nodes are marked the diff logic can check for the flag and skip the work
> done in #1
> This is kind of similar to way we mark nodes which have at least one child
> (OAK-1117)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3066) Persistent cache for previous documents
[ https://issues.apache.org/jira/browse/OAK-3066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-3066: -- Fix Version/s: (was: 1.3.9) 1.4 > Persistent cache for previous documents > --- > > Key: OAK-3066 > URL: https://issues.apache.org/jira/browse/OAK-3066 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, mongomk >Reporter: Marcel Reutegger >Assignee: Vikas Saurabh > Labels: performance > Fix For: 1.4 > > > Previous (aka split) documents contain old revisions and are immutable > documents. Those documents should go into the persistent cache to reduce > calls to the underlying DocumentStore. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2242) provide a way to update the "created" timestamp of a NodeDocument
[ https://issues.apache.org/jira/browse/OAK-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-2242: -- Fix Version/s: (was: 1.3.9) 1.4 > provide a way to update the "created" timestamp of a NodeDocument > - > > Key: OAK-2242 > URL: https://issues.apache.org/jira/browse/OAK-2242 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk >Affects Versions: 1.1.1 >Reporter: Julian Reschke >Assignee: Julian Reschke > Labels: performance > Fix For: 1.4 > > > Both the MongoDocumentStore and the RDBDocumentStore maintain a "_modCount" > property, which uniquely identifies a version of a document in the > persistence. > Sometimes, we read data from the persistence although we already might have > the document cached. This happens: > a) when the cached document is older than what the caller asked for > b) when running a query (for instance when looking up children of a node) > In both cases, we currently replace the cache entry with a newly built > NodeDocument. > It would make sense to re-use the existing document instead. (This would > probably require modifying the "created" timestamp, but would avoid the > trouble of having to update the cache at all) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-1558) Expose FileStoreBackupRestoreMBean for supported NodeStores
[
https://issues.apache.org/jira/browse/OAK-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-1558:
---
Fix Version/s: (was: 1.4)
> Expose FileStoreBackupRestoreMBean for supported NodeStores
> ---
>
> Key: OAK-1558
> URL: https://issues.apache.org/jira/browse/OAK-1558
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: mongomk, segmentmk
>Reporter: Michael Dürig
> Labels: monitoring
>
> {{NodeStore}} implementations should expose the
> {{FileStoreBackupRestoreMBean}} in order to be interoperable with
> {{RepositoryManagementMBean}}. See OAK-1160.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3070) Use a lower bound in VersionGC query to avoid checking unmodified once deleted docs
[
https://issues.apache.org/jira/browse/OAK-3070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-3070:
--
Fix Version/s: (was: 1.3.9)
1.4
> Use a lower bound in VersionGC query to avoid checking unmodified once
> deleted docs
> ---
>
> Key: OAK-3070
> URL: https://issues.apache.org/jira/browse/OAK-3070
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: mongomk, rdbmk
>Reporter: Chetan Mehrotra
>Assignee: Vikas Saurabh
> Labels: performance
> Fix For: 1.4
>
> Attachments: OAK-3070.patch
>
>
> As part of OAK-3062 [~mreutegg] suggested
> {quote}
> As a further optimization we could also limit the lower bound of the _modified
> range. The revision GC does not need to check documents with a _deletedOnce
> again if they were not modified after the last successful GC run. If they
> didn't change and were considered existing during the last run, then they
> must still exist in the current GC run. To make this work, we'd need to
> track the last successful revision GC run.
> {quote}
> Lowest last validated _modified can be possibly saved in settings collection
> and reused for next run
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-533) Define behaviour for and implement mix:lastModified
[
https://issues.apache.org/jira/browse/OAK-533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-533:
--
Fix Version/s: (was: 1.4)
> Define behaviour for and implement mix:lastModified
> ---
>
> Key: OAK-533
> URL: https://issues.apache.org/jira/browse/OAK-533
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: jcr
>Reporter: Michael Dürig
> Attachments:
> 0001-OAK-533-Define-behaviour-for-and-implement-mix-lastM.patch
>
>
> There has been quite some discussion how to best implement
> {{mix:lastModified}} for Jackrabbit 2:
> https://issues.apache.org/jira/browse/JCR-2116
> https://issues.apache.org/jira/browse/JCR-2233
> http://markmail.org/thread/ygaktajwdz4z4r5m
> I think we should try to do it right from the start in Oak.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2613) Do versionGC more frequently and at adjusted speed
[
https://issues.apache.org/jira/browse/OAK-2613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-2613:
--
Fix Version/s: 1.4
> Do versionGC more frequently and at adjusted speed
> --
>
> Key: OAK-2613
> URL: https://issues.apache.org/jira/browse/OAK-2613
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, mongomk
>Affects Versions: 1.0.12
>Reporter: Stefan Egli
> Labels: observation, resilience
> Fix For: 1.4
>
>
> This is a follow-up ticket from
> [here|https://issues.apache.org/jira/browse/OAK-2557?focusedCommentId=14355322&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14355322]
> mixed with an offline discussion with [~mreutegg]:
> * we could make the VersionGC play nicely to existing load on the system: it
> could progress slower if the load is higher and vice-verca. One simple
> measure could be: if the observation queue is small (eg below 10) then the
> load is low and it could progress full-speed. Otherwise it could add some
> artificial sleeping in between.
> * we could run versionGC more regularly than once a day but instead kind of
> 'continuously' let it run in the background. While the speed of the gc would
> be adjusted to the load - it also would have to be assured that it doesn't
> run too slow (and would never finish if instance is under some constant load)
> Note that 'adjusted speed' would also imply some intelligence about the
> system load, as pointed out by [~chetanm] on OAK-2557:
> {quote}Version GC currently ensures that query fired is made against the
> Secondary (if present). However having some throttling in such background
> task would be good thing to have. But first we need to have some
> SystemLoadIndicator notion in Oak which can be provide details say in
> percentage 1..100 about system load. We can then expose configurable
> threshold which VersionGC would listen for and adjust its working accordingly.
> It can be a JMX bean which emits notification and we have our components
> listen to those notification (or use OSGi SR/Events). That can be used in
> other places like Observation processing, Blob GC etc
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2392) [DocumentMK] Garbage Collect older revisions of binary properties in main document
[ https://issues.apache.org/jira/browse/OAK-2392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-2392: -- Fix Version/s: (was: 1.3.9) 1.4 > [DocumentMK] Garbage Collect older revisions of binary properties in main > document > -- > > Key: OAK-2392 > URL: https://issues.apache.org/jira/browse/OAK-2392 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: 1.4 > > > Current GC logic for DocumentMK only collects certain types of garbage (see > OAK-1981) and currently only split documents are removed. While complete full > blow gc would take time and yet not fully implemented we should handle those > documents which have binary properties and those properties get updated few > times (but not very frequently). > For e.g. performing a reindex for Lucene index would lead to removal of index > files nodes and again creation of nodes with same name. In such a case the > older revision of binary property would remain in main document and would not > be eligible for gc as per current impl. > As a fix the GC logic should look for document which might have binaries and > then remove the older revisions of binary properties. Currently we do scan > all such documents for Blob GC. > So this can be done either as part of Revision GC or Blob GC -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2110) performance issues with VersionGarbageCollector
[ https://issues.apache.org/jira/browse/OAK-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-2110: -- Fix Version/s: (was: 1.3.9) 1.4 > performance issues with VersionGarbageCollector > --- > > Key: OAK-2110 > URL: https://issues.apache.org/jira/browse/OAK-2110 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk >Reporter: Julian Reschke >Assignee: Julian Reschke > Fix For: 1.4 > > > This one currently special-cases Mongo. For other persistences, it > - fetches *all* documents > - filters by SD_TYPE > - filters by lastmod of versions > - deletes what remains > This is not only inefficient but also fails with OutOfMemory for any larger > repo. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2919) Refactor DocumentNodeStoreService and dependencies
[ https://issues.apache.org/jira/browse/OAK-2919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-2919: -- Fix Version/s: (was: 1.3.10) > Refactor DocumentNodeStoreService and dependencies > -- > > Key: OAK-2919 > URL: https://issues.apache.org/jira/browse/OAK-2919 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: blob, mongomk >Reporter: Philipp Suter > Labels: technical_debt > > Change how DocumentNodeStoreService, DocumentNodeStore, DocumentStore, > BlobStore, DocumentMK.Builder are wired. It is unclear why > registerNodeStoreIfPossible and registerNodeStore need additional logic to > load the right BlobStore and DocumentStore. > - Ideally (Document)NodeStore references one DocumentStore and one BlobStore. > Configuration for them are loaded over respective OSGi configurations. > - Cache should be handled in (Document)NodeStore and be independent from > DocumentStore, BlobStore. > - DocumentMK.Builder and DocumentNodeStoreService should be obsolete. > - DocumentNodeStore is too long and could ideally be split in smaller files. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-1328) refactor DocumentMK caching
[ https://issues.apache.org/jira/browse/OAK-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-1328: -- Fix Version/s: (was: 1.3.10) > refactor DocumentMK caching > --- > > Key: OAK-1328 > URL: https://issues.apache.org/jira/browse/OAK-1328 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk, rdbmk >Reporter: Julian Reschke > Labels: technical_debt > > Caching currently is part of the DocumentStore API; consider to refactor the > code so that caching lives inside MongoMK and automatically applies to all > DocumentStore implementations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-1704) tighten DS contract for UpdateOps with checks
[ https://issues.apache.org/jira/browse/OAK-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-1704: -- Fix Version/s: (was: 1.3.10) > tighten DS contract for UpdateOps with checks > - > > Key: OAK-1704 > URL: https://issues.apache.org/jira/browse/OAK-1704 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk >Reporter: Julian Reschke >Priority: Minor > Labels: technical_debt > > [~mreutegg]: it may make sense to tighten the contract of the methods and > require an implementation to throw an IllegalArgumentException if the > UpdateOp contains a condition for a method that does not check them. > See also thread starting with > http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201404.mbox/%3C5344384D.7030103%40gmx.de%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
