[jira] [Updated] (OAK-2592) Commit does not ensure w:majority
[
https://issues.apache.org/jira/browse/OAK-2592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-2592:
--
Fix Version/s: (was: 1.3.13)
1.4
> 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.4
>
>
> 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] [Updated] (OAK-3649) Extract node document cache from Mongo and RDB document stores
[ https://issues.apache.org/jira/browse/OAK-3649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-3649: -- Fix Version/s: (was: 1.3.13) 1.4 > Extract node document cache from Mongo and RDB document stores > -- > > Key: OAK-3649 > URL: https://issues.apache.org/jira/browse/OAK-3649 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk, mongomk, rdbmk >Reporter: Tomek Rękawek >Assignee: Marcel Reutegger >Priority: Minor > Labels: candidate_oak_1_0, candidate_oak_1_2 > Fix For: 1.4 > > > MongoDocumentStore and RDBDocumentStore contains copy & pasted methods > responsible for handling node document cache. Extract these into a new > NodeDocumentCache. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (OAK-2629) Cleanup Oak Travis jobs
[ https://issues.apache.org/jira/browse/OAK-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger reassigned OAK-2629: - Assignee: Marcel Reutegger (was: Tommaso Teofili) > Cleanup Oak Travis jobs > --- > > Key: OAK-2629 > URL: https://issues.apache.org/jira/browse/OAK-2629 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: it >Reporter: Tommaso Teofili >Assignee: Marcel Reutegger > Labels: CI > Fix For: 1.4 > > > Since we're moving toward Jenkins, let's remove the Travis jobs for Oak. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2629) Cleanup Oak Travis jobs
[ https://issues.apache.org/jira/browse/OAK-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-2629: -- Fix Version/s: (was: 1.3.13) 1.4 > Cleanup Oak Travis jobs > --- > > Key: OAK-2629 > URL: https://issues.apache.org/jira/browse/OAK-2629 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: it >Reporter: Tommaso Teofili >Assignee: Marcel Reutegger > Labels: CI > Fix For: 1.4 > > > Since we're moving toward Jenkins, let's remove the Travis jobs for Oak. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3436) Prevent missing checkpoint due to unstable topology from causing complete reindexing
[
https://issues.apache.org/jira/browse/OAK-3436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15046507#comment-15046507
]
Chetan Mehrotra commented on OAK-3436:
--
Test framework introduced in {{AsyncIndexUpdateLeaseTest}} are pretty
comprehensive and use a much simpler approach to test concurrent update! Took
me some time to figure out why testPrePrepare is ok-ko and
testPrePrepareRexindex ok-ok. Also now if index update is failing due to lease
then that would also get reflected in MBean which is good. So nice work there :)
Given the actual fix is very small i.e. swapping the order of
{{updateTempCheckpoints}} and {{mergeWithConcurrencyCheck}} it would good to
commit the patch in 2 parts. One with test failure and minor refactoring just
required for test and then actual fix commit.
Also given that we are at it - I checked coverage and there is probably no
coverage for the loop in updateTempCheckpoints. Would be good to have some test
coverage for that if easily possible
> Prevent missing checkpoint due to unstable topology from causing complete
> reindexing
>
>
> Key: OAK-3436
> URL: https://issues.apache.org/jira/browse/OAK-3436
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Chetan Mehrotra
>Assignee: Alex Parvulescu
> Labels: resilience
> Fix For: 1.2.9, 1.3.13, 1.0.26
>
> Attachments: AsyncIndexUpdateClusterTest.java, OAK-3436-0.patch,
> OAK-3436-tests.patch, OAK-3436-v2.patch
>
>
> Async indexing logic relies on embedding application to ensure that async
> indexing job is run as a singleton in a cluster. For Sling based apps it
> depends on Sling Discovery support. At times it is being seen that if
> topology is not stable then different cluster nodes can consider them as
> leader and execute the async indexing job concurrently.
> This can cause problem as both cluster node might not see same repository
> state (due to write skew and eventual consistency) and might remove the
> checkpoint which other cluster node is still relying upon. For e.g. consider
> a 2 node cluster N1 and N2 where both are performing async indexing.
> # Base state - CP1 is the checkpoint for "async" job
> # N2 starts indexing and removes changes CP1 to CP2. For Mongo the
> checkpoints are saved in {{settings}} collection
> # N1 also decides to execute indexing but has yet not seen the latest
> repository state so still thinks that CP1 is the base checkpoint and tries to
> read it. However CP1 is already removed from {{settings}} and this makes N1
> think that checkpoint is missing and it decides to reindex everything!
> To avoid this topology must be stable but at Oak level we should still handle
> such a case and avoid doing a full reindexing. So we would need to have a
> {{MissingCheckpointStrategy}} similar to {{MissingIndexEditorStrategy}} as
> done in OAK-2203
> Possible approaches
> # A1 - Fail the indexing run if checkpoint is missing - Checkpoint being
> missing can have valid reason and invalid reason. Need to see what are valid
> scenarios where a checkpoint can go missing
> # A2 - When a checkpoint is created also store the creation time. When a
> checkpoint is found to be missing and its a *recent* checkpoint then fail the
> run. For e.g. we would fail the run till checkpoint found to be missing is
> less than an hour old (for just started take startup time into account)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3694) As a user, I want to know when a node that I've created has been indexed.
[
https://issues.apache.org/jira/browse/OAK-3694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-3694:
-
Fix Version/s: 1.4
> As a user, I want to know when a node that I've created has been indexed.
> -
>
> Key: OAK-3694
> URL: https://issues.apache.org/jira/browse/OAK-3694
> Project: Jackrabbit Oak
> Issue Type: Story
>Reporter: Valentin Olteanu
>Assignee: Chetan Mehrotra
> Fix For: 1.4
>
>
> As a user, I want to know when a node that I've created has been indexed so
> that I can start using it.
> Generalization: As a user, I want to know when everything created before
> timestamp T0 has been indexed.
> Ideal solution: MBean operation {{bool isIndexedBefore(long timestamp)}} that
> returns {{true}} if everything created before {{timestamp}} has been indexed
> (by all indexers).
> Current options:
> # check IndexStatsMBean for Start and Done to determine if a cycle has
> started after adding the node and has finished. Issue: there can be multiple
> async indexers. OAK-3606 proposes a solution.
> # add a node and search for it until it is retrieved. Issue: must add
> different nodes for different indexers and wait for all.
> These options are not precise (give false positives) and are not resilient to
> changes in indexing strategy (e.g. adding one more indexer breaks the
> checks).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (OAK-3694) As a user, I want to know when a node that I've created has been indexed.
[
https://issues.apache.org/jira/browse/OAK-3694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra reassigned OAK-3694:
Assignee: Chetan Mehrotra
> As a user, I want to know when a node that I've created has been indexed.
> -
>
> Key: OAK-3694
> URL: https://issues.apache.org/jira/browse/OAK-3694
> Project: Jackrabbit Oak
> Issue Type: Story
>Reporter: Valentin Olteanu
>Assignee: Chetan Mehrotra
> Fix For: 1.4
>
>
> As a user, I want to know when a node that I've created has been indexed so
> that I can start using it.
> Generalization: As a user, I want to know when everything created before
> timestamp T0 has been indexed.
> Ideal solution: MBean operation {{bool isIndexedBefore(long timestamp)}} that
> returns {{true}} if everything created before {{timestamp}} has been indexed
> (by all indexers).
> Current options:
> # check IndexStatsMBean for Start and Done to determine if a cycle has
> started after adding the node and has finished. Issue: there can be multiple
> async indexers. OAK-3606 proposes a solution.
> # add a node and search for it until it is retrieved. Issue: must add
> different nodes for different indexers and wait for all.
> These options are not precise (give false positives) and are not resilient to
> changes in indexing strategy (e.g. adding one more indexer breaks the
> checks).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3613) Backport TarMK revision gc related issues
[ https://issues.apache.org/jira/browse/OAK-3613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-3613: --- Fix Version/s: (was: 1.0.25) 1.0.26 > Backport TarMK revision gc related issues > - > > Key: OAK-3613 > URL: https://issues.apache.org/jira/browse/OAK-3613 > Project: Jackrabbit Oak > Issue Type: Task > Components: segmentmk >Reporter: Michael Dürig >Assignee: Michael Dürig > Labels: compaction, gc > Fix For: 1.2.9, 1.0.26 > > Attachments: > 0001-OAK-2870-Introduce-a-SegmentNodeStoreBuilder-to-help.patch, > 1.2-OAK-2870.patch, OAK-1995-1.0.patch, OAK-1995-1.2.zip, OsgiUtil-1.0.patch, > OsgiUtil-1.2.patch > > > Some of the issues related to TarMK revision gc should be back ported to the > branches. This issue is for keeping track of which issues and which svn > revisions we consider for back porting. The task consists of the following > steps: > # Identify issue to back port > # Merge the respective commits into a private forks of the 1.0 and 1.2 > branches > # Run tests on builds from the private forks > # On success merge the private forks to the 1.0 and 1.2 branches and update > the fix versions of the respective issues. > * Update the svn merge info with the respective merged svn revisions. > * Update the fix versions of the affected issues. > [~dhasler]: FYI > [~alex.parvulescu], [~frm]: please refrain from merging potential conflicting > changes into the branches in the meanwhile. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3436) Prevent missing checkpoint due to unstable topology from causing complete reindexing
[
https://issues.apache.org/jira/browse/OAK-3436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amit Jain updated OAK-3436:
---
Fix Version/s: (was: 1.0.25)
1.0.26
> Prevent missing checkpoint due to unstable topology from causing complete
> reindexing
>
>
> Key: OAK-3436
> URL: https://issues.apache.org/jira/browse/OAK-3436
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Chetan Mehrotra
>Assignee: Alex Parvulescu
> Labels: resilience
> Fix For: 1.2.9, 1.3.13, 1.0.26
>
> Attachments: AsyncIndexUpdateClusterTest.java, OAK-3436-0.patch,
> OAK-3436-tests.patch, OAK-3436-v2.patch
>
>
> Async indexing logic relies on embedding application to ensure that async
> indexing job is run as a singleton in a cluster. For Sling based apps it
> depends on Sling Discovery support. At times it is being seen that if
> topology is not stable then different cluster nodes can consider them as
> leader and execute the async indexing job concurrently.
> This can cause problem as both cluster node might not see same repository
> state (due to write skew and eventual consistency) and might remove the
> checkpoint which other cluster node is still relying upon. For e.g. consider
> a 2 node cluster N1 and N2 where both are performing async indexing.
> # Base state - CP1 is the checkpoint for "async" job
> # N2 starts indexing and removes changes CP1 to CP2. For Mongo the
> checkpoints are saved in {{settings}} collection
> # N1 also decides to execute indexing but has yet not seen the latest
> repository state so still thinks that CP1 is the base checkpoint and tries to
> read it. However CP1 is already removed from {{settings}} and this makes N1
> think that checkpoint is missing and it decides to reindex everything!
> To avoid this topology must be stable but at Oak level we should still handle
> such a case and avoid doing a full reindexing. So we would need to have a
> {{MissingCheckpointStrategy}} similar to {{MissingIndexEditorStrategy}} as
> done in OAK-2203
> Possible approaches
> # A1 - Fail the indexing run if checkpoint is missing - Checkpoint being
> missing can have valid reason and invalid reason. Need to see what are valid
> scenarios where a checkpoint can go missing
> # A2 - When a checkpoint is created also store the creation time. When a
> checkpoint is found to be missing and its a *recent* checkpoint then fail the
> run. For e.g. we would fail the run till checkpoint found to be missing is
> less than an hour old (for just started take startup time into account)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-3730) RDBDocumentStore: implement RDB-specific VersionGC support for lookup of split documents
[
https://issues.apache.org/jira/browse/OAK-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15045279#comment-15045279
]
Julian Reschke edited comment on OAK-3730 at 12/7/15 5:23 PM:
--
[~mreutegg]: this is a somewhat hacky (*) approach to implement
{{VersionGCSupport.identifyGarbage}} which tries to only SQL-Select IDs that
can potentially be split documents:
{noformat}
List keyPatterns = Arrays.asList(new String[] { "_:p%", "__:p%",
"___:p%", ":p%", "_:h%", "__:h%", "___:h%", "___:h%" });
{noformat}
(I believe this includes all split docs and all longpath docs, thus resulting
in a new - harmless - false positives)
(*) as it depends on assumptions about ID pattern formats
was (Author: reschke):
[~mreutegg]: this is a somewhat hacky (*) approach to implement
{{VersionGCSupport.identifyGarbage}} which tries to only SQL-Select IDs that
can potentially be split documents:
{{noformat}}
List keyPatterns = Arrays.asList(new String[] { "_:p%", "__:p%",
"___:p%", ":p%", "_:h%", "__:h%", "___:h%", "___:h%" });
{{noformat}}
(I believe this includes all split docs and all longpath docs, thus resulting
in a new - harmless - false positives)
(*) as it depends on assumptions about ID pattern formats
> RDBDocumentStore: implement RDB-specific VersionGC support for lookup of
> split documents
>
>
> Key: OAK-3730
> URL: https://issues.apache.org/jira/browse/OAK-3730
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: rdbmk
>Reporter: Julian Reschke
> Fix For: 1.4
>
> Attachments: OAK-3730.diff
>
>
> This requires a change to the table layout (adding SD_TYPE and more), thus
> needs thought about how to migrate from older versions of the persistence.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3730) RDBDocumentStore: implement RDB-specific VersionGC support for lookup of split documents
[
https://issues.apache.org/jira/browse/OAK-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15045279#comment-15045279
]
Julian Reschke commented on OAK-3730:
-
[~mreutegg]: this is a somewhat hacky (*) approach to implement
{{VersionGCSupport.identifyGarbage}} which tries to only SQL-Select IDs that
can potentially be split documents:
{{noformat}}
List keyPatterns = Arrays.asList(new String[] { "_:p%", "__:p%",
"___:p%", ":p%", "_:h%", "__:h%", "___:h%", "___:h%" });
{{noformat}}
(I believe this includes all split docs and all longpath docs, thus resulting
in a new - harmless - false positives)
(*) as it depends on assumptions about ID pattern formats
> RDBDocumentStore: implement RDB-specific VersionGC support for lookup of
> split documents
>
>
> Key: OAK-3730
> URL: https://issues.apache.org/jira/browse/OAK-3730
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: rdbmk
>Reporter: Julian Reschke
> Fix For: 1.4
>
> Attachments: OAK-3730.diff
>
>
> This requires a change to the table layout (adding SD_TYPE and more), thus
> needs thought about how to migrate from older versions of the persistence.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3730) RDBDocumentStore: implement RDB-specific VersionGC support for lookup of split documents
[ https://issues.apache.org/jira/browse/OAK-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-3730: Attachment: OAK-3730.diff Sketch of a patch that (ab)uses ID-like patterns to exclude non-split-documents > RDBDocumentStore: implement RDB-specific VersionGC support for lookup of > split documents > > > Key: OAK-3730 > URL: https://issues.apache.org/jira/browse/OAK-3730 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke > Fix For: 1.4 > > Attachments: OAK-3730.diff > > > This requires a change to the table layout (adding SD_TYPE and more), thus > needs thought about how to migrate from older versions of the persistence. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3436) Prevent missing checkpoint due to unstable topology from causing complete reindexing
[
https://issues.apache.org/jira/browse/OAK-3436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu updated OAK-3436:
-
Attachment: OAK-3436-v2.patch
attached better version based on previous patch, it also comes with a fix for
the current issue, and some more tests. the reindexing issue I noticed was a
bad test, I think now it should reflect the expectations better.
[~chetanm] please take a look when you can :)
> Prevent missing checkpoint due to unstable topology from causing complete
> reindexing
>
>
> Key: OAK-3436
> URL: https://issues.apache.org/jira/browse/OAK-3436
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Chetan Mehrotra
>Assignee: Alex Parvulescu
> Labels: resilience
> Fix For: 1.2.9, 1.0.25, 1.3.13
>
> Attachments: AsyncIndexUpdateClusterTest.java, OAK-3436-0.patch,
> OAK-3436-tests.patch, OAK-3436-v2.patch
>
>
> Async indexing logic relies on embedding application to ensure that async
> indexing job is run as a singleton in a cluster. For Sling based apps it
> depends on Sling Discovery support. At times it is being seen that if
> topology is not stable then different cluster nodes can consider them as
> leader and execute the async indexing job concurrently.
> This can cause problem as both cluster node might not see same repository
> state (due to write skew and eventual consistency) and might remove the
> checkpoint which other cluster node is still relying upon. For e.g. consider
> a 2 node cluster N1 and N2 where both are performing async indexing.
> # Base state - CP1 is the checkpoint for "async" job
> # N2 starts indexing and removes changes CP1 to CP2. For Mongo the
> checkpoints are saved in {{settings}} collection
> # N1 also decides to execute indexing but has yet not seen the latest
> repository state so still thinks that CP1 is the base checkpoint and tries to
> read it. However CP1 is already removed from {{settings}} and this makes N1
> think that checkpoint is missing and it decides to reindex everything!
> To avoid this topology must be stable but at Oak level we should still handle
> such a case and avoid doing a full reindexing. So we would need to have a
> {{MissingCheckpointStrategy}} similar to {{MissingIndexEditorStrategy}} as
> done in OAK-2203
> Possible approaches
> # A1 - Fail the indexing run if checkpoint is missing - Checkpoint being
> missing can have valid reason and invalid reason. Need to see what are valid
> scenarios where a checkpoint can go missing
> # A2 - When a checkpoint is created also store the creation time. When a
> checkpoint is found to be missing and its a *recent* checkpoint then fail the
> run. For e.g. we would fail the run till checkpoint found to be missing is
> less than an hour old (for just started take startup time into account)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3450) Configuration to have case insensitive suggestions
[
https://issues.apache.org/jira/browse/OAK-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-3450:
---
Fix Version/s: (was: 1.3.13)
1.4
> Configuration to have case insensitive suggestions
> --
>
> Key: OAK-3450
> URL: https://issues.apache.org/jira/browse/OAK-3450
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
> Fix For: 1.4
>
>
> Currently suggestions follow the same case as requested in query parameter.
> It makes sense to allow for it to be case insensitive. e.g. Asking for
> suggestions for {{cat}} should give {{Cat is an animal}} as well as
> {{category needs to be assigned}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3406) Configuration to rank exact match suggestions over partial match suggestions
[
https://issues.apache.org/jira/browse/OAK-3406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-3406:
---
Fix Version/s: (was: 1.3.13)
1.4
> Configuration to rank exact match suggestions over partial match suggestions
>
>
> Key: OAK-3406
> URL: https://issues.apache.org/jira/browse/OAK-3406
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
> Fix For: 1.4
>
>
> Currently, a suggestion query ranks the results according to popularity. But,
> at times, it's intended to have suggested phrases based on exact matches to
> be ranked above a more popular suggestion based on a partial match. e.g. a
> repository might have a 1000 docs with {{windows is a very popular OS}} and
> say 4 with {{win over them}} - it's a useful case to configure suggestions
> such that for a suggestions query for {{win}}, we'd get {{win over them}} as
> a higher ranked suggestion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2675) Include change type information in perf logs for diff logic
[
https://issues.apache.org/jira/browse/OAK-2675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-2675:
---
Fix Version/s: (was: 1.3.13)
1.4
> Include change type information in perf logs for diff logic
> ---
>
> Key: OAK-2675
> URL: https://issues.apache.org/jira/browse/OAK-2675
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Chetan Mehrotra
>Assignee: Vikas Saurabh
>Priority: Minor
> Labels: observation, performance, resilience, tooling
> Fix For: 1.4
>
>
> Currently the diff perf logs in {{NodeObserver}} does not indicate what type
> of change was processed i.e. was the change an internal one or an external
> one.
> Having this information would allow us to determine how the cache is being
> used. For e.g. if we see slower number even for local changes then that would
> indicate that there is some issue with the diff cache and its not be being
> utilized effectively
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2847) Dependency cleanup
[ https://issues.apache.org/jira/browse/OAK-2847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Saurabh updated OAK-2847: --- Fix Version/s: (was: 1.3.13) 1.4 > Dependency cleanup > --- > > Key: OAK-2847 > URL: https://issues.apache.org/jira/browse/OAK-2847 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Michael Dürig >Assignee: Vikas Saurabh > Labels: technical_debt > Fix For: 1.4 > > > Early in the next release cycle we should go through the list of Oak's > dependencies and decide whether we have candidates we want to upgrade and > remove orphaned dependencies. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-3742) FileStoreBackup and FileStoreRestore have a reference on Segment Store classes
Francesco Mari created OAK-3742:
---
Summary: FileStoreBackup and FileStoreRestore have a reference on
Segment Store classes
Key: OAK-3742
URL: https://issues.apache.org/jira/browse/OAK-3742
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Reporter: Francesco Mari
Assignee: Francesco Mari
{{FileStoreBackup}} and {{FileStoreRestore}} reference classes for the Segment
Store packages to create and initialise a store for backup and restore. This
direct reference makes difficult to move the Segment Store into its own
independent bundle.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3742) FileStoreBackup and FileStoreRestore have a reference on Segment Store classes
[
https://issues.apache.org/jira/browse/OAK-3742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari updated OAK-3742:
Fix Version/s: 1.4
> FileStoreBackup and FileStoreRestore have a reference on Segment Store classes
> --
>
> Key: OAK-3742
> URL: https://issues.apache.org/jira/browse/OAK-3742
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: Francesco Mari
>Assignee: Francesco Mari
> Fix For: 1.4
>
>
> {{FileStoreBackup}} and {{FileStoreRestore}} reference classes for the
> Segment Store packages to create and initialise a store for backup and
> restore. This direct reference makes difficult to move the Segment Store into
> its own independent bundle.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3741) AbstractCheckpointMBean references SegmentCheckpointMBean
[
https://issues.apache.org/jira/browse/OAK-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari updated OAK-3741:
Fix Version/s: 1.4
> AbstractCheckpointMBean references SegmentCheckpointMBean
> -
>
> Key: OAK-3741
> URL: https://issues.apache.org/jira/browse/OAK-3741
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: Francesco Mari
>Assignee: Francesco Mari
> Fix For: 1.4
>
>
> {{AbstractCheckpointMBean}} references a specific implementation, namely
> {{SegmentCheckpointMBean}}, to register an MBean using a specific class name.
> The reference to {{SegmentCheckpointMBean}} should be removed to allow the
> segment store to move to an independent bundle. Moreover, as a side effect,
> every MBean registered using {{AbstractCheckpointMBean}} will always have the
> same name, even if they are not related to the segment store in any way.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-3741) AbstractCheckpointMBean references SegmentCheckpointMBean
Francesco Mari created OAK-3741:
---
Summary: AbstractCheckpointMBean references SegmentCheckpointMBean
Key: OAK-3741
URL: https://issues.apache.org/jira/browse/OAK-3741
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Reporter: Francesco Mari
Assignee: Francesco Mari
{{AbstractCheckpointMBean}} references a specific implementation, namely
{{SegmentCheckpointMBean}}, to register an MBean using a specific class name.
The reference to {{SegmentCheckpointMBean}} should be removed to allow the
segment store to move to an independent bundle. Moreover, as a side effect,
every MBean registered using {{AbstractCheckpointMBean}} will always have the
same name, even if they are not related to the segment store in any way.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3740) ValueImpl has references on classes internal to SegmentStore
[
https://issues.apache.org/jira/browse/OAK-3740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari updated OAK-3740:
Fix Version/s: 1.4
> ValueImpl has references on classes internal to SegmentStore
>
>
> Key: OAK-3740
> URL: https://issues.apache.org/jira/browse/OAK-3740
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: Francesco Mari
>Assignee: Francesco Mari
> Fix For: 1.4
>
>
> {{o.a.j.o.plugins.value.ValueImpl}} references
> {{o.a.j.o.plugins.segment.SegmentNotFoundException}} to handle a specific
> case in a catch block. This reference should be broken to allow the segment
> store to be moved to an independent bundle.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-3740) ValueImpl has references on classes internal to SegmentStore
Francesco Mari created OAK-3740:
---
Summary: ValueImpl has references on classes internal to
SegmentStore
Key: OAK-3740
URL: https://issues.apache.org/jira/browse/OAK-3740
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Reporter: Francesco Mari
Assignee: Francesco Mari
{{o.a.j.o.plugins.value.ValueImpl}} references
{{o.a.j.o.plugins.segment.SegmentNotFoundException}} to handle a specific case
in a catch block. This reference should be broken to allow the segment store to
be moved to an independent bundle.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-3739) RDB*Store: allow schema evolution
Julian Reschke created OAK-3739: --- Summary: RDB*Store: allow schema evolution Key: OAK-3739 URL: https://issues.apache.org/jira/browse/OAK-3739 Project: Jackrabbit Oak Issue Type: Technical task Components: rdbmk Reporter: Julian Reschke Assignee: Julian Reschke In the future, we may have to add new table columns (for instance, see OAK-3730). We can somewhat decouple database changes from code changes by only using new columns when they are present. However, we need to make sure that once the columns have been added and the system has started to use them, no older code writes to the DB (potentially causing inconsistencies because of not updating these columns). To prevent this, code could check that it understands all columns it finds on startup. If there are unknown columns, it would need to abort and log an error that explains the compatibility issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3738) Datastore directory shouldn't be moved after the migration
[
https://issues.apache.org/jira/browse/OAK-3738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomek Rękawek updated OAK-3738:
---
Fix Version/s: (was: 1.3.13)
1.4
> Datastore directory shouldn't be moved after the migration
> --
>
> Key: OAK-3738
> URL: https://issues.apache.org/jira/browse/OAK-3738
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: upgrade
>Reporter: Tomek Rękawek
>Priority: Minor
> Fix For: 1.4
>
> Attachments: OAK-3738.patch
>
>
> After the in-place upgrade is finished, crx2oak moves all the CRX2 files into
> {{repository/crx2}} directory. This includes {{datastore}} directory, which
> may be reused by the Oak repository. Therefore, it shouldn't be moved if the
> {{--copy-binaries}} flag is not present.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3738) Datastore directory shouldn't be moved after the migration
[
https://issues.apache.org/jira/browse/OAK-3738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomek Rękawek updated OAK-3738:
---
Attachment: OAK-3738.patch
> Datastore directory shouldn't be moved after the migration
> --
>
> Key: OAK-3738
> URL: https://issues.apache.org/jira/browse/OAK-3738
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: upgrade
>Reporter: Tomek Rękawek
>Priority: Minor
> Fix For: 1.3.13
>
> Attachments: OAK-3738.patch
>
>
> After the in-place upgrade is finished, crx2oak moves all the CRX2 files into
> {{repository/crx2}} directory. This includes {{datastore}} directory, which
> may be reused by the Oak repository. Therefore, it shouldn't be moved if the
> {{--copy-binaries}} flag is not present.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3738) Datastore directory shouldn't be moved after the migration
[
https://issues.apache.org/jira/browse/OAK-3738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15045005#comment-15045005
]
Tomek Rękawek commented on OAK-3738:
[~jsedding], could you take a look on this patch?
> Datastore directory shouldn't be moved after the migration
> --
>
> Key: OAK-3738
> URL: https://issues.apache.org/jira/browse/OAK-3738
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: upgrade
>Reporter: Tomek Rękawek
>Priority: Minor
> Fix For: 1.3.13
>
> Attachments: OAK-3738.patch
>
>
> After the in-place upgrade is finished, crx2oak moves all the CRX2 files into
> {{repository/crx2}} directory. This includes {{datastore}} directory, which
> may be reused by the Oak repository. Therefore, it shouldn't be moved if the
> {{--copy-binaries}} flag is not present.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-3738) Datastore directory shouldn't be moved after the migration
Tomek Rękawek created OAK-3738:
--
Summary: Datastore directory shouldn't be moved after the migration
Key: OAK-3738
URL: https://issues.apache.org/jira/browse/OAK-3738
Project: Jackrabbit Oak
Issue Type: Bug
Components: upgrade
Reporter: Tomek Rękawek
Priority: Minor
Fix For: 1.3.13
After the in-place upgrade is finished, crx2oak moves all the CRX2 files into
{{repository/crx2}} directory. This includes {{datastore}} directory, which may
be reused by the Oak repository. Therefore, it shouldn't be moved if the
{{--copy-binaries}} flag is not present.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3646) Inconsistent read of hierarchy
[ https://issues.apache.org/jira/browse/OAK-3646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044990#comment-15044990 ] Marcel Reutegger commented on OAK-3646: --- A work-in-progress is available in a github branch: https://github.com/mreutegg/jackrabbit-oak/tree/OAK-3646 > Inconsistent read of hierarchy > --- > > Key: OAK-3646 > URL: https://issues.apache.org/jira/browse/OAK-3646 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, documentmk >Affects Versions: 1.0, 1.2 >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Fix For: 1.4 > > > This is similar to OAK-3388, but about hierarchy information like which child > nodes exist at a given revision of the parent node. This issue only occurs in > a cluster. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3450) Configuration to have case insensitive suggestions
[
https://issues.apache.org/jira/browse/OAK-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-3450:
--
Fix Version/s: (was: 1.3.12)
1.3.13
> Configuration to have case insensitive suggestions
> --
>
> Key: OAK-3450
> URL: https://issues.apache.org/jira/browse/OAK-3450
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
> Fix For: 1.3.13
>
>
> Currently suggestions follow the same case as requested in query parameter.
> It makes sense to allow for it to be case insensitive. e.g. Asking for
> suggestions for {{cat}} should give {{Cat is an animal}} as well as
> {{category needs to be assigned}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2477) Move suggester specific config to own configuration node
[ https://issues.apache.org/jira/browse/OAK-2477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-2477: -- Fix Version/s: (was: 1.3.12) 1.3.13 > Move suggester specific config to own configuration node > > > Key: OAK-2477 > URL: https://issues.apache.org/jira/browse/OAK-2477 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > Labels: technical_debt > Fix For: 1.3.13 > > > Currently suggester configuration is controlled via properties defined on > main config / props node but it'd be good if we would have its own place to > configure the whole suggest feature to not mix up configuration of other > features / parameters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[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: (was: 1.3.12)
1.3.13
> 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
>Priority: Minor
> Fix For: 1.3.13
>
>
> 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.java:14
[jira] [Updated] (OAK-2556) do intermediate commit during async indexing
[ https://issues.apache.org/jira/browse/OAK-2556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-2556: -- Fix Version/s: (was: 1.3.12) 1.3.13 > do intermediate commit during async indexing > > > Key: OAK-2556 > URL: https://issues.apache.org/jira/browse/OAK-2556 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Affects Versions: 1.0.11 >Reporter: Stefan Egli > Labels: resilience > Fix For: 1.3.13 > > > A recent issue found at a customer unveils a potential issue with the async > indexer. Reading the AsyncIndexUpdate.updateIndex it looks like it is doing > the entire update of the async indexer *in one go*, ie in one commit. > When there is - for some reason - however, a huge diff that the async indexer > has to process, the 'one big commit' can become gigantic. There is no limit > to the size of the commit in fact. > So the suggestion is to do intermediate commits while the async indexer is > going on. The reason this is acceptable is the fact that by doing async > indexing, that index is anyway not 100% up-to-date - so it would not make > much of a difference if it would commit after every 100 or 1000 changes > either. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3159) Extend documentation for SegmentNodeStoreService in http://jackrabbit.apache.org/oak/docs/osgi_config.html#SegmentNodeStore
[ https://issues.apache.org/jira/browse/OAK-3159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-3159: -- Fix Version/s: (was: 1.3.12) 1.3.13 > Extend documentation for SegmentNodeStoreService in > http://jackrabbit.apache.org/oak/docs/osgi_config.html#SegmentNodeStore > --- > > Key: OAK-3159 > URL: https://issues.apache.org/jira/browse/OAK-3159 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: doc >Reporter: Konrad Windszus > Fix For: 1.3.13 > > > Currently the documentation at > http://jackrabbit.apache.org/oak/docs/osgi_config.html#SegmentNodeStore only > documents the properties > # repository.home and > # tarmk.size > All the other properties like customBlobStore, tarmk.mode, are not > documented. Please extend that. Also it would be good, if the table could be > extended with what type is supported for the individual properties. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-3730) RDBDocumentStore: implement RDB-specific VersionGC support for lookup of split documents
[
https://issues.apache.org/jira/browse/OAK-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044961#comment-15044961
]
Julian Reschke edited comment on OAK-3730 at 12/7/15 1:49 PM:
--
Very good. This means that migration code could restrict itself to nodes where
ID LIKE {{_:p%}}, {{__:p%}} or {{___:p%}}...
was (Author: reschke):
Very good. This means that migration code could restrict itself to nodes where
ID LIKE '_:p%', '__:p%' or '___:p%'...
> RDBDocumentStore: implement RDB-specific VersionGC support for lookup of
> split documents
>
>
> Key: OAK-3730
> URL: https://issues.apache.org/jira/browse/OAK-3730
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: rdbmk
>Reporter: Julian Reschke
> Fix For: 1.4
>
>
> This requires a change to the table layout (adding SD_TYPE and more), thus
> needs thought about how to migrate from older versions of the persistence.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3728) Document indexes in the index itself
[
https://issues.apache.org/jira/browse/OAK-3728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-3728:
--
Fix Version/s: (was: 1.3.12)
1.3.13
> Document indexes in the index itself
>
>
> Key: OAK-3728
> URL: https://issues.apache.org/jira/browse/OAK-3728
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
> Fix For: 1.3.13
>
> Attachments: OAK-3728.patch
>
>
> Out-of-the box indexes should be documented, so that people know why they are
> needed. This is mainly needed for Oak indexes; we don't need to enforce this
> for user defined indexes.
> To do that, for each index, a property "info" could be added. Example:
> {noformat}
> /oak:index/nodetype/info = "Oak index used for ..."
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3071) Add a compound index for _modified + _id
[
https://issues.apache.org/jira/browse/OAK-3071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-3071:
--
Fix Version/s: (was: 1.3.12)
1.3.13
> Add a compound index for _modified + _id
>
>
> Key: OAK-3071
> URL: https://issues.apache.org/jira/browse/OAK-3071
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: mongomk
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Labels: performance, resilience
> Fix For: 1.3.13
>
>
> As explained in OAK-1966 diff logic makes a call like
> bq. db.nodes.find({ _id: { $gt: "3:/content/foo/01/", $lt:
> "3:/content/foo010" }, _modified: { $gte: 1405085300 } }).sort({_id:1})
> For better and deterministic query performance we would need to create a
> compound index like \{_modified:1, _id:1\}. This index would ensure that
> Mongo does not have to perform object scan while evaluating such a query.
> Care must be taken that index is only created by default for fresh setup. For
> existing setup we should expose a JMX operation which can be invoked by
> system admin to create the required index as per maintenance window
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-1695) Document Solr index
[ https://issues.apache.org/jira/browse/OAK-1695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-1695: -- Fix Version/s: (was: 1.3.12) 1.3.13 > Document Solr index > --- > > Key: OAK-1695 > URL: https://issues.apache.org/jira/browse/OAK-1695 > Project: Jackrabbit Oak > Issue Type: Task > Components: doc, solr >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > Labels: documentation > Fix For: 1.3.13 > > > Provide documentation about the Oak Solr index. That should contain > information about the design and how to configure it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2797) Closeable aspect of Analyzer should be accounted for
[
https://issues.apache.org/jira/browse/OAK-2797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-2797:
--
Fix Version/s: (was: 1.3.12)
1.3.13
> Closeable aspect of Analyzer should be accounted for
>
>
> Key: OAK-2797
> URL: https://issues.apache.org/jira/browse/OAK-2797
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Chetan Mehrotra
> Labels: technical_debt
> Fix For: 1.3.13
>
>
> Lucene {{Analyzer}} implements {{Closeable}} [1] interface and internally it
> has a ThreadLocal storage of some persistent resource
> So far in oak-lucene we do not take care of closing any analyzer. In fact we
> use a singleton Analyzer in all cases. Opening this bug to think about this
> aspect and see if our usage of Analyzer follows the best practices
> [1]
> http://lucene.apache.org/core/4_7_0/core/org/apache/lucene/analysis/Analyzer.html#close%28%29
> /cc [~teofili] [~alex.parvulescu]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3286) Persistent Cache improvements
[ https://issues.apache.org/jira/browse/OAK-3286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-3286: -- Fix Version/s: (was: 1.3.12) 1.3.13 > Persistent Cache improvements > - > > Key: OAK-3286 > URL: https://issues.apache.org/jira/browse/OAK-3286 > Project: Jackrabbit Oak > Issue Type: Epic > Components: cache >Reporter: Michael Marth >Priority: Minor > Fix For: 1.3.13 > > > Issue for collecting various improvements to the persistent cache -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2891) Use more efficient approach to manage in memory map in LengthCachingDataStore
[ https://issues.apache.org/jira/browse/OAK-2891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-2891: -- Fix Version/s: (was: 1.3.12) 1.3.13 > Use more efficient approach to manage in memory map in LengthCachingDataStore > - > > Key: OAK-2891 > URL: https://issues.apache.org/jira/browse/OAK-2891 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: upgrade >Reporter: Chetan Mehrotra >Priority: Minor > Fix For: 1.3.13 > > > LengthCachingDataStore introduced in OAK-2882 has an in memory map for > keeping the mapping between blobId and length. This would pose issue when > number of binaries are very large. > Instead of in memory map we should use some off heap store like MVStore of > MapDB -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3253) Support caching in FileDataStoreService
[ https://issues.apache.org/jira/browse/OAK-3253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-3253: -- Fix Version/s: (was: 1.3.12) 1.3.13 > Support caching in FileDataStoreService > --- > > Key: OAK-3253 > URL: https://issues.apache.org/jira/browse/OAK-3253 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: blob >Affects Versions: 1.3.3 >Reporter: Shashank Gupta >Assignee: Shashank Gupta > Labels: candidate_oak_1_0, candidate_oak_1_2, docs-impacting, > features, performance > Fix For: 1.3.13 > > > FDS on SAN/NAS storage is not efficient as it involves network call. In OAK. > indexes are stored SAN/NAS and even idle system does lot of read system > generated data. > Enable caching in FDS so the reads are done locally and async upload to > SAN/NAS > See [previous > discussions|https://issues.apache.org/jira/browse/OAK-3005?focusedCommentId=14700801&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14700801] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2478) Move spellcheck config to own configuration node
[ https://issues.apache.org/jira/browse/OAK-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-2478: -- Fix Version/s: (was: 1.3.12) 1.3.13 > Move spellcheck config to own configuration node > > > Key: OAK-2478 > URL: https://issues.apache.org/jira/browse/OAK-2478 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Tommaso Teofili > Labels: technical_debt > Fix For: 1.3.13 > > > Currently spellcheck configuration is controlled via properties defined on > main config / props node but it'd be good if we would have its own place to > configure the whole spellcheck feature to not mix up configuration of other > features / parameters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-937) Query engine index selection tweaks: shortcut and hint
[ https://issues.apache.org/jira/browse/OAK-937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-937: - Fix Version/s: (was: 1.3.12) 1.3.13 > Query engine index selection tweaks: shortcut and hint > -- > > Key: OAK-937 > URL: https://issues.apache.org/jira/browse/OAK-937 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, query >Reporter: Alex Parvulescu >Priority: Minor > Labels: performance > Fix For: 1.3.13 > > > This issue covers 2 different changes related to the way the QueryEngine > selects a query index: > Firstly there could be a way to end the index selection process early via a > known constant value: if an index returns a known value token (like -1000) > then the query engine would effectively stop iterating through the existing > index impls and use that index directly. > Secondly it would be nice to be able to specify a desired index (if one is > known to perform better) thus skipping the existing selection mechanism (cost > calculation and comparison). This could be done via certain query hints [0]. > [0] http://en.wikipedia.org/wiki/Hint_(SQL) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2618) Improve performance of queries with ORDER BY and multiple OR filters
[ https://issues.apache.org/jira/browse/OAK-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-2618: -- Fix Version/s: (was: 1.3.12) 1.3.13 > Improve performance of queries with ORDER BY and multiple OR filters > > > Key: OAK-2618 > URL: https://issues.apache.org/jira/browse/OAK-2618 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Amit Jain >Assignee: Amit Jain > Labels: performance > Fix For: 1.3.13 > > > When multiple OR constraints are specified in the XPATH query, itis broken up > into union of multiple clauses. If query includes an order by clause, the > sorting in this case is done by traversing the result set in memory leading > to slow query performance. > Possible improvements could include: > * For indexes which can support multiple filters (like lucene, solr) such > queries should be efficient and the query engine can pass-thru the query as > is. > ** Possibly also needed for other cases also. So, we can have some sort of > capability advertiser for indexes which can hint the query engine > and/or > * Batched merging of the sorted iterators returned for the multiple union > queries (possible externally). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2675) Include change type information in perf logs for diff logic
[
https://issues.apache.org/jira/browse/OAK-2675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-2675:
--
Fix Version/s: (was: 1.3.12)
1.3.13
> Include change type information in perf logs for diff logic
> ---
>
> Key: OAK-2675
> URL: https://issues.apache.org/jira/browse/OAK-2675
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Chetan Mehrotra
>Assignee: Vikas Saurabh
>Priority: Minor
> Labels: observation, performance, resilience, tooling
> Fix For: 1.3.13
>
>
> Currently the diff perf logs in {{NodeObserver}} does not indicate what type
> of change was processed i.e. was the change an internal one or an external
> one.
> Having this information would allow us to determine how the cache is being
> used. For e.g. if we see slower number even for local changes then that would
> indicate that there is some issue with the diff cache and its not be being
> utilized effectively
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3406) Configuration to rank exact match suggestions over partial match suggestions
[
https://issues.apache.org/jira/browse/OAK-3406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-3406:
--
Fix Version/s: (was: 1.3.12)
1.3.13
> Configuration to rank exact match suggestions over partial match suggestions
>
>
> Key: OAK-3406
> URL: https://issues.apache.org/jira/browse/OAK-3406
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
> Fix For: 1.3.13
>
>
> Currently, a suggestion query ranks the results according to popularity. But,
> at times, it's intended to have suggested phrases based on exact matches to
> be ranked above a more popular suggestion based on a partial match. e.g. a
> repository might have a 1000 docs with {{windows is a very popular OS}} and
> say 4 with {{win over them}} - it's a useful case to configure suggestions
> such that for a suggestions query for {{win}}, we'd get {{win over them}} as
> a higher ranked suggestion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3362) Estimate compaction based on diff to previous compacted head state
[ https://issues.apache.org/jira/browse/OAK-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-3362: -- Fix Version/s: (was: 1.3.12) 1.3.13 > Estimate compaction based on diff to previous compacted head state > -- > > Key: OAK-3362 > URL: https://issues.apache.org/jira/browse/OAK-3362 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: segmentmk >Reporter: Alex Parvulescu >Assignee: Alex Parvulescu >Priority: Minor > Labels: compaction, gc > Fix For: 1.3.13 > > > Food for thought: try to base the compaction estimation on a diff between the > latest compacted state and the current state. > Pros > * estimation duration would be proportional to number of changes on the > current head state > * using the size on disk as a reference, we could actually stop the > estimation early when we go over the gc threshold. > * data collected during this diff could in theory be passed as input to the > compactor so it could focus on compacting a specific subtree > Cons > * need to keep a reference to a previous compacted state. post-startup and > pre-compaction this might prove difficult (except maybe if we only persist > the revision similar to what the async indexer is doing currently) > * coming up with a threshold for running compaction might prove difficult > * diff might be costly, but still cheaper than the current full diff -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-1819) oak-solr-core test failures on Java 8
[
https://issues.apache.org/jira/browse/OAK-1819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-1819:
--
Fix Version/s: (was: 1.3.12)
1.3.13
> oak-solr-core test failures on Java 8
> -
>
> Key: OAK-1819
> URL: https://issues.apache.org/jira/browse/OAK-1819
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: solr
>Affects Versions: 1.0
> Environment: {noformat}
> Apache Maven 3.1.0 (893ca28a1da9d5f51ac03827af98bb730128f9f2; 2013-06-27
> 22:15:32-0400)
> Maven home: c:\Program Files\apache-maven-3.1.0
> Java version: 1.8.0, vendor: Oracle Corporation
> Java home: c:\Program Files\Java\jdk1.8.0\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
> {noformat}
>Reporter: Jukka Zitting
>Assignee: Tommaso Teofili
>Priority: Minor
> Labels: java8, test
> Fix For: 1.3.13
>
>
> The following {{oak-solr-core}} test failures occur when building Oak with
> Java 8:
> {noformat}
> Failed tests:
>
> testNativeMLTQuery(org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexQueryTest):
> expected: but was:
>
> testNativeMLTQueryWithStream(org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexQueryTest):
> expected: but was:
> {noformat}
> The cause of this might well be something as simple as the test case
> incorrectly expecting a specific ordering of search results.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2722) IndexCopier fails to delete older index directory upon reindex
[
https://issues.apache.org/jira/browse/OAK-2722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-2722:
--
Fix Version/s: (was: 1.3.12)
1.3.13
> IndexCopier fails to delete older index directory upon reindex
> --
>
> Key: OAK-2722
> URL: https://issues.apache.org/jira/browse/OAK-2722
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Labels: resilience
> Fix For: 1.3.13
>
>
> {{IndexCopier}} tries to remove the older index directory incase of reindex.
> This might fails on platform like Windows if the files are still memory
> mapped or are locked.
> For deleting directories we would need to take similar approach like being
> done with deleting old index files i.e. do retries later.
> Due to this following test fails on Windows (Per [~julian.resc...@gmx.de] )
> {noformat}
> Tests run: 9, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.07 sec <<<
> FAILURE!
> deleteOldPostReindex(org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopierTest)
> Time elapsed: 0.02 sec <<< FAILURE!
> java.lang.AssertionError: Old index directory should have been removed
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.assertTrue(Assert.java:43)
> at org.junit.Assert.assertFalse(Assert.java:68)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopierTest.deleteOldPostReindex(IndexCopierTest.java:160)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2847) Dependency cleanup
[ https://issues.apache.org/jira/browse/OAK-2847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-2847: -- Fix Version/s: (was: 1.3.12) 1.3.13 > Dependency cleanup > --- > > Key: OAK-2847 > URL: https://issues.apache.org/jira/browse/OAK-2847 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Michael Dürig >Assignee: Vikas Saurabh > Labels: technical_debt > Fix For: 1.3.13 > > > Early in the next release cycle we should go through the list of Oak's > dependencies and decide whether we have candidates we want to upgrade and > remove orphaned dependencies. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2629) Cleanup Oak Travis jobs
[ https://issues.apache.org/jira/browse/OAK-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-2629: -- Fix Version/s: (was: 1.3.12) 1.3.13 > Cleanup Oak Travis jobs > --- > > Key: OAK-2629 > URL: https://issues.apache.org/jira/browse/OAK-2629 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: it >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > Labels: CI > Fix For: 1.3.13 > > > Since we're moving toward Jenkins, let's remove the Travis jobs for Oak. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3717) Make it possible to declare SynonyFilter 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: (was: 1.3.12)
1.3.13
> Make it possible to declare SynonyFilter 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
> Fix For: 1.3.13
>
>
> 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
(v6.3.4#6332)
[jira] [Updated] (OAK-1610) Improved default indexing by JCR type in SolrIndexEditor
[ https://issues.apache.org/jira/browse/OAK-1610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-1610: -- Fix Version/s: (was: 1.3.12) 1.3.13 > Improved default indexing by JCR type in SolrIndexEditor > > > Key: OAK-1610 > URL: https://issues.apache.org/jira/browse/OAK-1610 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: solr >Reporter: Tommaso Teofili > Fix For: 1.3.13 > > > It'd be good to provide a typed indexing default so that properties of a > certain type can be mapped to certain Solr dynamic fields with dedicated > types. The infrastructure for doing that is already in place as per > OakSolrConfiguration#getFieldNameFor(Type) but the default configuration is > not properly set with a good mapping. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2808) Active deletion of 'deleted' Lucene index files from DataStore without relying on full scale Blob GC
[ https://issues.apache.org/jira/browse/OAK-2808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-2808: -- Fix Version/s: (was: 1.3.12) 1.3.13 > Active deletion of 'deleted' Lucene index files from DataStore without > relying on full scale Blob GC > > > Key: OAK-2808 > URL: https://issues.apache.org/jira/browse/OAK-2808 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Chetan Mehrotra >Assignee: Thomas Mueller > Labels: datastore, performance > Fix For: 1.3.13 > > Attachments: OAK-2808-1.patch, copyonread-stats.png > > > With storing of Lucene index files within DataStore our usage pattern > of DataStore has changed between JR2 and Oak. > With JR2 the writes were mostly application based i.e. if application > stores a pdf/image file then that would be stored in DataStore. JR2 by > default would not write stuff to DataStore. Further in deployment > where large number of binary content is present then systems tend to > share the DataStore to avoid duplication of storage. In such cases > running Blob GC is a non trivial task as it involves a manual step and > coordination across multiple deployments. Due to this systems tend to > delay frequency of GC > Now with Oak apart from application the Oak system itself *actively* > uses the DataStore to store the index files for Lucene and there the > churn might be much higher i.e. frequency of creation and deletion of > index file is lot higher. This would accelerate the rate of garbage > generation and thus put lot more pressure on the DataStore storage > requirements. > Discussion thread http://markmail.org/thread/iybd3eq2bh372zrl -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3090) Caching BlobStore implementation
[ https://issues.apache.org/jira/browse/OAK-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-3090: -- Fix Version/s: (was: 1.3.12) 1.3.13 > Caching BlobStore implementation > - > > Key: OAK-3090 > URL: https://issues.apache.org/jira/browse/OAK-3090 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: blob >Reporter: Chetan Mehrotra > Labels: performance, resilience > Fix For: 1.3.13 > > > Storing binaries in Mongo puts lots of pressure on the MongoDB for reads. To > reduce the read load it would be useful to have a filesystem based cache of > frequently used binaries. > This would be similar to CachingFDS (OAK-3005) but would be implemented on > top of BlobStore API. > Requirements > * Specify the max binary size which can be cached on file system > * Limit the size of all binary content present in the cache -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3176) Provide an option to include a configured boost query while searching
[ https://issues.apache.org/jira/browse/OAK-3176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-3176: -- Fix Version/s: (was: 1.3.12) 1.3.13 > Provide an option to include a configured boost query while searching > - > > Key: OAK-3176 > URL: https://issues.apache.org/jira/browse/OAK-3176 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: solr >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > Fix For: 1.2.9, 1.3.13 > > > For tweaking relevancy it's sometimes useful to include a boost query that > gets applied at query time and modifies the ranking accordingly. > This can be done also by setting it by hand as a default parameter to the > /select request handler, but for convenience it'd be good if the Solr > instance configuration files wouldn't be touched. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3730) RDBDocumentStore: implement RDB-specific VersionGC support for lookup of split documents
[ https://issues.apache.org/jira/browse/OAK-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044961#comment-15044961 ] Julian Reschke commented on OAK-3730: - Very good. This means that migration code could restrict itself to nodes where ID LIKE '_:p%', '__:p%' or '___:p%'... > RDBDocumentStore: implement RDB-specific VersionGC support for lookup of > split documents > > > Key: OAK-3730 > URL: https://issues.apache.org/jira/browse/OAK-3730 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke > Fix For: 1.4 > > > This requires a change to the table layout (adding SD_TYPE and more), thus > needs thought about how to migrate from older versions of the persistence. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3436) Prevent missing checkpoint due to unstable topology from causing complete reindexing
[
https://issues.apache.org/jira/browse/OAK-3436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-3436:
--
Fix Version/s: (was: 1.3.12)
1.3.13
> Prevent missing checkpoint due to unstable topology from causing complete
> reindexing
>
>
> Key: OAK-3436
> URL: https://issues.apache.org/jira/browse/OAK-3436
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Chetan Mehrotra
>Assignee: Alex Parvulescu
> Labels: resilience
> Fix For: 1.2.9, 1.0.25, 1.3.13
>
> Attachments: AsyncIndexUpdateClusterTest.java, OAK-3436-0.patch,
> OAK-3436-tests.patch
>
>
> Async indexing logic relies on embedding application to ensure that async
> indexing job is run as a singleton in a cluster. For Sling based apps it
> depends on Sling Discovery support. At times it is being seen that if
> topology is not stable then different cluster nodes can consider them as
> leader and execute the async indexing job concurrently.
> This can cause problem as both cluster node might not see same repository
> state (due to write skew and eventual consistency) and might remove the
> checkpoint which other cluster node is still relying upon. For e.g. consider
> a 2 node cluster N1 and N2 where both are performing async indexing.
> # Base state - CP1 is the checkpoint for "async" job
> # N2 starts indexing and removes changes CP1 to CP2. For Mongo the
> checkpoints are saved in {{settings}} collection
> # N1 also decides to execute indexing but has yet not seen the latest
> repository state so still thinks that CP1 is the base checkpoint and tries to
> read it. However CP1 is already removed from {{settings}} and this makes N1
> think that checkpoint is missing and it decides to reindex everything!
> To avoid this topology must be stable but at Oak level we should still handle
> such a case and avoid doing a full reindexing. So we would need to have a
> {{MissingCheckpointStrategy}} similar to {{MissingIndexEditorStrategy}} as
> done in OAK-2203
> Possible approaches
> # A1 - Fail the indexing run if checkpoint is missing - Checkpoint being
> missing can have valid reason and invalid reason. Need to see what are valid
> scenarios where a checkpoint can go missing
> # A2 - When a checkpoint is created also store the creation time. When a
> checkpoint is found to be missing and its a *recent* checkpoint then fail the
> run. For e.g. we would fail the run till checkpoint found to be missing is
> less than an hour old (for just started take startup time into account)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-3669) Update jackrabbit.version to regular non-snapshot version
[ https://issues.apache.org/jira/browse/OAK-3669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella resolved OAK-3669. --- Resolution: Duplicate Duplicate of OAK-3708 > Update jackrabbit.version to regular non-snapshot version > - > > Key: OAK-3669 > URL: https://issues.apache.org/jira/browse/OAK-3669 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: angela >Priority: Blocker > Fix For: 1.3.12 > > > see OAK-3632 and JCR-3933 for details. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-3613) Backport TarMK revision gc related issues
[ https://issues.apache.org/jira/browse/OAK-3613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14998629#comment-14998629 ] Michael Dürig edited comment on OAK-3613 at 12/7/15 1:34 PM: - OAK-2734: Compaction does not finish on repository with continuous writes ([1675311|http://svn.apache.org/r1675311]) OAK-2862: CompactionMap#compress() inefficient for large compaction maps ([1678958|http://svn.apache.org/r1678958], [1679959|http://svn.apache.org/r1679959], [1679995|http://svn.apache.org/r1679995], [1683780|http://svn.apache.org/r1683780]) OAK-2713: High memory usage of CompactionMap ([1679958|http://svn.apache.org/r1679958]) (1.0 only) OAK-2849: Improve revision gc on SegmentMK ([1691216|http://svn.apache.org/r1691216], [1693194|http://svn.apache.org/r1693194]) OAK-3094: Potential ClassCastException with LIRS cache builder ([1690657|http://svn.apache.org/r1690657], [1690672|http://svn.apache.org/r1690672]) OAK-3095: Add eviction listener to LIRS cache ([1690991|http://svn.apache.org/r1690991]) OAK-3007: SegmentStore cache does not take "string" map into account ([1691217|http://svn.apache.org/r1691217], [1691218|http://svn.apache.org/r1691218]) OAK-3055: Improve segment cache in SegmentTracker ([1691219|http://svn.apache.org/r1691219], [1691220|http://svn.apache.org/r1691220]) OAK-3109: OOME in tarkmk standby tests ([1692272|http://svn.apache.org/r1692272], [1695829|http://svn.apache.org/r1695829], [1695830|http://svn.apache.org/r1695830]) OAK-3051: Improve compaction gain estimation logging for the case where there are no tar readers ([1691589|http://svn.apache.org/r1691589]) OAK-2384: SegmentNotFoundException when keeping JCR Value references ([1650503|http://svn.apache.org/r1650503], [1670137|http://svn.apache.org/r1670137]) (1.0 only) OAK-3095: Add eviction listener to LIRS cache ([1692234|http://svn.apache.org/r1692234]) OAK-3055: Improve segment cache in SegmentTracker ([1692235|http://svn.apache.org/r1692235]) OAK-3139: SNFE in persisted comapation map when using CLEAN_OLD ([1693022|http://svn.apache.org/r1693022], [1693195|http://svn.apache.org/r1693195]) OAK-3168: SegmentCache flushes Segment on update ([1694022|http://svn.apache.org/r1694022]) OAK-3179: Deadlock between persisted compaction map and cleanup ([1694208|http://svn.apache.org/r1694208]) OAK-3177: Compaction slow on repository with continuous writes ([1694497|http://svn.apache.org/r1694497]) OAK-3264: Deadlock between persisted compaction map and cleanup 2 ( [1696956|http://svn.apache.org/r1696956]) OAK-2875: Namespaces keep references to old node states ([1697423|http://svn.apache.org/r1697423]) OAK-3317: ConcurrentModificationException when running SegmentOverflowExceptionIT ([1700252|http://svn.apache.org/r1700252]) OAK-3347: Ineffective cleanup after compaction due to references to root ([1701239|http://svn.apache.org/r1701239]) OAK-3329: TarMK cleanup blocks writers ([1706818|http://svn.apache.org/r1706818]) OAK-3481: CompationMapTest does not close file store ([1706974|http://svn.apache.org/r1706974]) OAK-3172: Unreleased closed sessions can keep a root reference from getting collected ([1707073|http://svn.apache.org/r1707073]) OAK-3502: Improve logging during cleanup ([1707753|http://svn.apache.org/r1707753]) OAK-3501: PersistedCompactionMap could release reference to records early ([1708051|http://svn.apache.org/r1708051]) OAK-3511: Test failure: CompactionMapTest.removeSome ([1708297|http://svn.apache.org/r1708297], [1708298|http://svn.apache.org/r1708298]) OAK-3330: FileStore lock contention with concurrent writers ([1708401|http://svn.apache.org/r1708401], [1708402|http://svn.apache.org/r1708402], [1708403|http://svn.apache.org/r1708403]) OAK-3506: Uniformization of compaction log messages ([1708447|http://svn.apache.org/r1708447], [1710629|http://svn.apache.org/r1710629]) OAK-2581: Metatype info for SegmentNodeStoreService ([1664942|http://svn.apache.org/r1664942]) (1.0 only) OAK-2870: Introduce a SegmentNodeStoreBuilder to help wire a SegmentNodeStore ([1679998|http://svn.apache.org/r1679998]) OAK-3123: NPE in RecordIdMap ([1691965|http://svn.apache.org/r1691965]) OAK-1446: Offline tool to repair TarMK ([1586363|http://svn.apache.org/r1586363]) (1.0 only) OAK-3158: IAE when specifiying 2G cache for FileStore ([1694639|http://svn.apache.org/r1694639], [1702240|http://svn.apache.org/r1702240]) OAK-2962: SegmentNodeStoreService fails to handle empty strings in the OSGi configuration ([1687171|http://svn.apache.org/r1687171]) OAK-3048: Enable lookup of OSGi configuration from framework first and component next ([1693868|http://svn.apache.org/r1693868]) OAK-3052: Make compaction gain estimate threshold configurable ([1689805|http://svn.apache.org/r1689805]) OAK-3125: Skip compaction estimation if threshold is 0 ([1692063|http://svn.apache.org/r1692063], [1692366|
[jira] [Resolved] (OAK-3708) Update Oak to Jackrabbit 2.11.3
[ https://issues.apache.org/jira/browse/OAK-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella resolved OAK-3708. --- Resolution: Fixed in trunk at https://svn.apache.org/r1718348 > Update Oak to Jackrabbit 2.11.3 > --- > > Key: OAK-3708 > URL: https://issues.apache.org/jira/browse/OAK-3708 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Davide Giannella >Assignee: Davide Giannella >Priority: Blocker > Fix For: 1.4, 1.3.12 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-3737) Compactor should log revisions acting upon
[ https://issues.apache.org/jira/browse/OAK-3737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig resolved OAK-3737. Resolution: Fixed Fixed at http://svn.apache.org/viewvc?view=revision&revision=1718340 > Compactor should log revisions acting upon > -- > > Key: OAK-3737 > URL: https://issues.apache.org/jira/browse/OAK-3737 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: segmentmk >Reporter: Michael Dürig >Assignee: Michael Dürig >Priority: Blocker > Labels: compaction, gc > Fix For: 1.3.12 > > > For post mortem analysis it would be helpful to have the revisions that where > involved in a compaction run. I.e. the revision that was compacted, the > revisions of the cycles (if any) and the revision that is ultimately applied? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3436) Prevent missing checkpoint due to unstable topology from causing complete reindexing
[
https://issues.apache.org/jira/browse/OAK-3436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu updated OAK-3436:
-
Attachment: OAK-3436-tests.patch
attaching proposed test POC. I think simplifying the test setup helps with
clearer tests and expectations, but this means I had to refactor the existing
code a bit. For now patch only has tests (failing ones too), not fix, this is
just to validate the approach. further work would bring in a fix and more tests.
Besides the fact that I've reproduced the original issue (see
{{testPrePrepare}}), I think there's another issue here with the lease
mechanism during reindexing (see {{testPrePrepareRexindex}}, I'll fix the name
in a future iteration).
[~chetanm] looking forward to your thoughts on the patch!
> Prevent missing checkpoint due to unstable topology from causing complete
> reindexing
>
>
> Key: OAK-3436
> URL: https://issues.apache.org/jira/browse/OAK-3436
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Chetan Mehrotra
>Assignee: Alex Parvulescu
> Labels: resilience
> Fix For: 1.2.9, 1.0.25, 1.3.12
>
> Attachments: AsyncIndexUpdateClusterTest.java, OAK-3436-0.patch,
> OAK-3436-tests.patch
>
>
> Async indexing logic relies on embedding application to ensure that async
> indexing job is run as a singleton in a cluster. For Sling based apps it
> depends on Sling Discovery support. At times it is being seen that if
> topology is not stable then different cluster nodes can consider them as
> leader and execute the async indexing job concurrently.
> This can cause problem as both cluster node might not see same repository
> state (due to write skew and eventual consistency) and might remove the
> checkpoint which other cluster node is still relying upon. For e.g. consider
> a 2 node cluster N1 and N2 where both are performing async indexing.
> # Base state - CP1 is the checkpoint for "async" job
> # N2 starts indexing and removes changes CP1 to CP2. For Mongo the
> checkpoints are saved in {{settings}} collection
> # N1 also decides to execute indexing but has yet not seen the latest
> repository state so still thinks that CP1 is the base checkpoint and tries to
> read it. However CP1 is already removed from {{settings}} and this makes N1
> think that checkpoint is missing and it decides to reindex everything!
> To avoid this topology must be stable but at Oak level we should still handle
> such a case and avoid doing a full reindexing. So we would need to have a
> {{MissingCheckpointStrategy}} similar to {{MissingIndexEditorStrategy}} as
> done in OAK-2203
> Possible approaches
> # A1 - Fail the indexing run if checkpoint is missing - Checkpoint being
> missing can have valid reason and invalid reason. Need to see what are valid
> scenarios where a checkpoint can go missing
> # A2 - When a checkpoint is created also store the creation time. When a
> checkpoint is found to be missing and its a *recent* checkpoint then fail the
> run. For e.g. we would fail the run till checkpoint found to be missing is
> less than an hour old (for just started take startup time into account)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3708) Update Oak to Jackrabbit 2.11.3
[ https://issues.apache.org/jira/browse/OAK-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-3708: -- Fix Version/s: 1.4 > Update Oak to Jackrabbit 2.11.3 > --- > > Key: OAK-3708 > URL: https://issues.apache.org/jira/browse/OAK-3708 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Davide Giannella >Assignee: Davide Giannella >Priority: Blocker > Fix For: 1.4, 1.3.12 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3737) Compactor should log revisions acting upon
[ https://issues.apache.org/jira/browse/OAK-3737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-3737: --- Priority: Blocker (was: Major) > Compactor should log revisions acting upon > -- > > Key: OAK-3737 > URL: https://issues.apache.org/jira/browse/OAK-3737 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: segmentmk >Reporter: Michael Dürig >Assignee: Michael Dürig >Priority: Blocker > Labels: compaction, gc > Fix For: 1.3.12 > > > For post mortem analysis it would be helpful to have the revisions that where > involved in a compaction run. I.e. the revision that was compacted, the > revisions of the cycles (if any) and the revision that is ultimately applied? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3737) Compactor should log revisions acting upon
[ https://issues.apache.org/jira/browse/OAK-3737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044796#comment-15044796 ] Michael Dürig commented on OAK-3737: Making this a blocker so we can get it into the Oak 1.3.12 /cc [~edivad], [~dhasler] > Compactor should log revisions acting upon > -- > > Key: OAK-3737 > URL: https://issues.apache.org/jira/browse/OAK-3737 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: segmentmk >Reporter: Michael Dürig >Assignee: Michael Dürig >Priority: Blocker > Labels: compaction, gc > Fix For: 1.3.12 > > > For post mortem analysis it would be helpful to have the revisions that where > involved in a compaction run. I.e. the revision that was compacted, the > revisions of the cycles (if any) and the revision that is ultimately applied? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-3737) Compactor should log revisions acting upon
Michael Dürig created OAK-3737: -- Summary: Compactor should log revisions acting upon Key: OAK-3737 URL: https://issues.apache.org/jira/browse/OAK-3737 Project: Jackrabbit Oak Issue Type: Improvement Components: segmentmk Reporter: Michael Dürig Assignee: Michael Dürig Fix For: 1.3.12 For post mortem analysis it would be helpful to have the revisions that where involved in a compaction run. I.e. the revision that was compacted, the revisions of the cycles (if any) and the revision that is ultimately applied? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3737) Compactor should log revisions acting upon
[ https://issues.apache.org/jira/browse/OAK-3737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-3737: --- Issue Type: Technical task (was: Improvement) Parent: OAK-2403 > Compactor should log revisions acting upon > -- > > Key: OAK-3737 > URL: https://issues.apache.org/jira/browse/OAK-3737 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: segmentmk >Reporter: Michael Dürig >Assignee: Michael Dürig > Labels: compaction, gc > Fix For: 1.3.12 > > > For post mortem analysis it would be helpful to have the revisions that where > involved in a compaction run. I.e. the revision that was compacted, the > revisions of the cycles (if any) and the revision that is ultimately applied? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-3352) Expose Lucene search score explanation
[
https://issues.apache.org/jira/browse/OAK-3352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh resolved OAK-3352.
Resolution: Fixed
Bumped package version of org.apache.jackrabbit.oak.query at
[r1718310|http://svn.apache.org/r1718310].
Resolving again.
> Expose Lucene search score explanation
> ---
>
> Key: OAK-3352
> URL: https://issues.apache.org/jira/browse/OAK-3352
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: lucene, query
>Reporter: Chetan Mehrotra
>Assignee: Vikas Saurabh
> Fix For: 1.3.12
>
> Attachments: OAK-3352.patch
>
>
> Lucene provides {{Explanation}} [1] support to understand how the score for a
> particular search result is determined. To enable users to reason out about
> fulltext search results in Oak we should expose this information as part of
> query result
> [1]
> https://lucene.apache.org/core/4_0_0/core/org/apache/lucene/search/Explanation.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-3732) Offline compaction doesn't clean up unreferenced tar files
[
https://issues.apache.org/jira/browse/OAK-3732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig resolved OAK-3732.
Resolution: Fixed
Fix Version/s: 1.3.12
Fixed at http://svn.apache.org/viewvc?rev=1718309&view=rev
> Offline compaction doesn't clean up unreferenced tar files
> --
>
> Key: OAK-3732
> URL: https://issues.apache.org/jira/browse/OAK-3732
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segmentmk
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: cleanup, gc
> Fix For: 1.3.12
>
>
> This is a regression introduced with OAK-3329 where cleaning up unreferenced
> tar files was taken out of {{FileStore#cleanup}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3694) As a user, I want to know when a node that I've created has been indexed.
[
https://issues.apache.org/jira/browse/OAK-3694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044760#comment-15044760
]
Valentin Olteanu commented on OAK-3694:
---
[~chetanm], as discussed during the oakathon, I've updated the story with the
requirements. Thierry had proposed a solution on OAK-3606, but please comment
with any idea that you have on this.
It would be really helpful to have this done in a reliable way.
Thanks!
> As a user, I want to know when a node that I've created has been indexed.
> -
>
> Key: OAK-3694
> URL: https://issues.apache.org/jira/browse/OAK-3694
> Project: Jackrabbit Oak
> Issue Type: Story
>Reporter: Valentin Olteanu
>
> As a user, I want to know when a node that I've created has been indexed so
> that I can start using it.
> Generalization: As a user, I want to know when everything created before
> timestamp T0 has been indexed.
> Ideal solution: MBean operation {{bool isIndexedBefore(long timestamp)}} that
> returns {{true}} if everything created before {{timestamp}} has been indexed
> (by all indexers).
> Current options:
> # check IndexStatsMBean for Start and Done to determine if a cycle has
> started after adding the node and has finished. Issue: there can be multiple
> async indexers. OAK-3606 proposes a solution.
> # add a node and search for it until it is retrieved. Issue: must add
> different nodes for different indexers and wait for all.
> These options are not precise (give false positives) and are not resilient to
> changes in indexing strategy (e.g. adding one more indexer breaks the
> checks).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3694) As a user, I want to know when a node that I've created has been indexed.
[
https://issues.apache.org/jira/browse/OAK-3694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Olteanu updated OAK-3694:
--
Description:
As a user, I want to know when a node that I've created has been indexed so
that I can start using it.
Generalization: As a user, I want to know when everything created before
timestamp T0 has been indexed.
Ideal solution: MBean operation {{bool isIndexedBefore(long timestamp)}} that
returns {{true}} if everything created before {{timestamp}} has been indexed
(by all indexers).
Current options:
# check IndexStatsMBean for Start and Done to determine if a cycle has started
after adding the node and has finished. Issue: there can be multiple async
indexers. OAK-3606 proposes a solution.
# add a node and search for it until it is retrieved. Issue: must add different
nodes for different indexers and wait for all.
These options are not precise (give false positives) and are not resilient to
changes in indexing strategy (e.g. adding one more indexer breaks the checks).
was:
As a user, I want to know when a node that I've created has been indexed so
that I can start using it.
Generalization: As a user, I want to know when everything created before
timestamp T0 has been indexed.
Current options: (1) check
> As a user, I want to know when a node that I've created has been indexed.
> -
>
> Key: OAK-3694
> URL: https://issues.apache.org/jira/browse/OAK-3694
> Project: Jackrabbit Oak
> Issue Type: Story
>Reporter: Valentin Olteanu
>
> As a user, I want to know when a node that I've created has been indexed so
> that I can start using it.
> Generalization: As a user, I want to know when everything created before
> timestamp T0 has been indexed.
> Ideal solution: MBean operation {{bool isIndexedBefore(long timestamp)}} that
> returns {{true}} if everything created before {{timestamp}} has been indexed
> (by all indexers).
> Current options:
> # check IndexStatsMBean for Start and Done to determine if a cycle has
> started after adding the node and has finished. Issue: there can be multiple
> async indexers. OAK-3606 proposes a solution.
> # add a node and search for it until it is retrieved. Issue: must add
> different nodes for different indexers and wait for all.
> These options are not precise (give false positives) and are not resilient to
> changes in indexing strategy (e.g. adding one more indexer breaks the
> checks).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3694) As a user, I want to know when a node that I've created has been indexed.
[ https://issues.apache.org/jira/browse/OAK-3694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Olteanu updated OAK-3694: -- Description: As a user, I want to know when a node that I've created has been indexed so that I can start using it. Generalization: As a user, I want to know when everything created before timestamp T0 has been indexed. Current options: (1) check was: As a user, I want to know when a node that I've created has been indexed so that I can start using it. Generalization: As a user, I want to know when everything created before timestamp T0 has been indexed. > As a user, I want to know when a node that I've created has been indexed. > - > > Key: OAK-3694 > URL: https://issues.apache.org/jira/browse/OAK-3694 > Project: Jackrabbit Oak > Issue Type: Story >Reporter: Valentin Olteanu > > As a user, I want to know when a node that I've created has been indexed so > that I can start using it. > Generalization: As a user, I want to know when everything created before > timestamp T0 has been indexed. > Current options: (1) check -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (OAK-3352) Expose Lucene search score explanation
[
https://issues.apache.org/jira/browse/OAK-3352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger reopened OAK-3352:
---
Re-opening, because baseline plugin complains about required version increase:
{noformat}
org.apache.jackrabbit.oak.query: Version increase required; detected 4.0.0,
suggested 4.1.0
{noformat}
> Expose Lucene search score explanation
> ---
>
> Key: OAK-3352
> URL: https://issues.apache.org/jira/browse/OAK-3352
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: lucene, query
>Reporter: Chetan Mehrotra
>Assignee: Vikas Saurabh
> Fix For: 1.3.12
>
> Attachments: OAK-3352.patch
>
>
> Lucene provides {{Explanation}} [1] support to understand how the score for a
> particular search result is determined. To enable users to reason out about
> fulltext search results in Oak we should expose this information as part of
> query result
> [1]
> https://lucene.apache.org/core/4_0_0/core/org/apache/lucene/search/Explanation.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3642) Enable failing of commit upon Missing IndexEditor implementation by default
[ https://issues.apache.org/jira/browse/OAK-3642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated OAK-3642: - Fix Version/s: (was: 1.3.12) 1.3.13 > Enable failing of commit upon Missing IndexEditor implementation by default > --- > > Key: OAK-3642 > URL: https://issues.apache.org/jira/browse/OAK-3642 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: 1.3.13 > > > With OAK-3505 we exposed config option to enable failing of commit if any > IndexEditor is missing. The default should be changed to always fail the > commit -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2719) Warn about local copy size different than remote copy in oak-lucene with copyOnRead enabled
[
https://issues.apache.org/jira/browse/OAK-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-2719:
-
Fix Version/s: (was: 1.3.12)
> Warn about local copy size different than remote copy in oak-lucene with
> copyOnRead enabled
> ---
>
> Key: OAK-2719
> URL: https://issues.apache.org/jira/browse/OAK-2719
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Labels: resilience
>
> At times following warning is seen in logs
> {noformat}
> 31.03.2015 14:04:57.610 *WARN* [pool-6-thread-7]
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopier Found local copy
> for _0.cfs in
> NIOFSDirectory@/path/to/index/e5a943cdec3000bd8ce54924fd2070ab5d1d35b9ecf530963a3583d43bf28293/1
>
> lockFactory=NativeFSLockFactory@/path/to/index/e5a943cdec3000bd8ce54924fd2070ab5d1d35b9ecf530963a3583d43bf28293/1
> but size of local 1040384 differs from remote 1958385. Content would be read
> from remote file only
> {noformat}
> The file length check provides a weak check around index file consistency. In
> some cases this warning is misleading. For e.g.
> # Index version Rev1 - Task submitted to copy index file F1
> # Index updated to Rev2 - Directory bound to Rev1 is closed
> # Read is performed with Rev2 for F1 - Here as the file would be locally
> created the size would be different as the copying is in progress
> In such a case the logic should ensure that once copy is done the local file
> gets used
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2719) Warn about local copy size different than remote copy in oak-lucene with copyOnRead enabled
[
https://issues.apache.org/jira/browse/OAK-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044719#comment-15044719
]
Chetan Mehrotra commented on OAK-2719:
--
Chances of this scenario are greatly reduced with prefetching of index files
enabled by default as then there is no race condition.
> Warn about local copy size different than remote copy in oak-lucene with
> copyOnRead enabled
> ---
>
> Key: OAK-2719
> URL: https://issues.apache.org/jira/browse/OAK-2719
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Labels: resilience
>
> At times following warning is seen in logs
> {noformat}
> 31.03.2015 14:04:57.610 *WARN* [pool-6-thread-7]
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopier Found local copy
> for _0.cfs in
> NIOFSDirectory@/path/to/index/e5a943cdec3000bd8ce54924fd2070ab5d1d35b9ecf530963a3583d43bf28293/1
>
> lockFactory=NativeFSLockFactory@/path/to/index/e5a943cdec3000bd8ce54924fd2070ab5d1d35b9ecf530963a3583d43bf28293/1
> but size of local 1040384 differs from remote 1958385. Content would be read
> from remote file only
> {noformat}
> The file length check provides a weak check around index file consistency. In
> some cases this warning is misleading. For e.g.
> # Index version Rev1 - Task submitted to copy index file F1
> # Index updated to Rev2 - Directory bound to Rev1 is closed
> # Read is performed with Rev2 for F1 - Here as the file would be locally
> created the size would be different as the copying is in progress
> In such a case the logic should ensure that once copy is done the local file
> gets used
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3185) Port and refactor jackrabbit-webapp module to Oak
[ https://issues.apache.org/jira/browse/OAK-3185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated OAK-3185: - Fix Version/s: (was: 1.3.12) 1.4 > Port and refactor jackrabbit-webapp module to Oak > -- > > Key: OAK-3185 > URL: https://issues.apache.org/jira/browse/OAK-3185 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: webapp >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: 1.4 > > > As mentioned at [1] we should port the jackrabbit-webapp [2] module to Oak > and refactor it to run complete Oak stack. Purpose of this module would be to > demonstrate > # How to embed Oak in standalone web applications which are not based on OSGi > # Configure various aspect of Oak via config > h3. Proposed Appraoch > # Copy jackrabbit-webapp to Oak repo under oak-webapp > # Refactor the repository initialization logic to use Oak Pojosr to configure > Repository [3] > # Bonus configure Felix WebConsole to enable users to see what all OSGi > services are exposed and what config options are supported > This would also enable us to document what all thirdparty dependencies are > required for getting Oak to work in such environments > [1] > http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201508.mbox/%3CCAHCW-mkbpS6qSkgFe1h1anFcD-dYWFrcr9xBWx9dpKaxr91Q3Q%40mail.gmail.com%3E > [2] > https://jackrabbit.apache.org/jcr/components/jackrabbit-web-application.html > [3] https://github.com/apache/jackrabbit-oak/tree/trunk/oak-pojosr -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3629) Index corruption seen with CopyOnRead when index defnition is recreated
[
https://issues.apache.org/jira/browse/OAK-3629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-3629:
-
Fix Version/s: (was: 1.3.12)
1.3.13
> Index corruption seen with CopyOnRead when index defnition is recreated
> ---
>
> Key: OAK-3629
> URL: https://issues.apache.org/jira/browse/OAK-3629
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.3.13
>
>
> CopyOnRead logic relies on {{reindexCount}} to determine the name of
> directory in which index files would be copied. In normal flow if the index
> is reindexed then this count would get increased and newer index files would
> get copied to a new directory.
> However if the index definition node gets recreated due to some deployment
> process then this count gets reset to 0. Due to which newly created index
> files from reindexing would start getting copied to already existing
> directory and that can lead to corruption.
> So what happened here was
> # System started with index definition I1 and indexing got complete with
> index files saved under index/hash(indexpath)/1 (where 1 is current reindex
> count)
> # A new index definition package was deployed which reset the index count.
> Now reindex happened again and the CopyOnRead logic per current design reused
> the existing index directory. And it so happens that Lucene create file with
> same name and same size but different content. This trips the CopyOnRead
> defense of length based index corruption check and thus cause new lucene
> index to corrupt
> *Note that here corruption is transient i.e. persisted index is not
> corrupted*. Just that locally copied index gets corrupted. Cleaning up the
> index directory would fix the issue and that can be used as a workaround.
> *Fix*
> After discussing with [~tmueller] following approach can be used.
> Instead of relying on reindex count we can maintain a hidden randomly
> generated uuid and store it in the index config. This would be used to derive
> the name of directory on filesystem. If the index definition gets reset then
> the uuid can be regenerated.
> *Workaround*
> Clean the directory used by CopyOnRead which is /index before
> restart
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3319) Disabling IndexRule inheritence is not working in all cases
[
https://issues.apache.org/jira/browse/OAK-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-3319:
-
Fix Version/s: (was: 1.3.12)
> Disabling IndexRule inheritence is not working in all cases
> ---
>
> Key: OAK-3319
> URL: https://issues.apache.org/jira/browse/OAK-3319
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
>
> IndexRules are inherited by default i.e. a rule defined for nt:hierrachyNode
> is also applicable for nt:folder (nt:folder extends nt:hierrachyNode). Lucene
> indexing supports {{inherited}} floag (defaults to true). If this is set to
> false then inheritance is disabled.
> As per current implementation disabling works fine on indexing side. An node
> which is not having an explicit indexRule defined is not indexed. However
> same is not working on query side i.e. IndexPlanner would still opt in for a
> given query ignoring the fact that inheritance is disabled
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2910) oak-jcr bundle should be usable as a standalone bundle
[ https://issues.apache.org/jira/browse/OAK-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated OAK-2910: - Fix Version/s: (was: 1.3.12) 1.4 > oak-jcr bundle should be usable as a standalone bundle > -- > > Key: OAK-2910 > URL: https://issues.apache.org/jira/browse/OAK-2910 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: jcr >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Labels: modularization, osgi, technical_debt > Fix For: 1.4 > > > Currently oak-jcr bundle needs to be embedded within some other bundle if the > Oak needs to be properly configured in OSGi env. Need to revisit this aspect > and see what needs to be done to enable Oak to be properly configured without > requiring the oak-jcr bundle to be embedded in the repo -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3598) Export cache related classes for usage in other oak bundle
[
https://issues.apache.org/jira/browse/OAK-3598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-3598:
-
Fix Version/s: (was: 1.3.12)
1.4
> Export cache related classes for usage in other oak bundle
> --
>
> Key: OAK-3598
> URL: https://issues.apache.org/jira/browse/OAK-3598
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: cache
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.4
>
>
> For OAK-3092 oak-lucene would need to access classes from
> {{org.apache.jackrabbit.oak.cache}} package. For now its limited to
> {{CacheStats}} to expose the cache related statistics.
> This task is meant to determine steps needed to export the package
> * Update the pom.xml to export the package
> * Review current set of classes to see if they need to be reviewed
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3126) Enable HybridMapFactory by default
[ https://issues.apache.org/jira/browse/OAK-3126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-3126: -- Fix Version/s: (was: 1.0.25) 1.0.26 > Enable HybridMapFactory by default > -- > > Key: OAK-3126 > URL: https://issues.apache.org/jira/browse/OAK-3126 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Fix For: 1.0.26 > > > This is a follow up issue of OAK-3112. The HybridMapFactory should be enabled > by default once it has proven to be stable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2592) Commit does not ensure w:majority
[
https://issues.apache.org/jira/browse/OAK-2592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-2592:
--
Fix Version/s: (was: 1.3.12)
1.3.13
> 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.13
>
>
> 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] [Updated] (OAK-3649) Extract node document cache from Mongo and RDB document stores
[ https://issues.apache.org/jira/browse/OAK-3649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-3649: -- Fix Version/s: (was: 1.3.12) 1.3.13 > Extract node document cache from Mongo and RDB document stores > -- > > Key: OAK-3649 > URL: https://issues.apache.org/jira/browse/OAK-3649 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk, mongomk, rdbmk >Reporter: Tomek Rękawek >Assignee: Marcel Reutegger >Priority: Minor > Labels: candidate_oak_1_0, candidate_oak_1_2 > Fix For: 1.3.13 > > > MongoDocumentStore and RDBDocumentStore contains copy & pasted methods > responsible for handling node document cache. Extract these into a new > NodeDocumentCache. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (OAK-3649) Extract node document cache from Mongo and RDB document stores
[ https://issues.apache.org/jira/browse/OAK-3649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger reassigned OAK-3649: - Assignee: Marcel Reutegger > Extract node document cache from Mongo and RDB document stores > -- > > Key: OAK-3649 > URL: https://issues.apache.org/jira/browse/OAK-3649 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk, mongomk, rdbmk >Reporter: Tomek Rękawek >Assignee: Marcel Reutegger >Priority: Minor > Labels: candidate_oak_1_0, candidate_oak_1_2 > Fix For: 1.3.12 > > > MongoDocumentStore and RDBDocumentStore contains copy & pasted methods > responsible for handling node document cache. Extract these into a new > NodeDocumentCache. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-3736) Document changing OOTB index definitions
Davide Giannella created OAK-3736: - Summary: Document changing OOTB index definitions Key: OAK-3736 URL: https://issues.apache.org/jira/browse/OAK-3736 Project: Jackrabbit Oak Issue Type: Documentation Components: doc Reporter: Davide Giannella Assignee: Davide Giannella Fix For: 1.4 Provide a documentation that highlights best practices around updating OOTB index definitions to meet custom requirements. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-3735) Release Oak 1.2.9
Davide Giannella created OAK-3735: - Summary: Release Oak 1.2.9 Key: OAK-3735 URL: https://issues.apache.org/jira/browse/OAK-3735 Project: Jackrabbit Oak Issue Type: Task Reporter: Davide Giannella Assignee: Davide Giannella Fix For: 1.4 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-3734) Release Oak 1.3.12
Davide Giannella created OAK-3734: - Summary: Release Oak 1.3.12 Key: OAK-3734 URL: https://issues.apache.org/jira/browse/OAK-3734 Project: Jackrabbit Oak Issue Type: Task Reporter: Davide Giannella Assignee: Davide Giannella Fix For: 1.4 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3436) Prevent missing checkpoint due to unstable topology from causing complete reindexing
[
https://issues.apache.org/jira/browse/OAK-3436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044601#comment-15044601
]
Alex Parvulescu commented on OAK-3436:
--
fyi I'm working on a patch for this issue, but it's more involved than I
originally thought, so it's going to be a few more days before I can attach
something
> Prevent missing checkpoint due to unstable topology from causing complete
> reindexing
>
>
> Key: OAK-3436
> URL: https://issues.apache.org/jira/browse/OAK-3436
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Chetan Mehrotra
>Assignee: Alex Parvulescu
> Labels: resilience
> Fix For: 1.2.9, 1.0.25, 1.3.12
>
> Attachments: AsyncIndexUpdateClusterTest.java, OAK-3436-0.patch
>
>
> Async indexing logic relies on embedding application to ensure that async
> indexing job is run as a singleton in a cluster. For Sling based apps it
> depends on Sling Discovery support. At times it is being seen that if
> topology is not stable then different cluster nodes can consider them as
> leader and execute the async indexing job concurrently.
> This can cause problem as both cluster node might not see same repository
> state (due to write skew and eventual consistency) and might remove the
> checkpoint which other cluster node is still relying upon. For e.g. consider
> a 2 node cluster N1 and N2 where both are performing async indexing.
> # Base state - CP1 is the checkpoint for "async" job
> # N2 starts indexing and removes changes CP1 to CP2. For Mongo the
> checkpoints are saved in {{settings}} collection
> # N1 also decides to execute indexing but has yet not seen the latest
> repository state so still thinks that CP1 is the base checkpoint and tries to
> read it. However CP1 is already removed from {{settings}} and this makes N1
> think that checkpoint is missing and it decides to reindex everything!
> To avoid this topology must be stable but at Oak level we should still handle
> such a case and avoid doing a full reindexing. So we would need to have a
> {{MissingCheckpointStrategy}} similar to {{MissingIndexEditorStrategy}} as
> done in OAK-2203
> Possible approaches
> # A1 - Fail the indexing run if checkpoint is missing - Checkpoint being
> missing can have valid reason and invalid reason. Need to see what are valid
> scenarios where a checkpoint can go missing
> # A2 - When a checkpoint is created also store the creation time. When a
> checkpoint is found to be missing and its a *recent* checkpoint then fail the
> run. For e.g. we would fail the run till checkpoint found to be missing is
> less than an hour old (for just started take startup time into account)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (OAK-3436) Prevent missing checkpoint due to unstable topology from causing complete reindexing
[
https://issues.apache.org/jira/browse/OAK-3436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu reassigned OAK-3436:
Assignee: Alex Parvulescu (was: Chetan Mehrotra)
> Prevent missing checkpoint due to unstable topology from causing complete
> reindexing
>
>
> Key: OAK-3436
> URL: https://issues.apache.org/jira/browse/OAK-3436
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Chetan Mehrotra
>Assignee: Alex Parvulescu
> Labels: resilience
> Fix For: 1.2.9, 1.0.25, 1.3.12
>
> Attachments: AsyncIndexUpdateClusterTest.java, OAK-3436-0.patch
>
>
> Async indexing logic relies on embedding application to ensure that async
> indexing job is run as a singleton in a cluster. For Sling based apps it
> depends on Sling Discovery support. At times it is being seen that if
> topology is not stable then different cluster nodes can consider them as
> leader and execute the async indexing job concurrently.
> This can cause problem as both cluster node might not see same repository
> state (due to write skew and eventual consistency) and might remove the
> checkpoint which other cluster node is still relying upon. For e.g. consider
> a 2 node cluster N1 and N2 where both are performing async indexing.
> # Base state - CP1 is the checkpoint for "async" job
> # N2 starts indexing and removes changes CP1 to CP2. For Mongo the
> checkpoints are saved in {{settings}} collection
> # N1 also decides to execute indexing but has yet not seen the latest
> repository state so still thinks that CP1 is the base checkpoint and tries to
> read it. However CP1 is already removed from {{settings}} and this makes N1
> think that checkpoint is missing and it decides to reindex everything!
> To avoid this topology must be stable but at Oak level we should still handle
> such a case and avoid doing a full reindexing. So we would need to have a
> {{MissingCheckpointStrategy}} similar to {{MissingIndexEditorStrategy}} as
> done in OAK-2203
> Possible approaches
> # A1 - Fail the indexing run if checkpoint is missing - Checkpoint being
> missing can have valid reason and invalid reason. Need to see what are valid
> scenarios where a checkpoint can go missing
> # A2 - When a checkpoint is created also store the creation time. When a
> checkpoint is found to be missing and its a *recent* checkpoint then fail the
> run. For e.g. we would fail the run till checkpoint found to be missing is
> less than an hour old (for just started take startup time into account)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3727) Broadcasting cache: auto-configuration
[ https://issues.apache.org/jira/browse/OAK-3727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-3727: -- Component/s: (was: mongomk) documentmk Changed component to 'documentmk' because I assume this is independent of the DocumentStore implementation. > Broadcasting cache: auto-configuration > -- > > Key: OAK-3727 > URL: https://issues.apache.org/jira/browse/OAK-3727 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk >Reporter: Thomas Mueller >Assignee: Thomas Mueller > > The plan is, each cluster node writes its IP address and listening port to > the clusterInfo collection, and (if really needed) a UUID. That way, it's > possible to detect other cluster nodes and connect to them. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3733) Sometimes hierarchy confict between concurrent add/delete isn't detected
[
https://issues.apache.org/jira/browse/OAK-3733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044549#comment-15044549
]
Vikas Saurabh commented on OAK-3733:
I thought OAK-3646 affects revisions which get older than an hour. The
contentious revisions for 8:/ document (and even the nearby revisions which
affected it) didn't seem so far out.
> Sometimes hierarchy confict between concurrent add/delete isn't detected
>
>
> Key: OAK-3733
> URL: https://issues.apache.org/jira/browse/OAK-3733
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, documentmk
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
> Fix For: 1.4
>
> Attachments: mongoexport.zip
>
>
> I'm not sure of exact set of event that led to an incident on one of our test
> clusters. The cluster is running 3 AEM instances based on oak build at
> 1.3.10.r1713699 backed by a single mongo 3 instance.
> Unfortunately, we found the issue too late and logs had rolled over. Here's
> the exception that showed over and over as workflow jobs were (trying to)
> being processed:
> {noformat}
>
> at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.jcr.InvalidItemStateException: OakMerge0004: OakMerge0004:
> The node
> 8:/oak:index/event.job.topic/:index/com%2Fadobe%2Fgranite%2Fworkflow%2Ftransient%2Fjob%2Fetc%2Fworkflow%2Fmodels%2Fdam-xmp-writeback%2Fjcr_content%2Fmodel/var/eventing/jobs/assigned
> was already added in revision
> r151233e54e1-0-4, before
> r15166378b6a-0-2 (retries 5, 6830 ms)
> at
> org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:239)
> at
> org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:212)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.newRepositoryException(SessionDelegate.java:669)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.save(SessionDelegate.java:495)
> at
> org.apache.jackrabbit.oak.jcr.session.SessionImpl$8.performVoid(SessionImpl.java:419)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:273)
> at
> org.apache.jackrabbit.oak.jcr.session.SessionImpl.save(SessionImpl.java:416)
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.commit(JcrResourceProvider.java:634)
> ... 16 common frames omitted
> Caused by: org.apache.jackrabbit.oak.api.CommitFailedException: OakMerge0004:
> OakMerge0004: The node
> 8:/oak:index/event.job.topic/:index/com%2Fadobe%2Fgranite%2Fworkflow%2Ftransient%2Fjob%2Fetc%2Fworkflow%2Fmodels%2Fdam-xmp-writeback%2Fjcr_content%2Fmodel/var/eventing/jobs/assigned
> was already added in revision
> r151233e54e1-0-4, before
> r15166378b6a-0-2 (retries 5, 6830 ms)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge0(DocumentNodeStoreBranch.java:200)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge(DocumentNodeStoreBranch.java:123)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentRootBuilder.merge(DocumentRootBuilder.java:158)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.merge(DocumentNodeStore.java:1497)
> at
> org.apache.jackrabbit.oak.core.MutableRoot.commit(MutableRoot.java:247)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.commit(SessionDelegate.java:346)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.save(SessionDelegate.java:493)
> ... 20 common frames omitted
> Caused by: org.apache.jackrabbit.oak.plugins.document.ConflictException: The
> node
> 8:/oak:index/event.job.topic/:index/com%2Fadobe%2Fgranite%2Fworkflow%2Ftransient%2Fjob%2Fetc%2Fworkflow%2Fmodels%2Fdam-xmp-writeback%2Fjcr_content%2Fmodel/var/eventing/jobs/assigned
> was already added in revision
> r151233e54e1-0-4, before
> r15166378b6a-0-2
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.checkConflicts(Commit.java:582)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.createOrUpdateNode(Commit.java:487)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.applyToDocumentStore(Commit.java:371)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.applyToDocumentStore(Commit.java:265)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.applyInternal(Commit.java:234)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.apply(Commit.java:219)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.persist(DocumentNodeStoreBranch.java:290)
> at
> org.apache.j
[jira] [Commented] (OAK-3733) Sometimes hierarchy confict between concurrent add/delete isn't detected
[
https://issues.apache.org/jira/browse/OAK-3733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044545#comment-15044545
]
Marcel Reutegger commented on OAK-3733:
---
This issue may be related to OAK-3646.
> Sometimes hierarchy confict between concurrent add/delete isn't detected
>
>
> Key: OAK-3733
> URL: https://issues.apache.org/jira/browse/OAK-3733
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, documentmk
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
> Fix For: 1.4
>
> Attachments: mongoexport.zip
>
>
> I'm not sure of exact set of event that led to an incident on one of our test
> clusters. The cluster is running 3 AEM instances based on oak build at
> 1.3.10.r1713699 backed by a single mongo 3 instance.
> Unfortunately, we found the issue too late and logs had rolled over. Here's
> the exception that showed over and over as workflow jobs were (trying to)
> being processed:
> {noformat}
>
> at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.jcr.InvalidItemStateException: OakMerge0004: OakMerge0004:
> The node
> 8:/oak:index/event.job.topic/:index/com%2Fadobe%2Fgranite%2Fworkflow%2Ftransient%2Fjob%2Fetc%2Fworkflow%2Fmodels%2Fdam-xmp-writeback%2Fjcr_content%2Fmodel/var/eventing/jobs/assigned
> was already added in revision
> r151233e54e1-0-4, before
> r15166378b6a-0-2 (retries 5, 6830 ms)
> at
> org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:239)
> at
> org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:212)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.newRepositoryException(SessionDelegate.java:669)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.save(SessionDelegate.java:495)
> at
> org.apache.jackrabbit.oak.jcr.session.SessionImpl$8.performVoid(SessionImpl.java:419)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:273)
> at
> org.apache.jackrabbit.oak.jcr.session.SessionImpl.save(SessionImpl.java:416)
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.commit(JcrResourceProvider.java:634)
> ... 16 common frames omitted
> Caused by: org.apache.jackrabbit.oak.api.CommitFailedException: OakMerge0004:
> OakMerge0004: The node
> 8:/oak:index/event.job.topic/:index/com%2Fadobe%2Fgranite%2Fworkflow%2Ftransient%2Fjob%2Fetc%2Fworkflow%2Fmodels%2Fdam-xmp-writeback%2Fjcr_content%2Fmodel/var/eventing/jobs/assigned
> was already added in revision
> r151233e54e1-0-4, before
> r15166378b6a-0-2 (retries 5, 6830 ms)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge0(DocumentNodeStoreBranch.java:200)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge(DocumentNodeStoreBranch.java:123)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentRootBuilder.merge(DocumentRootBuilder.java:158)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.merge(DocumentNodeStore.java:1497)
> at
> org.apache.jackrabbit.oak.core.MutableRoot.commit(MutableRoot.java:247)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.commit(SessionDelegate.java:346)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.save(SessionDelegate.java:493)
> ... 20 common frames omitted
> Caused by: org.apache.jackrabbit.oak.plugins.document.ConflictException: The
> node
> 8:/oak:index/event.job.topic/:index/com%2Fadobe%2Fgranite%2Fworkflow%2Ftransient%2Fjob%2Fetc%2Fworkflow%2Fmodels%2Fdam-xmp-writeback%2Fjcr_content%2Fmodel/var/eventing/jobs/assigned
> was already added in revision
> r151233e54e1-0-4, before
> r15166378b6a-0-2
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.checkConflicts(Commit.java:582)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.createOrUpdateNode(Commit.java:487)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.applyToDocumentStore(Commit.java:371)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.applyToDocumentStore(Commit.java:265)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.applyInternal(Commit.java:234)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.apply(Commit.java:219)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.persist(DocumentNodeStoreBranch.java:290)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.persist(DocumentNodeStoreBranch.java:260)
> at
> org.apache.jackrabbit.oak.pl
[jira] [Updated] (OAK-3718) JCR observation should be visible in SessionMBean
[ https://issues.apache.org/jira/browse/OAK-3718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-3718: --- Fix Version/s: 1.4 > JCR observation should be visible in SessionMBean > - > > Key: OAK-3718 > URL: https://issues.apache.org/jira/browse/OAK-3718 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Affects Versions: 1.0.24 >Reporter: Jörg Hoh > Labels: monitoring, resilience > Fix For: 1.4 > > > I am looking for long-running sessions, which are not (explicitly or > implicitly) refreshed. As the a session, which has a registered JCR > observation event listener, gets refreshed implicitly, it would be good to > see in the Session MBean, if a JCR observation event handler is registered > for this session. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3718) JCR observation should be visible in SessionMBean
[ https://issues.apache.org/jira/browse/OAK-3718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-3718: --- Labels: monitoring resilience (was: ) > JCR observation should be visible in SessionMBean > - > > Key: OAK-3718 > URL: https://issues.apache.org/jira/browse/OAK-3718 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Affects Versions: 1.0.24 >Reporter: Jörg Hoh > Labels: monitoring, resilience > Fix For: 1.4 > > > I am looking for long-running sessions, which are not (explicitly or > implicitly) refreshed. As the a session, which has a registered JCR > observation event listener, gets refreshed implicitly, it would be good to > see in the Session MBean, if a JCR observation event handler is registered > for this session. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3718) JCR observation should be visible in SessionMBean
[ https://issues.apache.org/jira/browse/OAK-3718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-3718: --- Component/s: core > JCR observation should be visible in SessionMBean > - > > Key: OAK-3718 > URL: https://issues.apache.org/jira/browse/OAK-3718 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Affects Versions: 1.0.24 >Reporter: Jörg Hoh > Labels: monitoring, resilience > Fix For: 1.4 > > > I am looking for long-running sessions, which are not (explicitly or > implicitly) refreshed. As the a session, which has a registered JCR > observation event listener, gets refreshed implicitly, it would be good to > see in the Session MBean, if a JCR observation event handler is registered > for this session. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3730) RDBDocumentStore: implement RDB-specific VersionGC support for lookup of split documents
[
https://issues.apache.org/jira/browse/OAK-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044544#comment-15044544
]
Marcel Reutegger commented on OAK-3730:
---
{{_sdType}} is only set on split documents. Regular documents do not have such
a field.
> RDBDocumentStore: implement RDB-specific VersionGC support for lookup of
> split documents
>
>
> Key: OAK-3730
> URL: https://issues.apache.org/jira/browse/OAK-3730
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: rdbmk
>Reporter: Julian Reschke
> Fix For: 1.4
>
>
> This requires a change to the table layout (adding SD_TYPE and more), thus
> needs thought about how to migrate from older versions of the persistence.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
