[jira] [Commented] (OAK-7116) Use JMX mode to reindex on SegmentNodeStore without requiring manual steps
[ https://issues.apache.org/jira/browse/OAK-7116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16309406#comment-16309406 ] Daniel Hasler commented on OAK-7116: [~chetanm] thanks! +1 for a prototype to achieve automation friendliness for oak-run reindexing on Tar. > Use JMX mode to reindex on SegmentNodeStore without requiring manual steps > -- > > Key: OAK-7116 > URL: https://issues.apache.org/jira/browse/OAK-7116 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: run >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: 1.10 > > > oak-run indexing for SegmentNodeStore currently require following steps while > performing indexing against a repository which is in use [1] > # Create checkpoint via MBean and pass it as part of cli args > # Perform actual indexing with read only access to repo > # Import the index via MBean operation > As per current documented steps #1 and #3 are manual. This can potentially be > simplified by directly using JMX operation from within oak-run as currently > for accessing SegmentNodeStore oak-run needs to run on same host as actual > application > *JMX Access* > JMX access can be done via following ways > # Application using Oak has JMX remote > ## Enabled and same info provided as cli args > ## Not enabled - In such a case we can rely on > ### pid and [local > connection|https://stackoverflow.com/questions/13252914/how-to-connect-to-a-local-jmx-server-by-knowing-the-process-id] > or [attach|https://github.com/nickman/jmxlocal] > ### Or query all running java prcess jmx and check if SegmentNodeStore repo > path is same as one provided in cli > # Application using OAk > *Proposed Approach* > # Establish the JMX connection > # Create checkpoint using the JMX connection programatically > # Perform indexing with read only access > # Import the index via JMX access > With this indexing support for SegmentNodeStore would be at par with > DocumentNodeStore in terms of ease of use > [1] https://jackrabbit.apache.org/oak/docs/query/oak-run-indexing.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-5229) Using Node.setPrimaryType() should fail if non-matching childnodes
[
https://issues.apache.org/jira/browse/OAK-5229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Hasler updated OAK-5229:
---
Assignee: Thomas Mueller
> Using Node.setPrimaryType() should fail if non-matching childnodes
> --
>
> Key: OAK-5229
> URL: https://issues.apache.org/jira/browse/OAK-5229
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.5.14
>Reporter: Tobias Bocanegra
>Assignee: Thomas Mueller
>Priority: Critical
> Fix For: 1.5.18
>
>
> 1. Assume the following:
> {noformat}
> /testNode [nt:unstructured]
> /unstructured_child [nt:unstructured]
> {noformat}
> 2. setting "/testNode".setPrimaryType("nt:folder")
> 3. save the session.
> Altering the primary type works, thus leaving the repository in an
> inconsistent state.
> Interestingly, subsequent calls to
> "/testNiode/unstructured_child".setProperty() will fail:
> {noformat}
> javax.jcr.nodetype.ConstraintViolationException: OakConstraint0001:
> /test_node[[nt:folder]]: No matching definition found for child node
> unstructured_child with effective type [nt:unstructured]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5369) Lucene Property Index: Syntax Error, cannot parse
[
https://issues.apache.org/jira/browse/OAK-5369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Hasler updated OAK-5369:
---
Fix Version/s: 1.5.18
> Lucene Property Index: Syntax Error, cannot parse
> -
>
> Key: OAK-5369
> URL: https://issues.apache.org/jira/browse/OAK-5369
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
> Fix For: 1.5.18, 1.4.12, 1.6
>
>
> The following query throws an exception in Apache Lucene:
> {noformat}
> /jcr:root//*[jcr:contains(., 'hello -- world')]
> 22.12.2016 16:42:54.511 *WARN* [qtp1944702753-3846]
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex query via
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex@1c0006db
> failed.
> java.lang.RuntimeException: INVALID_SYNTAX_CANNOT_PARSE: Syntax Error, cannot
> parse hello -- world:
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.tokenToQuery(LucenePropertyIndex.java:1450)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.tokenToQuery(LucenePropertyIndex.java:1418)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.access$900(LucenePropertyIndex.java:180)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$3.visitTerm(LucenePropertyIndex.java:1353)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$3.visit(LucenePropertyIndex.java:1307)
> at
> org.apache.jackrabbit.oak.query.fulltext.FullTextContains.accept(FullTextContains.java:63)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.getFullTextQuery(LucenePropertyIndex.java:1303)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.getLuceneRequest(LucenePropertyIndex.java:791)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.access$300(LucenePropertyIndex.java:180)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$1.loadDocs(LucenePropertyIndex.java:375)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$1.computeNext(LucenePropertyIndex.java:317)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$1.computeNext(LucenePropertyIndex.java:306)
> at
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
> at
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$LucenePathCursor$1.hasNext(LucenePropertyIndex.java:1571)
> at com.google.common.collect.Iterators$7.computeNext(Iterators.java:645)
> at
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
> at
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
> at
> org.apache.jackrabbit.oak.spi.query.Cursors$PathCursor.hasNext(Cursors.java:205)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$LucenePathCursor.hasNext(LucenePropertyIndex.java:1595)
> at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.next(SelectorImpl.java:420)
> at
> org.apache.jackrabbit.oak.query.QueryImpl$RowIterator.fetchNext(QueryImpl.java:828)
> at
> org.apache.jackrabbit.oak.query.QueryImpl$RowIterator.hasNext(QueryImpl.java:853)
> at
> org.apache.jackrabbit.oak.jcr.query.QueryResultImpl$1.fetch(QueryResultImpl.java:98)
> at
> org.apache.jackrabbit.oak.jcr.query.QueryResultImpl$1.(QueryResultImpl.java:94)
> at
> org.apache.jackrabbit.oak.jcr.query.QueryResultImpl.getRows(QueryResultImpl.java:78)
> Caused by:
> org.apache.lucene.queryparser.flexible.standard.parser.ParseException: Syntax
> Error, cannot parse hello -- world:
> at
> org.apache.lucene.queryparser.flexible.standard.parser.StandardSyntaxParser.generateParseException(StandardSyntaxParser.java:1054)
> at
> org.apache.lucene.queryparser.flexible.standard.parser.StandardSyntaxParser.jj_consume_token(StandardSyntaxParser.java:936)
> at
> org.apache.lucene.queryparser.flexible.standard.parser.StandardSyntaxParser.Clause(StandardSyntaxParser.java:486)
> at
> org.apache.lucene.queryparser.flexible.standard.parser.StandardSyntaxParser.ModClause(StandardSyntaxParser.java:303)
> at
> org.apache.lucene.queryparser.flexible.standard.parser.StandardSyntaxParser.ConjQuery(StandardSyntaxParser.java:234)
> at
> org.apache.lucene.queryparser.flexible.standard.parser.StandardSyntaxParser.DisjQuery(StandardSyntaxParser.java:204)
> at
>
[jira] [Updated] (OAK-5289) The tarmkdiff command does too many things
[
https://issues.apache.org/jira/browse/OAK-5289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Hasler updated OAK-5289:
---
Labels: tooling (was: )
> The tarmkdiff command does too many things
> --
>
> Key: OAK-5289
> URL: https://issues.apache.org/jira/browse/OAK-5289
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: run, segment-tar
>Reporter: Francesco Mari
>Assignee: Francesco Mari
>Priority: Minor
> Labels: tooling
> Fix For: 1.6
>
>
> The {{tarmkdiff}} command is actually the combination of two commands.
> The first command, activated when the {{\-\-list}} flag is specified, list
> available revisions in the Segment Store. For this command, only the
> {{\-\-output}} option is relevant. If other options are specified, they are
> ignored.
> The second command is the proper logic of {{tarmkdiff}}. This logic is
> activated only if the {{\-\-list}} flag is not specified. For this command,
> every option on the command line is relevant.
> The logic listing available revisions in the Segment Store should be
> encapsulated in its own command, without cluttering the CLI of {{tarmkdiff}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5277) The check command defines a useless default value for the "bin" option
[
https://issues.apache.org/jira/browse/OAK-5277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Hasler updated OAK-5277:
---
Labels: tooling (was: )
> The check command defines a useless default value for the "bin" option
> --
>
> Key: OAK-5277
> URL: https://issues.apache.org/jira/browse/OAK-5277
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: run, segment-tar
>Reporter: Francesco Mari
>Assignee: Francesco Mari
>Priority: Minor
> Labels: tooling
> Fix For: 1.6
>
>
> The {{check}} command enables the traversal of binary properties via the
> {{--bin}} option. The user could provide a value for this option to specify
> the amount of bytes that should be traversed for every binary value. The
> default value for the {{--bin}} option is zero, effectively disabling the
> traversal of binary properties. Instead, if a value for this property is not
> specified, the tools should traverse the binary properties in their entirety.
> A value should be specified only to restrict the amount of bytes to traverse.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5276) The check command overloads the meaning of the "deep" option
[
https://issues.apache.org/jira/browse/OAK-5276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Hasler updated OAK-5276:
---
Labels: tooling (was: )
> The check command overloads the meaning of the "deep" option
>
>
> Key: OAK-5276
> URL: https://issues.apache.org/jira/browse/OAK-5276
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: run, segment-tar
>Reporter: Francesco Mari
>Assignee: Francesco Mari
>Priority: Minor
> Labels: tooling
> Fix For: 1.6
>
>
> The {{--deep}} option accepted by the {{check}} command is semantically
> overloaded. It is used both as a flag to enable deep content traversal and as
> a way to specify the frequency of debug messages printed by the tool.
> This option should be split in two. In particular, {{--deep}} should retain
> its behaviour of on/off flag for deep traversal, and a new command line
> option should be introduced to specify the interval of debug messages.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5275) The check command should accept the path to the store as a positional argument
[
https://issues.apache.org/jira/browse/OAK-5275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Hasler updated OAK-5275:
---
Labels: tooling (was: )
> The check command should accept the path to the store as a positional argument
> --
>
> Key: OAK-5275
> URL: https://issues.apache.org/jira/browse/OAK-5275
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: run, segment-tar
>Reporter: Francesco Mari
>Assignee: Francesco Mari
>Priority: Minor
> Labels: tooling
> Fix For: 1.6
>
>
> The {{check}} tool requires the path to the store to be specified. The path
> is passed to the tool via a required option {{--path}}. This way of
> specifying the path to the store is verbose for no good reason. It would be
> nicer if the path to the Segment Store would be specified via a positional
> argument instead.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5326) Not able to move segment store directory on filesystem after closing FileStore
[
https://issues.apache.org/jira/browse/OAK-5326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Hasler updated OAK-5326:
---
Fix Version/s: (was: 1.5.17)
1.5.18
> Not able to move segment store directory on filesystem after closing FileStore
> --
>
> Key: OAK-5326
> URL: https://issues.apache.org/jira/browse/OAK-5326
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: upgrade
>Affects Versions: 1.5.13
> Environment: Windows 2012 R2,
> Java(TM) SE Run-time Environment (build 1.8.0_74-b02)
>Reporter: Arek Kita
>Assignee: Arek Kita
> Fix For: 1.5.18, 1.6
>
>
> The JVM process that uses {{oak-upgrade}} library for upgrading Oak
> repository is not able to move source (and probably destination) repository
> after making sure that both file stores are closed.
> {code:title=oak-upgrade}
> 16.12.2016 17:15:31.463 INFO o.a.j.o.u.RepositorySidegrade: Copying node
> #77:
> 16.12.2016 17:15:38.604 INFO o.a.j.o.u.RepositorySidegrade: Copying node
> #78:
> 16.12.2016 17:15:39.495 INFO o.a.j.o.u.RepositorySidegrade: Copying node
> #79:
> 16.12.2016 17:15:41.182 INFO o.a.j.o.s.f.FileStore: TarMK closed:
> C:\workspace\repository-segment-tar-20161216-171300\segmentstore
> 16.12.2016 17:15:41.370 INFO o.a.j.o.p.s.f.FileStore: TarMK closed:
> C:\workspace\repository\segmentstore
> 16.12.2016 17:17:11.604 ERROR java.io.IOException: Unable to delete file:
> C:\workspace\repository\segmentstore\journal.log
> at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:2381) ~
> at org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:1679) ~
> at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1575)
> ~
> at org.apache.commons.io.FileUtils.moveDirectory(FileUtils.java:2916) ~
> ...
> {code}
> Please also note that {{--disable-mmap}} option is passed to avoid OAK-4274.
> Is there any way to make all operations synchronised and finished after the
> migration is executed using the API method:
> {{OakUpgrade.migrate(MigrationOptions options, StoreArguments stores,
> DatastoreArguments datastores) throws IOException, CliArgumentException}}
> This leads to a weird experience when filesystem clean up (reordering) is
> needed.
> On Unix the {{segmentstore}} folder might be moved as UNIX fs implementation
> is not so restrictive. On Windows it is *not possible*.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5326) Not able to move segment store directory on filesystem after closing FileStore
[
https://issues.apache.org/jira/browse/OAK-5326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Hasler updated OAK-5326:
---
Fix Version/s: 1.5.17
> Not able to move segment store directory on filesystem after closing FileStore
> --
>
> Key: OAK-5326
> URL: https://issues.apache.org/jira/browse/OAK-5326
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: upgrade
>Affects Versions: 1.5.13
> Environment: Windows 2012 R2,
> Java(TM) SE Run-time Environment (build 1.8.0_74-b02)
>Reporter: Arek Kita
>Assignee: Arek Kita
> Fix For: 1.5.17, 1.6
>
>
> The JVM process that uses {{oak-upgrade}} library for upgrading Oak
> repository is not able to move source (and probably destination) repository
> after making sure that both file stores are closed.
> {code:title=oak-upgrade}
> 16.12.2016 17:15:31.463 INFO o.a.j.o.u.RepositorySidegrade: Copying node
> #77:
> 16.12.2016 17:15:38.604 INFO o.a.j.o.u.RepositorySidegrade: Copying node
> #78:
> 16.12.2016 17:15:39.495 INFO o.a.j.o.u.RepositorySidegrade: Copying node
> #79:
> 16.12.2016 17:15:41.182 INFO o.a.j.o.s.f.FileStore: TarMK closed:
> C:\workspace\repository-segment-tar-20161216-171300\segmentstore
> 16.12.2016 17:15:41.370 INFO o.a.j.o.p.s.f.FileStore: TarMK closed:
> C:\workspace\repository\segmentstore
> 16.12.2016 17:17:11.604 ERROR java.io.IOException: Unable to delete file:
> C:\workspace\repository\segmentstore\journal.log
> at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:2381) ~
> at org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:1679) ~
> at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1575)
> ~
> at org.apache.commons.io.FileUtils.moveDirectory(FileUtils.java:2916) ~
> ...
> {code}
> Please also note that {{--disable-mmap}} option is passed to avoid OAK-4274.
> Is there any way to make all operations synchronised and finished after the
> migration is executed using the API method:
> {{OakUpgrade.migrate(MigrationOptions options, StoreArguments stores,
> DatastoreArguments datastores) throws IOException, CliArgumentException}}
> This leads to a weird experience when filesystem clean up (reordering) is
> needed.
> On Unix the {{segmentstore}} folder might be moved as UNIX fs implementation
> is not so restrictive. On Windows it is *not possible*.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5048) Upgrade to latest Tika version
[ https://issues.apache.org/jira/browse/OAK-5048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Hasler updated OAK-5048: --- Fix Version/s: (was: 1.6) 1.8 > Upgrade to latest Tika version > -- > > Key: OAK-5048 > URL: https://issues.apache.org/jira/browse/OAK-5048 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > Fix For: 1.8 > > > Oak Lucene indes is currently using Tika 1.5 version while current latest > release of Apache Tika is 1.14, I think there're lots of "interesting" bugs > fixed, and possibly improvements (performance, more accurate text extraction, > etc.) we could get at almost 0 cost by just bumping the version number. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-5144) use 'allNodeTypes' of ChangeSet for nodeType-aggregate-filter
[ https://issues.apache.org/jira/browse/OAK-5144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Hasler updated OAK-5144: --- Fix Version/s: (was: 1.6) 1.8 > use 'allNodeTypes' of ChangeSet for nodeType-aggregate-filter > - > > Key: OAK-5144 > URL: https://issues.apache.org/jira/browse/OAK-5144 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: jcr >Affects Versions: 1.5.14 >Reporter: Stefan Egli > Fix For: 1.8 > > > With OAK-4940 the ChangeSet now contains all node types up to root that are > related to a change. This fact could be used by the nodeType-aggregate-filter > (OAK-5021), which would likely speed up this type of filter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-5186) ChangeSetFIlterImpl: support many includePaths by filtering for 1st path name
[
https://issues.apache.org/jira/browse/OAK-5186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Hasler updated OAK-5186:
---
Fix Version/s: (was: 1.6)
1.8
> ChangeSetFIlterImpl: support many includePaths by filtering for 1st path name
> -
>
> Key: OAK-5186
> URL: https://issues.apache.org/jira/browse/OAK-5186
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.5.14
>Reporter: Stefan Egli
>Priority: Critical
> Fix For: 1.8
>
> Attachments: OAK-5186.patch
>
>
> When there is a large number of include paths in the ChangeSetFilterImpl and
> combine that with a large-ish ChangeSet (many paths) then the comparison
> becomes expensive, as there is a loop with each ChangeSet-path, then looping
> through each include path. Basically an {{O(n*m)}}.
> A probably ideal solution would be to implement a tree with the tree items be
> the path elements. And have two sets of trees: the filter one and the
> ChangeSet one.
> A simpler and perhaps 'good enough' solution could be to just look at the
> first level name of both the filter include paths: if a ChangeSet path's
> first level name is not in that set, then it can't be included. That would
> allow to skip the pattern comparison (which is slower even though it is a
> compiled {{Pattern}}).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5222) Optimize the multiplexing node store
[
https://issues.apache.org/jira/browse/OAK-5222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Hasler updated OAK-5222:
---
Fix Version/s: (was: 1.6)
1.8
> Optimize the multiplexing node store
>
>
> Key: OAK-5222
> URL: https://issues.apache.org/jira/browse/OAK-5222
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Tomek Rękawek
>Assignee: Tomek Rękawek
> Fix For: 1.8
>
>
> I added support for the multiplexing node store for the oak-run benchmark
> fixtures. It seems that the performance in ReadDeepTreeTest is linearly
> dependent on the mount counts:
> {noformat}
> MountsN
> 0 729
> 1 402
> 2 287
> 3 209
> 4 188
> 5 154
> 6 133
> 7 126
> 8 104
> 9 100
> 1085
> 2046
> {noformat}
> {{N}} - throughput in 60 seconds. Following command was used:
> {noformat}
> $ java -jar target/oak-run-1.6-SNAPSHOT.jar benchmark ReadDeepTreeTest
> Oak-Multiplexing --mounts=10
> {noformat}
> It should be possible to improve this, so we won't have a noticeable
> performance decrease for 1000 mounts.
> //cc: [~rombert]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5017) Standby test failures
[
https://issues.apache.org/jira/browse/OAK-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Hasler updated OAK-5017:
---
Assignee: Francesco Mari (was: Timothee Maret)
> Standby test failures
> -
>
> Key: OAK-5017
> URL: https://issues.apache.org/jira/browse/OAK-5017
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Francesco Mari
> Labels: test-failure
> Fix For: 1.6, 1.5.15
>
>
> I've recently seen a couple of the standby tests fail. E.g. on Jenkins:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1245/
> {noformat}
> java.lang.AssertionError: expected:
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... },
> root = { ... } }> but was:
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... },
> root = { ... } }>
> at
> org.apache.jackrabbit.oak.segment.standby.StandbyTestIT.testSyncLoop(StandbyTestIT.java:122)
> {noformat}
> {noformat}
> java.lang.AssertionError: expected:
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... },
> root = { ... } }> but was:
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... },
> root = { ... } }>
> at
> org.apache.jackrabbit.oak.segment.standby.StandbyTestIT.testSyncLoop(StandbyTestIT.java:122)
> {noformat}
> {{org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT.testProxySkippedBytes}}:
> {noformat}
> java.lang.AssertionError: expected:<{ root = { ... } }> but was:<{ root : { }
> }>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3219) Lucene IndexPlanner should also account for number of property constraints evaluated while giving cost estimation
[
https://issues.apache.org/jira/browse/OAK-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Hasler updated OAK-3219:
---
Fix Version/s: (was: 1.6)
1.8
> Lucene IndexPlanner should also account for number of property constraints
> evaluated while giving cost estimation
> -
>
> Key: OAK-3219
> URL: https://issues.apache.org/jira/browse/OAK-3219
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Thomas Mueller
>Priority: Minor
> Labels: performance
> Fix For: 1.8
>
>
> Currently the cost returned by Lucene index is a function of number of
> indexed documents present in the index. If the number of indexed entries are
> high then it might reduce chances of this index getting selected if some
> property index also support of the property constraint.
> {noformat}
> /jcr:root/content/freestyle-cms/customers//element(*, cq:Page)
> [(jcr:content/@title = 'm' or jcr:like(jcr:content/@title, 'm%'))
> and jcr:content/@sling:resourceType = '/components/page/customer’]
> {noformat}
> Consider above query with following index definition
> * A property index on resourceType
> * A Lucene index for cq:Page with properties {{jcr:content/title}},
> {{jcr:content/sling:resourceType}} indexed and also path restriction
> evaluation enabled
> Now what the two indexes can help in
> # Property index
> ## Path restriction
> ## Property restriction on {{sling:resourceType}}
> # Lucene index
> ## NodeType restriction
> ## Property restriction on {{sling:resourceType}}
> ## Property restriction on {{title}}
> ## Path restriction
> Now cost estimate currently works like this
> * Property index - {{f(indexedValueEstimate, estimateOfNodesUnderGivenPath)}}
> ** indexedValueEstimate - For 'sling:resourceType=foo' its the approximate
> count for nodes having that as 'foo'
> ** estimateOfNodesUnderGivenPath - Its derived from an approximate estimation
> of nodes present under given path
> * Lucene Index - {{f(totalIndexedEntries)}}
> As cost of Lucene is too simple it does not reflect the reality. Following 2
> changes can be done to make it better
> * Given that Lucene index can handle multiple constraints compared (4) to
> property index (2), the cost estimate returned by it should also reflect this
> state. This can be done by setting costPerEntry to 1/(no of property
> restriction evaluated)
> * Get the count for queried property value - This is similar to what
> PropertyIndex does and assumes that Lucene can provide that information in
> O(1) cost. In case of multiple supported property restriction this can be
> minima of all
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5063) Failure in QueryTest.nodeType
[
https://issues.apache.org/jira/browse/OAK-5063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Hasler updated OAK-5063:
---
Fix Version/s: 1.5.16
> Failure in QueryTest.nodeType
> --
>
> Key: OAK-5063
> URL: https://issues.apache.org/jira/browse/OAK-5063
> Project: Jackrabbit Oak
> Issue Type: Test
> Components: query
>Reporter: Chetan Mehrotra
>Assignee: Thomas Mueller
>Priority: Minor
> Fix For: 1.6, 1.5.16
>
>
> There are 4 failure seen in QueryTest.nodeType in past 2 weeks. With
> OAK-4993 the plan is now being reported as part of test failure
> {noformat}
> Error Message:
> Unexpected plan: [oak:Unstructured] as [a] /* traverse "//*" where
> ([a].[xyz/jcr:primaryType] is not null) and (isdescendantnode([a], [/])) */
> Stack Trace:
> java.lang.AssertionError: Unexpected plan: [oak:Unstructured] as [a] /*
> traverse "//*" where ([a].[xyz/jcr:primaryType] is not null) and
> (isdescendantnode([a], [/])) */
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at
> org.apache.jackrabbit.oak.jcr.query.QueryTest.assertPlan(QueryTest.java:852)
> at
> org.apache.jackrabbit.oak.jcr.query.QueryTest.nodeType(QueryTest.java:846)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5136) remove prefiltering testmode (feature/config) before 1.6
[ https://issues.apache.org/jira/browse/OAK-5136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Hasler updated OAK-5136: --- Assignee: Marcel Reutegger (was: Stefan Egli) > remove prefiltering testmode (feature/config) before 1.6 > > > Key: OAK-5136 > URL: https://issues.apache.org/jira/browse/OAK-5136 > Project: Jackrabbit Oak > Issue Type: Task > Components: jcr >Affects Versions: 1.5.14 >Reporter: Stefan Egli >Assignee: Marcel Reutegger >Priority: Blocker > Fix For: 1.6, 1.5.18 > > > OAK-5134 introduces an osgi config for the prefiltering test mode (previously > it was a system property). > This prefiltering test mode should be removed before 1.6 - it should not > become part of the stable release - it's only meant for early testing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-5136) remove prefiltering testmode (feature/config) before 1.6
[ https://issues.apache.org/jira/browse/OAK-5136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Hasler updated OAK-5136: --- Fix Version/s: 1.5.18 > remove prefiltering testmode (feature/config) before 1.6 > > > Key: OAK-5136 > URL: https://issues.apache.org/jira/browse/OAK-5136 > Project: Jackrabbit Oak > Issue Type: Task > Components: jcr >Affects Versions: 1.5.14 >Reporter: Stefan Egli >Assignee: Stefan Egli >Priority: Blocker > Fix For: 1.6, 1.5.18 > > > OAK-5134 introduces an osgi config for the prefiltering test mode (previously > it was a system property). > This prefiltering test mode should be removed before 1.6 - it should not > become part of the stable release - it's only meant for early testing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4452) Consistently use the term segment-tar
[ https://issues.apache.org/jira/browse/OAK-4452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Hasler updated OAK-4452: --- Issue Type: Task (was: Improvement) > Consistently use the term segment-tar > - > > Key: OAK-4452 > URL: https://issues.apache.org/jira/browse/OAK-4452 > Project: Jackrabbit Oak > Issue Type: Task > Components: doc, segment-tar >Reporter: Michael Dürig >Assignee: Michael Dürig >Priority: Minor > Labels: documentation, production > Fix For: 1.6, 1.5.16 > > > We should make an effort to consistently use the term "segment-tar" instead > of "SegmentMK", "TarMK", etc. in logging, exceptions, labels, descriptions, > documentation etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-5028) Remove DocumentStore.update()
[ https://issues.apache.org/jira/browse/OAK-5028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Hasler updated OAK-5028: --- Fix Version/s: (was: 1.5.15) (was: 1.6) 1.8 > Remove DocumentStore.update() > - > > Key: OAK-5028 > URL: https://issues.apache.org/jira/browse/OAK-5028 > Project: Jackrabbit Oak > Issue Type: Task > Components: core, documentmk, mongomk, rdbmk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Fix For: 1.8 > > > OAK-3018 removed the single production usage of DocumentStore.update(). I > propose we remove the method to reduce maintenance. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-5060) Make DocumentNodeStore.alignWithExternalRevisions more chatty
[ https://issues.apache.org/jira/browse/OAK-5060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Hasler updated OAK-5060: --- Fix Version/s: 1.5.18 > Make DocumentNodeStore.alignWithExternalRevisions more chatty > - > > Key: OAK-5060 > URL: https://issues.apache.org/jira/browse/OAK-5060 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk >Reporter: Julian Reschke >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.6, 1.5.18 > > Attachments: OAK-5060.diff > > > ...when the computed delay is large (> 60s?), so that the system log > continues to show what's going on... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4687) Issue with backgroundOperationLock handling in exception case
[
https://issues.apache.org/jira/browse/OAK-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Hasler updated OAK-4687:
---
Fix Version/s: 1.5.16
> Issue with backgroundOperationLock handling in exception case
> -
>
> Key: OAK-4687
> URL: https://issues.apache.org/jira/browse/OAK-4687
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk
>Reporter: Chetan Mehrotra
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.6, 1.5.16
>
>
> If in a commit some exception occurs then that exception gets hidden due to
> error in exception handling code path in DocumentNodeStore
> Instead of original exception following exception is seen
> {noformat}
> Caused by: java.lang.IllegalMonitorStateException: attempt to unlock read
> lock, not locked by current thread
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$Sync.unmatchedUnlockException(ReentrantReadWriteLock.java:447)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$Sync.tryReleaseShared(ReentrantReadWriteLock.java:431)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.releaseShared(AbstractQueuedSynchronizer.java:1340)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.unlock(ReentrantReadWriteLock.java:883)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.canceled(DocumentNodeStore.java:767)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.persist(DocumentNodeStoreBranch.java:303)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.persist(DocumentNodeStoreBranch.java:268)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.access$300(DocumentNodeStoreBranch.java:58)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch$InMemory.merge(DocumentNodeStoreBranch.java:513)
> ... 36 more
> {noformat}
> This happens because the lock is released twice
> # Once in DocumentNodeStore#done
> # Second in DocumentNodeStore#canceled. Invoked in case of failure in
> DocumentNodeStoreBranch#persist
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5189) SegmentRevisionGC should expose unformatted timestamps
[
https://issues.apache.org/jira/browse/OAK-5189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Hasler updated OAK-5189:
---
Fix Version/s: 1.5.16
> SegmentRevisionGC should expose unformatted timestamps
> --
>
> Key: OAK-5189
> URL: https://issues.apache.org/jira/browse/OAK-5189
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Francesco Mari
>Assignee: Andrei Dulceanu
>Priority: Minor
> Fix For: 1.6, 1.5.16
>
>
> The {{LastCompaction}} and {{LastCleanup}} properties exposed by
> {{SegmentRevisionGC}} are timestamps formatted according to the
> machine-specified locale. To be portable and more easily parsed from
> non-human users (e.g. monitoring infrastructure), it would probably be better
> to expose those timestamps as plain long values.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4978) Expose maintainence related MBeans for Segment NodeStores created via factory
[
https://issues.apache.org/jira/browse/OAK-4978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Hasler updated OAK-4978:
---
Fix Version/s: 1.5.16
> Expose maintainence related MBeans for Segment NodeStores created via factory
> -
>
> Key: OAK-4978
> URL: https://issues.apache.org/jira/browse/OAK-4978
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar, segmentmk
>Reporter: Chetan Mehrotra
>Assignee: Alex Parvulescu
> Fix For: 1.6, 1.5.16
>
>
> With OAK-4655 support was added to initializing multiple segment nodestores
> and have them exposed via {{NodeStoreProvider}} ties to different roles.
> In some cases such stores are immutable and do not require any maintenance.
> However for other cases maintenance is required. So we would need to expose
> various MBean which allow such maintenance activities.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4453) Cleanup blob gc related tests
[ https://issues.apache.org/jira/browse/OAK-4453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Hasler updated OAK-4453: --- Fix Version/s: (was: 1.6) 1.8 > Cleanup blob gc related tests > - > > Key: OAK-4453 > URL: https://issues.apache.org/jira/browse/OAK-4453 > Project: Jackrabbit Oak > Issue Type: Task > Components: blob >Reporter: Amit Jain >Assignee: Amit Jain >Priority: Minor > Labels: technical_debt > Fix For: 1.8 > > > The various blob gc related tests have a fair bit of duplication. These > should be de duplicated and cleaned up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3341) lucene technical debt
[ https://issues.apache.org/jira/browse/OAK-3341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Hasler updated OAK-3341: --- Fix Version/s: (was: 1.4) 1.3.9 > lucene technical debt > - > > Key: OAK-3341 > URL: https://issues.apache.org/jira/browse/OAK-3341 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Daniel Hasler > Fix For: 1.3.9 > > > As discussed bilaterally grouping the technical debt for Lucene in this issue > for easier tracking -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3340) mongomk technical debt
[ https://issues.apache.org/jira/browse/OAK-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Hasler updated OAK-3340: --- Fix Version/s: (was: 1.4) 1.3.9 > mongomk technical debt > --- > > Key: OAK-3340 > URL: https://issues.apache.org/jira/browse/OAK-3340 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk >Reporter: Daniel Hasler > Fix For: 1.3.9 > > > As discussed bilaterally grouping the technical debt for MongoMK in this > issue for easier tracking -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-3340) mongomk technical debt
Daniel Hasler created OAK-3340: -- Summary: mongomk technical debt Key: OAK-3340 URL: https://issues.apache.org/jira/browse/OAK-3340 Project: Jackrabbit Oak Issue Type: Improvement Components: mongomk Reporter: Daniel Hasler Fix For: 1.3.8 As discussed bilaterally grouping the technical debt for MongoMK in this issue for easier tracking -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-3341) lucene technical debt
Daniel Hasler created OAK-3341: -- Summary: lucene technical debt Key: OAK-3341 URL: https://issues.apache.org/jira/browse/OAK-3341 Project: Jackrabbit Oak Issue Type: Improvement Components: lucene Reporter: Daniel Hasler Fix For: 1.4 As discussed bilaterally grouping the technical debt for Lucene in this issue for easier tracking -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3340) mongomk technical debt
[ https://issues.apache.org/jira/browse/OAK-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Hasler updated OAK-3340: --- Fix Version/s: (was: 1.3.8) 1.4 > mongomk technical debt > --- > > Key: OAK-3340 > URL: https://issues.apache.org/jira/browse/OAK-3340 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk >Reporter: Daniel Hasler > Fix For: 1.4 > > > As discussed bilaterally grouping the technical debt for MongoMK in this > issue for easier tracking -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2115) Turn async indexer checkpoint warning log to debug
[ https://issues.apache.org/jira/browse/OAK-2115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14156286#comment-14156286 ] Daniel Hasler commented on OAK-2115: [~alexparvulescu], same goes for AsyncIndexUpdate Unable to retrieve newly created checkpoint (...), skipping the async index update message. Turn async indexer checkpoint warning log to debug --- Key: OAK-2115 URL: https://issues.apache.org/jira/browse/OAK-2115 Project: Jackrabbit Oak Issue Type: Improvement Components: core Reporter: Alex Parvulescu Assignee: Alex Parvulescu Priority: Minor Fix For: 1.1.1 The async indexer relies on creating a new checkppoint on each run. This checkpoint creation might not be successful on the SegmentMK, but a warning is logged instead as a _warning_ log. I'd like to turn this into a _debug_ log, as it is nothing serious, the async indexer will be able to recover and continue where it left off on the next run. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-1160) Generic interfaces for operation tasks
[ https://issues.apache.org/jira/browse/OAK-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13922284#comment-13922284 ] Daniel Hasler commented on OAK-1160: +1 for using JMX. Generic interfaces for operation tasks -- Key: OAK-1160 URL: https://issues.apache.org/jira/browse/OAK-1160 Project: Jackrabbit Oak Issue Type: New Feature Components: core, mk Reporter: Michael Marth Assignee: Michael Dürig Fix For: 0.19 Could we add generic (i.e. MK independent) interfaces that can be used by higher levels to trigger certain ops tasks? The the application could decide when would be a good time to run them. I am thinking especially about backup/restore (OAK-1158), MVCC revision cleanup (OAK-1158) and DSGC (OAK-377) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (OAK-1217) support for QueryStat MBean
Daniel Hasler created OAK-1217:
--
Summary: support for QueryStat MBean
Key: OAK-1217
URL: https://issues.apache.org/jira/browse/OAK-1217
Project: Jackrabbit Oak
Issue Type: New Feature
Components: query
Reporter: Daniel Hasler
The JMX bindings for {{QueryStat}} are available in Jackrabbit, but not in Oak.
Having support for this in Oak would make it easy to identify long running
queries.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
