[jira] [Commented] (OAK-3336) Abstract a full text index implementation to be extended by Lucene and Solr
[ https://issues.apache.org/jira/browse/OAK-3336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426448#comment-16426448 ] Vikas Saurabh commented on OAK-3336: These most likely would call for separate issue/tasks but, it would be useful to remember what we ([~teofili], [~tmueller] and I) discussed off-list in a brain storming session: h4. Index definitions * can likely be common for most parts * analyzer – probably specific to lucene?? ** even if some (say solr or ES) allow for different definitions use different analyzers - but the concept might not be generic for oak-search module * tika – common * aggregates – common * property definitions – common, except below?? ** Suggestion ** Spellcheck ** Facet ** Excerpt ** Function index - probably common as function indexes are essentially just providing value to be indexed h4. Editor * When to index – most likely common as values affecting state change should be independent of index provider in play * What to index – most likely common except for following?? ** Spellcheck ** Suggestion ** Facet ** Excerpt ** Custom Field provider – common *** needs to be made independed of lucene Fields though *** how to deprecate current SPI? ** How to index – has to be custom for each index provider h4. Sync indexing should be common as its storage is node state based. Sync indexed data doesn't go to centrally indexed async information h4. NRT * should be common similar to sync indexing above * BUT would require oak-search to use lucene (which might be debatable) h4. CoR/CoW or counterparts * custom on need basis * most likely relevant only for lucene indexes but utilities could be useful to support different lucene versions (is that a goal??) h4. Query * Index selection – can I answer this query ** common ** this would be part of planner which checks index definition to see if the index can answer a give query * Cost estimation ** needs to be custom as it's highly tied to "how a given indexer indexes data" AND "how costly would it be to get a good fast estimate" ** some parts might be common like *** how many unique values does a given constraint have *** what's the worst case result count (maybe backed by node counter) in case concrete implementation can't get that information in a fast manner * Custom query terms provider – can be common (similar to Custom field provider) ** needs to be made independent of Lucene Query ** how to deprecate current SPI? * Low level query – needs to be custom ** But, maybe, we can utilize current form of LuceneProperyIndex and translate LuceneQuery AST to underlying engine’s query h4. Text extraction + tika configuration - common * as similar to function index, this is about generating data to index * should we allow for some implementations that might be interested in doing their own extractions? ** maybe with a caution that "external text extraction is out of control - so expectation of extraction feature parity is implicitly undefined" h4. Tests * Lucene tests have pretty decent coverage * Since the idea is to abstract as much stuff as possible, so, any test that’s querying and verifying result should be parametrized to all index providers (all = lucene, solr, ES, etc) > Abstract a full text index implementation to be extended by Lucene and Solr > --- > > Key: OAK-3336 > URL: https://issues.apache.org/jira/browse/OAK-3336 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene, query, solr >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili >Priority: Major > Fix For: 1.10 > > > Current Lucene and Solr indexes implement quite a no. of features according > to their specific APIs, design and implementation. However in the long run, > while differences in APIs and implementations will / can of course stay, the > difference in design can make it hard to keep those features on par. > It'd be therefore nice to make it possible to abstract as much of design and > implementation bits as possible in an abstract full text implementation which > Lucene and Solr would extend according to their specifics. > An example advantage of this is that index time aggregation will be > implemented only once and therefore any bugfixes and improvements in that > area will be done in the abstract implementation rather than having to do > that in two places. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7386) Build Jackrabbit Oak #1348 failed
[ https://issues.apache.org/jira/browse/OAK-7386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425877#comment-16425877 ] Hudson commented on OAK-7386: - Previously failing build now is OK. Passed run: [Jackrabbit Oak #1351|https://builds.apache.org/job/Jackrabbit%20Oak/1351/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/1351/console] > Build Jackrabbit Oak #1348 failed > - > > Key: OAK-7386 > URL: https://issues.apache.org/jira/browse/OAK-7386 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #1348 has failed. > First failed run: [Jackrabbit Oak > #1348|https://builds.apache.org/job/Jackrabbit%20Oak/1348/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/1348/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7386) Build Jackrabbit Oak #1348 failed
[ https://issues.apache.org/jira/browse/OAK-7386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425729#comment-16425729 ] Hudson commented on OAK-7386: - Previously failing build now is OK. Passed run: [Jackrabbit Oak #1350|https://builds.apache.org/job/Jackrabbit%20Oak/1350/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/1350/console] > Build Jackrabbit Oak #1348 failed > - > > Key: OAK-7386 > URL: https://issues.apache.org/jira/browse/OAK-7386 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #1348 has failed. > First failed run: [Jackrabbit Oak > #1348|https://builds.apache.org/job/Jackrabbit%20Oak/1348/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/1348/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7388) MergingNodeStateDiff may recreate nodes that were previously removed to resolve conflicts
[
https://issues.apache.org/jira/browse/OAK-7388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari updated OAK-7388:
Fix Version/s: 1.9.0
> MergingNodeStateDiff may recreate nodes that were previously removed to
> resolve conflicts
> -
>
> Key: OAK-7388
> URL: https://issues.apache.org/jira/browse/OAK-7388
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Francesco Mari
>Assignee: Francesco Mari
>Priority: Major
> Fix For: 1.9.0, 1.10
>
>
> {{MergingNodeStateDiff}} might behave incorrectly when the resolution of a
> conflict involves the deletion of the conflicting node. I spotted this issue
> in a use case that can be expressed by the following code.
> {noformat}
> NodeState root = EmptyNodeState.EMPTY_NODE;
> NodeState withProperty;
> {
> NodeBuilder builder = root.builder();
> builder.child("c").setProperty("foo", "bar");
> withProperty = builder.getNodeState();
> }
> NodeState withUpdatedProperty;
> {
> NodeBuilder builder = withProperty.builder();
> builder.child("c").setProperty("foo", "baz");
> withUpdatedProperty = builder.getNodeState();
> }
> NodeState withRemovedChild;
> {
> NodeBuilder builder = withProperty.builder();
> builder.child("c").remove();
> withRemovedChild = builder.getNodeState();
> }
> NodeBuilder mergedBuilder = withUpdatedProperty.builder();
> withRemovedChild.compareAgainstBaseState(withProperty, new
> ConflictAnnotatingRebaseDiff(mergedBuilder));
> NodeState merged =
> ConflictHook.of(DefaultThreeWayConflictHandler.OURS).processCommit(
> mergedBuilder.getBaseState(),
> mergedBuilder.getNodeState(),
> CommitInfo.EMPTY
> );
> assertFalse(merged.hasChildNode("c"));
> {noformat}
> The assertion at the end of the code fails becauuse `merged` actually has a
> child node named `c`, and `c` is an empty node. After digging into the issue,
> I figured out that the problem is caused by the following steps.
> # {{MergingNodeStateDiff#childNodeAdded}} is invoked because of
> {{:conflicts}}. This eventually results in the deletion of the conflicting
> child node.
> # {{MergingNodeStateDiff#childNodeChanged}} is called because in
> {{ModifiedNodeState#compareAgainstBaseState}} the children are compared with
> the {{!=}} operator instead of using {{Object#equals}}.
> # {{org.apache.jackrabbit.oak.spi.state.NodeBuilder#child}} is called in
> order to setup a new {{MergingNodeStateDiff}} to descend into the subtree
> that was detected as modified.
> # {{MemoryNodeBuilder#hasChildNode}} correctly returns {{false}}, because the
> child was removed in step 1. The return value of {{false}} triggers the next
> step.
> # {{MemoryNodeBuilder#setChildNode(java.lang.String)}} is invoked in order to
> setup a new, empty child node.
> In other words, the snippet above can be rewritten like the following.
> {noformat}
> NodeState root = EmptyNodeState.EMPTY_NODE;
> NodeState withProperty;
> {
> NodeBuilder builder = root.builder();
> builder.child("c").setProperty("foo", "bar");
> withProperty = builder.getNodeState();
> }
> NodeState withUpdatedProperty;
> {
> NodeBuilder builder = withProperty.builder();
> builder.child("c").setProperty("foo", "baz");
> withUpdatedProperty = builder.getNodeState();
> }
> NodeState withRemovedChild;
> {
> NodeBuilder builder = withProperty.builder();
> builder.child("c").remove();
> withRemovedChild = builder.getNodeState();
> }
> NodeBuilder mergedBuilder = withUpdatedProperty.builder();
> // As per MergingNodeStateDiff.childNodeAdded()
> mergedBuilder.child("c").remove();
> // As per ModifiedNodeState#compareAgainstBaseState()
> if (withUpdatedProperty.getChildNode("c") !=
> withRemovedChild.getChildNode("c")) {
> // As per MergingNodeStateDiff.childNodeChanged()
> mergedBuilder.child("c");
> }
> NodeState merged = mergedBuilder.getNodeState();
> assertFalse(merged.hasChildNode("c"));
> {noformat}
> The end result is that {{MergingNodeStateDiff}} inadvertently adds the node
> that was removed in order to resolve a conflict.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (OAK-7388) MergingNodeStateDiff may recreate nodes that were previously removed to resolve conflicts
[
https://issues.apache.org/jira/browse/OAK-7388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari resolved OAK-7388.
-
Resolution: Fixed
Fixed at r1828353.
> MergingNodeStateDiff may recreate nodes that were previously removed to
> resolve conflicts
> -
>
> Key: OAK-7388
> URL: https://issues.apache.org/jira/browse/OAK-7388
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Francesco Mari
>Assignee: Francesco Mari
>Priority: Major
> Fix For: 1.10
>
>
> {{MergingNodeStateDiff}} might behave incorrectly when the resolution of a
> conflict involves the deletion of the conflicting node. I spotted this issue
> in a use case that can be expressed by the following code.
> {noformat}
> NodeState root = EmptyNodeState.EMPTY_NODE;
> NodeState withProperty;
> {
> NodeBuilder builder = root.builder();
> builder.child("c").setProperty("foo", "bar");
> withProperty = builder.getNodeState();
> }
> NodeState withUpdatedProperty;
> {
> NodeBuilder builder = withProperty.builder();
> builder.child("c").setProperty("foo", "baz");
> withUpdatedProperty = builder.getNodeState();
> }
> NodeState withRemovedChild;
> {
> NodeBuilder builder = withProperty.builder();
> builder.child("c").remove();
> withRemovedChild = builder.getNodeState();
> }
> NodeBuilder mergedBuilder = withUpdatedProperty.builder();
> withRemovedChild.compareAgainstBaseState(withProperty, new
> ConflictAnnotatingRebaseDiff(mergedBuilder));
> NodeState merged =
> ConflictHook.of(DefaultThreeWayConflictHandler.OURS).processCommit(
> mergedBuilder.getBaseState(),
> mergedBuilder.getNodeState(),
> CommitInfo.EMPTY
> );
> assertFalse(merged.hasChildNode("c"));
> {noformat}
> The assertion at the end of the code fails becauuse `merged` actually has a
> child node named `c`, and `c` is an empty node. After digging into the issue,
> I figured out that the problem is caused by the following steps.
> # {{MergingNodeStateDiff#childNodeAdded}} is invoked because of
> {{:conflicts}}. This eventually results in the deletion of the conflicting
> child node.
> # {{MergingNodeStateDiff#childNodeChanged}} is called because in
> {{ModifiedNodeState#compareAgainstBaseState}} the children are compared with
> the {{!=}} operator instead of using {{Object#equals}}.
> # {{org.apache.jackrabbit.oak.spi.state.NodeBuilder#child}} is called in
> order to setup a new {{MergingNodeStateDiff}} to descend into the subtree
> that was detected as modified.
> # {{MemoryNodeBuilder#hasChildNode}} correctly returns {{false}}, because the
> child was removed in step 1. The return value of {{false}} triggers the next
> step.
> # {{MemoryNodeBuilder#setChildNode(java.lang.String)}} is invoked in order to
> setup a new, empty child node.
> In other words, the snippet above can be rewritten like the following.
> {noformat}
> NodeState root = EmptyNodeState.EMPTY_NODE;
> NodeState withProperty;
> {
> NodeBuilder builder = root.builder();
> builder.child("c").setProperty("foo", "bar");
> withProperty = builder.getNodeState();
> }
> NodeState withUpdatedProperty;
> {
> NodeBuilder builder = withProperty.builder();
> builder.child("c").setProperty("foo", "baz");
> withUpdatedProperty = builder.getNodeState();
> }
> NodeState withRemovedChild;
> {
> NodeBuilder builder = withProperty.builder();
> builder.child("c").remove();
> withRemovedChild = builder.getNodeState();
> }
> NodeBuilder mergedBuilder = withUpdatedProperty.builder();
> // As per MergingNodeStateDiff.childNodeAdded()
> mergedBuilder.child("c").remove();
> // As per ModifiedNodeState#compareAgainstBaseState()
> if (withUpdatedProperty.getChildNode("c") !=
> withRemovedChild.getChildNode("c")) {
> // As per MergingNodeStateDiff.childNodeChanged()
> mergedBuilder.child("c");
> }
> NodeState merged = mergedBuilder.getNodeState();
> assertFalse(merged.hasChildNode("c"));
> {noformat}
> The end result is that {{MergingNodeStateDiff}} inadvertently adds the node
> that was removed in order to resolve a conflict.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-6517) ActiveDeletedBlobCollectionIT.simpleAsyncIndexUpdateBasedBlobCollection failing intermittently
[
https://issues.apache.org/jira/browse/OAK-6517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425621#comment-16425621
]
Marcel Reutegger commented on OAK-6517:
---
FTR, the same test fails slightly different on travis-ci:
{noformat}
[ERROR]
simpleAsyncIndexUpdateBasedBlobCollection[WITH_FDS](org.apache.jackrabbit.oak.plugins.index.lucene.directory.ActiveDeletedBlobCollectionIT)
Time elapsed: 3.284 s <<< ERROR!
java.lang.IllegalArgumentException: Parameter 'directory' is not a directory:
target/junit3765904078426995713/deleted-blobs
at
org.apache.jackrabbit.oak.plugins.index.lucene.directory.ActiveDeletedBlobCollectionIT.simpleAsyncIndexUpdateBasedBlobCollection(ActiveDeletedBlobCollectionIT.java:138)
{noformat}
- https://travis-ci.org/apache/jackrabbit-oak/jobs/361647772
- https://travis-ci.org/apache/jackrabbit-oak/jobs/362145860
> ActiveDeletedBlobCollectionIT.simpleAsyncIndexUpdateBasedBlobCollection
> failing intermittently
> --
>
> Key: OAK-6517
> URL: https://issues.apache.org/jira/browse/OAK-6517
> Project: Jackrabbit Oak
> Issue Type: Test
> Components: lucene
>Affects Versions: 1.7.1
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
>
> [~chetanm] reported offline that
> {{ActiveDeletedBlobCollectionIT.simpleAsyncIndexUpdateBasedBlobCollection}}
> is failing for him intermittently.
> {noformat}
> Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 5.746 sec <<<
> FAILURE! - in
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.ActiveDeletedBlobCollectionIT
> simpleAsyncIndexUpdateBasedBlobCollection[WITH_FDS](org.apache.jackrabbit.oak.plugins.index.lucene.directory.ActiveDeletedBlobCollectionIT)
> Time elapsed: 2.301 sec <<< FAILURE!
> java.lang.AssertionError: First GC should delete some chunks
>at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.ActiveDeletedBlobCollectionIT.simpleAsyncIndexUpdateBasedBlobCollection(ActiveDeletedBlobCollectionIT.java:227)
> Results :
> Failed tests:
> ActiveDeletedBlobCollectionIT.simpleAsyncIndexUpdateBasedBlobCollection:227
> First GC should delete some chunks
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (OAK-7359) Update to MongoDB Java driver 3.6
[ https://issues.apache.org/jira/browse/OAK-7359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-7359. --- Resolution: Fixed Fix Version/s: 1.9.0 Done in trunk: http://svn.apache.org/r1828349 > Update to MongoDB Java driver 3.6 > - > > Key: OAK-7359 > URL: https://issues.apache.org/jira/browse/OAK-7359 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.9.0, 1.10 > > > Update the MongoDB Java driver to 3.6 to make use of new features when > running on a MongoDB 3.6.x server. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7386) Build Jackrabbit Oak #1348 failed
[ https://issues.apache.org/jira/browse/OAK-7386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425601#comment-16425601 ] Hudson commented on OAK-7386: - Previously failing build now is OK. Passed run: [Jackrabbit Oak #1349|https://builds.apache.org/job/Jackrabbit%20Oak/1349/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/1349/console] > Build Jackrabbit Oak #1348 failed > - > > Key: OAK-7386 > URL: https://issues.apache.org/jira/browse/OAK-7386 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #1348 has failed. > First failed run: [Jackrabbit Oak > #1348|https://builds.apache.org/job/Jackrabbit%20Oak/1348/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/1348/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (OAK-7384) SegmentNodeStoreStats should expose stats for previous minute per thread group
[
https://issues.apache.org/jira/browse/OAK-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu resolved OAK-7384.
--
Resolution: Fixed
Fixed at r1828345.
> SegmentNodeStoreStats should expose stats for previous minute per thread group
> --
>
> Key: OAK-7384
> URL: https://issues.apache.org/jira/browse/OAK-7384
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
> Labels: tooling
> Fix For: 1.9.0, 1.10
>
> Attachments: OAK-7384.patch
>
>
> The current "CommitsCountPerWriter" stats exposed by
> {{SegmentNodeStoreStats}} are hard to follow since there can be too many
> writers at a time. To improve this, a more coarse-grained version of this
> metric should be added, in which commits are recorded for groups of threads.
> The groups should be configurable and represent regexes to be matched by
> individual thread names. An additional group (i.e. "other") will group all
> threads not matching any of the defined group regexes.
> The current behaviour will be split in two:
> * "CommitsCountOtherThreads" will expose a snapshot of threads currently in
> "other" group
> * "CommitsCountPerGroup" will expose an aggregate of commits count per thread
> group for the previous minute.
> Both metrics will be reset each minute.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-7388) MergingNodeStateDiff may recreate nodes that were previously removed to resolve conflicts
[
https://issues.apache.org/jira/browse/OAK-7388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425526#comment-16425526
]
Francesco Mari commented on OAK-7388:
-
I added a failing unit test at r1828343.
> MergingNodeStateDiff may recreate nodes that were previously removed to
> resolve conflicts
> -
>
> Key: OAK-7388
> URL: https://issues.apache.org/jira/browse/OAK-7388
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Francesco Mari
>Assignee: Francesco Mari
>Priority: Major
> Fix For: 1.10
>
>
> {{MergingNodeStateDiff}} might behave incorrectly when the resolution of a
> conflict involves the deletion of the conflicting node. I spotted this issue
> in a use case that can be expressed by the following code.
> {noformat}
> NodeState root = EmptyNodeState.EMPTY_NODE;
> NodeState withProperty;
> {
> NodeBuilder builder = root.builder();
> builder.child("c").setProperty("foo", "bar");
> withProperty = builder.getNodeState();
> }
> NodeState withUpdatedProperty;
> {
> NodeBuilder builder = withProperty.builder();
> builder.child("c").setProperty("foo", "baz");
> withUpdatedProperty = builder.getNodeState();
> }
> NodeState withRemovedChild;
> {
> NodeBuilder builder = withProperty.builder();
> builder.child("c").remove();
> withRemovedChild = builder.getNodeState();
> }
> NodeBuilder mergedBuilder = withUpdatedProperty.builder();
> withRemovedChild.compareAgainstBaseState(withProperty, new
> ConflictAnnotatingRebaseDiff(mergedBuilder));
> NodeState merged =
> ConflictHook.of(DefaultThreeWayConflictHandler.OURS).processCommit(
> mergedBuilder.getBaseState(),
> mergedBuilder.getNodeState(),
> CommitInfo.EMPTY
> );
> assertFalse(merged.hasChildNode("c"));
> {noformat}
> The assertion at the end of the code fails becauuse `merged` actually has a
> child node named `c`, and `c` is an empty node. After digging into the issue,
> I figured out that the problem is caused by the following steps.
> # {{MergingNodeStateDiff#childNodeAdded}} is invoked because of
> {{:conflicts}}. This eventually results in the deletion of the conflicting
> child node.
> # {{MergingNodeStateDiff#childNodeChanged}} is called because in
> {{ModifiedNodeState#compareAgainstBaseState}} the children are compared with
> the {{!=}} operator instead of using {{Object#equals}}.
> # {{org.apache.jackrabbit.oak.spi.state.NodeBuilder#child}} is called in
> order to setup a new {{MergingNodeStateDiff}} to descend into the subtree
> that was detected as modified.
> # {{MemoryNodeBuilder#hasChildNode}} correctly returns {{false}}, because the
> child was removed in step 1. The return value of {{false}} triggers the next
> step.
> # {{MemoryNodeBuilder#setChildNode(java.lang.String)}} is invoked in order to
> setup a new, empty child node.
> In other words, the snippet above can be rewritten like the following.
> {noformat}
> NodeState root = EmptyNodeState.EMPTY_NODE;
> NodeState withProperty;
> {
> NodeBuilder builder = root.builder();
> builder.child("c").setProperty("foo", "bar");
> withProperty = builder.getNodeState();
> }
> NodeState withUpdatedProperty;
> {
> NodeBuilder builder = withProperty.builder();
> builder.child("c").setProperty("foo", "baz");
> withUpdatedProperty = builder.getNodeState();
> }
> NodeState withRemovedChild;
> {
> NodeBuilder builder = withProperty.builder();
> builder.child("c").remove();
> withRemovedChild = builder.getNodeState();
> }
> NodeBuilder mergedBuilder = withUpdatedProperty.builder();
> // As per MergingNodeStateDiff.childNodeAdded()
> mergedBuilder.child("c").remove();
> // As per ModifiedNodeState#compareAgainstBaseState()
> if (withUpdatedProperty.getChildNode("c") !=
> withRemovedChild.getChildNode("c")) {
> // As per MergingNodeStateDiff.childNodeChanged()
> mergedBuilder.child("c");
> }
> NodeState merged = mergedBuilder.getNodeState();
> assertFalse(merged.hasChildNode("c"));
> {noformat}
> The end result is that {{MergingNodeStateDiff}} inadvertently adds the node
> that was removed in order to resolve a conflict.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-7388) MergingNodeStateDiff may recreate nodes that were previously removed to resolve conflicts
[
https://issues.apache.org/jira/browse/OAK-7388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425486#comment-16425486
]
Michael Dürig commented on OAK-7388:
Excellent analysis! The first snipped of code should be made into a unit test.
And of course we should try to fix this!
> MergingNodeStateDiff may recreate nodes that were previously removed to
> resolve conflicts
> -
>
> Key: OAK-7388
> URL: https://issues.apache.org/jira/browse/OAK-7388
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Francesco Mari
>Assignee: Francesco Mari
>Priority: Major
> Fix For: 1.10
>
>
> {{MergingNodeStateDiff}} might behave incorrectly when the resolution of a
> conflict involves the deletion of the conflicting node. I spotted this issue
> in a use case that can be expressed by the following code.
> {noformat}
> NodeState root = EmptyNodeState.EMPTY_NODE;
> NodeState withProperty;
> {
> NodeBuilder builder = root.builder();
> builder.child("c").setProperty("foo", "bar");
> withProperty = builder.getNodeState();
> }
> NodeState withUpdatedProperty;
> {
> NodeBuilder builder = withProperty.builder();
> builder.child("c").setProperty("foo", "baz");
> withUpdatedProperty = builder.getNodeState();
> }
> NodeState withRemovedChild;
> {
> NodeBuilder builder = withProperty.builder();
> builder.child("c").remove();
> withRemovedChild = builder.getNodeState();
> }
> NodeBuilder mergedBuilder = withUpdatedProperty.builder();
> withRemovedChild.compareAgainstBaseState(withProperty, new
> ConflictAnnotatingRebaseDiff(mergedBuilder));
> NodeState merged =
> ConflictHook.of(DefaultThreeWayConflictHandler.OURS).processCommit(
> mergedBuilder.getBaseState(),
> mergedBuilder.getNodeState(),
> CommitInfo.EMPTY
> );
> assertFalse(merged.hasChildNode("c"));
> {noformat}
> The assertion at the end of the code fails becauuse `merged` actually has a
> child node named `c`, and `c` is an empty node. After digging into the issue,
> I figured out that the problem is caused by the following steps.
> # {{MergingNodeStateDiff#childNodeAdded}} is invoked because of
> {{:conflicts}}. This eventually results in the deletion of the conflicting
> child node.
> # {{MergingNodeStateDiff#childNodeChanged}} is called because in
> {{ModifiedNodeState#compareAgainstBaseState}} the children are compared with
> the {{!=}} operator instead of using {{Object#equals}}.
> # {{org.apache.jackrabbit.oak.spi.state.NodeBuilder#child}} is called in
> order to setup a new {{MergingNodeStateDiff}} to descend into the subtree
> that was detected as modified.
> # {{MemoryNodeBuilder#hasChildNode}} correctly returns {{false}}, because the
> child was removed in step 1. The return value of {{false}} triggers the next
> step.
> # {{MemoryNodeBuilder#setChildNode(java.lang.String)}} is invoked in order to
> setup a new, empty child node.
> In other words, the snippet above can be rewritten like the following.
> {noformat}
> NodeState root = EmptyNodeState.EMPTY_NODE;
> NodeState withProperty;
> {
> NodeBuilder builder = root.builder();
> builder.child("c").setProperty("foo", "bar");
> withProperty = builder.getNodeState();
> }
> NodeState withUpdatedProperty;
> {
> NodeBuilder builder = withProperty.builder();
> builder.child("c").setProperty("foo", "baz");
> withUpdatedProperty = builder.getNodeState();
> }
> NodeState withRemovedChild;
> {
> NodeBuilder builder = withProperty.builder();
> builder.child("c").remove();
> withRemovedChild = builder.getNodeState();
> }
> NodeBuilder mergedBuilder = withUpdatedProperty.builder();
> // As per MergingNodeStateDiff.childNodeAdded()
> mergedBuilder.child("c").remove();
> // As per ModifiedNodeState#compareAgainstBaseState()
> if (withUpdatedProperty.getChildNode("c") !=
> withRemovedChild.getChildNode("c")) {
> // As per MergingNodeStateDiff.childNodeChanged()
> mergedBuilder.child("c");
> }
> NodeState merged = mergedBuilder.getNodeState();
> assertFalse(merged.hasChildNode("c"));
> {noformat}
> The end result is that {{MergingNodeStateDiff}} inadvertently adds the node
> that was removed in order to resolve a conflict.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-6584) Add tooling API
[
https://issues.apache.org/jira/browse/OAK-6584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425483#comment-16425483
]
Michael Dürig commented on OAK-6584:
To get started with my tooling based on Oak tooling API build and install to
your local Maven cache (in this order):
* Tool API: [https://github.com/mduerig/oak-tooling-api]
* Initial impl: [https://github.com/mduerig/jackrabbit-oak/commits/OAK-6584]
* Script Oak: [https://github.com/mduerig/script-oak/commits/OAK-6584]
If all goes well this creates a
{{script-oak-reactor/script-oak-shell/target/script-oak-shell-1.3-SNAPSHOT.jar}}.
Now cd to a repository folder (i.e. such that there is a folder
{{segmentstore}} in {{ls .}}). Now the script oak shell and hack away:
{code}
java -jar script-oak-shell-1.3-SNAPSHOT.jar
Welcome to Script Oak 1.3-SNAPSHOT / oak-1.7.8
@ val fs = fileStoreAnalyser()
fs: filestore.FileStoreAnalyser =
michid.script.oak.fixture.package$$anon$1@1c807b1d
@ val sroot = fs.getNode("/").analyse
sroot: nodestore.Items.Node = Node(Node(null, "", { }), "", { checkpoints = {
... }, root = { ... } })
@ import michid.script.oak.nodestore.Items._
import michid.script.oak.nodestore.Items._
@ val nodes = collectNodes(sroot)
nodes: Iterable[Node] = Items(
Node(Node(null, "", { }), "", { checkpoints = { ... }, root = { ... } }),
Node(
Node(Node(null, "", { }), "", { checkpoints = { ... }, root = { ... } }),
"checkpoints",
{ ff9ea4dc-bca4-47b7-bb21-5ff0bed6e678 = { ... },
c19a503b-61fe-4291-b591-bc708184badf = { ... } }
),
Node(
Node(
Node(Node(null, "", { }), "", { checkpoints = { ... }, root = { ... } }),
"checkpoints",
{ ff9ea4dc-bca4-47b7-bb21-5ff0bed6e678 = { ... },
c19a503b-61fe-4291-b591-bc708184badf = { ... } }
),
"ff9ea4dc-bca4-47b7-bb21-5ff0bed6e678",
...
@ browse(nodes.take(100))
{code}
To learn more about the Shell see: http://ammonite.io/
To learn more about Script Oak see:
https://github.com/mduerig/script-oak/blob/master/script-oak-core/src/main/resources/scripts/FileStoreDemo.sc
> Add tooling API
> ---
>
> Key: OAK-6584
> URL: https://issues.apache.org/jira/browse/OAK-6584
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Major
> Labels: tooling
> Fix For: 1.10
>
>
> h3. Current situation
> Current segment store related tools are implemented ad-hoc by potentially
> relying on internal implementation details of Oak Segment Tar. This makes
> those tools less useful, portable, stable and potentially applicable than
> they should be.
> h3. Goal
> Provide a common and sufficiently stable Oak Tooling API for implementing
> segment store related tools. The API should be independent of Oak and not
> available for normal production use of Oak. Specifically it should not be
> possible to it to implement production features and production features must
> not rely on it. It must be possible to implement the Oak Tooling API in Oak
> 1.8 and it should be possible for Oak 1.6.
> h3. Typical use cases
> * Query the number of nodes / properties / values in a given path satisfying
> some criteria
> * Aggregate a certain value on queries like the above
> * Calculate size of the content / size on disk
> * Analyse changes. E.g. how many binaries bigger than a certain threshold
> were added / removed between two given revisions. What is the sum of their
> sizes?
> * Analyse locality: measure of locality of node states. Incident plots (See
> https://issues.apache.org/jira/browse/OAK-5655?focusedCommentId=15865973=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15865973).
> * Analyse level of deduplication (e.g. of checkpoint)
> h3. Validation
> Reimplement [Script Oak|https://github.com/mduerig/script-oak] on top of the
> tooling API.
> h3. API draft
> * Whiteboard shot of the [API
> entities|https://wiki.apache.org/jackrabbit/Oakathon%20August%202017?action=AttachFile=view=IMG_20170822_163256.jpg]
> identified initially.
> * Further [drafting of the API|https://github.com/mduerig/oak-tooling-api]
> takes place on Github for now. We'll move to the Apache SVN as soon as
> considered mature enough and have a consensus of where to best move it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OAK-7388) MergingNodeStateDiff may recreate nodes that were previously removed to resolve conflicts
Francesco Mari created OAK-7388:
---
Summary: MergingNodeStateDiff may recreate nodes that were
previously removed to resolve conflicts
Key: OAK-7388
URL: https://issues.apache.org/jira/browse/OAK-7388
Project: Jackrabbit Oak
Issue Type: Improvement
Components: core
Reporter: Francesco Mari
Assignee: Francesco Mari
Fix For: 1.10
{{MergingNodeStateDiff}} might behave incorrectly when the resolution of a
conflict involves the deletion of the conflicting node. I spotted this issue in
a use case that can be expressed by the following code.
{noformat}
NodeState root = EmptyNodeState.EMPTY_NODE;
NodeState withProperty;
{
NodeBuilder builder = root.builder();
builder.child("c").setProperty("foo", "bar");
withProperty = builder.getNodeState();
}
NodeState withUpdatedProperty;
{
NodeBuilder builder = withProperty.builder();
builder.child("c").setProperty("foo", "baz");
withUpdatedProperty = builder.getNodeState();
}
NodeState withRemovedChild;
{
NodeBuilder builder = withProperty.builder();
builder.child("c").remove();
withRemovedChild = builder.getNodeState();
}
NodeBuilder mergedBuilder = withUpdatedProperty.builder();
withRemovedChild.compareAgainstBaseState(withProperty, new
ConflictAnnotatingRebaseDiff(mergedBuilder));
NodeState merged =
ConflictHook.of(DefaultThreeWayConflictHandler.OURS).processCommit(
mergedBuilder.getBaseState(),
mergedBuilder.getNodeState(),
CommitInfo.EMPTY
);
assertFalse(merged.hasChildNode("c"));
{noformat}
The assertion at the end of the code fails becauuse `merged` actually has a
child node named `c`, and `c` is an empty node. After digging into the issue, I
figured out that the problem is caused by the following steps.
# {{MergingNodeStateDiff#childNodeAdded}} is invoked because of {{:conflicts}}.
This eventually results in the deletion of the conflicting child node.
# {{MergingNodeStateDiff#childNodeChanged}} is called because in
{{ModifiedNodeState#compareAgainstBaseState}} the children are compared with
the {{!=}} operator instead of using {{Object#equals}}.
# {{org.apache.jackrabbit.oak.spi.state.NodeBuilder#child}} is called in order
to setup a new {{MergingNodeStateDiff}} to descend into the subtree that was
detected as modified.
# {{MemoryNodeBuilder#hasChildNode}} correctly returns {{false}}, because the
child was removed in step 1. The return value of {{false}} triggers the next
step.
# {{MemoryNodeBuilder#setChildNode(java.lang.String)}} is invoked in order to
setup a new, empty child node.
In other words, the snippet above can be rewritten like the following.
{noformat}
NodeState root = EmptyNodeState.EMPTY_NODE;
NodeState withProperty;
{
NodeBuilder builder = root.builder();
builder.child("c").setProperty("foo", "bar");
withProperty = builder.getNodeState();
}
NodeState withUpdatedProperty;
{
NodeBuilder builder = withProperty.builder();
builder.child("c").setProperty("foo", "baz");
withUpdatedProperty = builder.getNodeState();
}
NodeState withRemovedChild;
{
NodeBuilder builder = withProperty.builder();
builder.child("c").remove();
withRemovedChild = builder.getNodeState();
}
NodeBuilder mergedBuilder = withUpdatedProperty.builder();
// As per MergingNodeStateDiff.childNodeAdded()
mergedBuilder.child("c").remove();
// As per ModifiedNodeState#compareAgainstBaseState()
if (withUpdatedProperty.getChildNode("c") !=
withRemovedChild.getChildNode("c")) {
// As per MergingNodeStateDiff.childNodeChanged()
mergedBuilder.child("c");
}
NodeState merged = mergedBuilder.getNodeState();
assertFalse(merged.hasChildNode("c"));
{noformat}
The end result is that {{MergingNodeStateDiff}} inadvertently adds the node
that was removed in order to resolve a conflict.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-3336) Abstract a full text index implementation to be extended by Lucene and Solr
[ https://issues.apache.org/jira/browse/OAK-3336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425456#comment-16425456 ] Tommaso Teofili commented on OAK-3336: -- created (empty) _oak-search_ module in r1828335. > Abstract a full text index implementation to be extended by Lucene and Solr > --- > > Key: OAK-3336 > URL: https://issues.apache.org/jira/browse/OAK-3336 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene, query, solr >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili >Priority: Major > Fix For: 1.10 > > > Current Lucene and Solr indexes implement quite a no. of features according > to their specific APIs, design and implementation. However in the long run, > while differences in APIs and implementations will / can of course stay, the > difference in design can make it hard to keep those features on par. > It'd be therefore nice to make it possible to abstract as much of design and > implementation bits as possible in an abstract full text implementation which > Lucene and Solr would extend according to their specifics. > An example advantage of this is that index time aggregation will be > implemented only once and therefore any bugfixes and improvements in that > area will be done in the abstract implementation rather than having to do > that in two places. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-6584) Add tooling API
[ https://issues.apache.org/jira/browse/OAK-6584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425451#comment-16425451 ] Michael Dürig commented on OAK-6584: [~frm], [~dulceanu], [~volteanu], my previous comment from last November still applies. Would be good to start reviewing the tool API and the latest changes I did there ([https://github.com/mduerig/oak-tooling-api|https://github.com/mduerig/oak-tooling-api]) and my initial implementation of it ([https://github.com/mduerig/jackrabbit-oak/commits/OAK-6584]). > Add tooling API > --- > > Key: OAK-6584 > URL: https://issues.apache.org/jira/browse/OAK-6584 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: segment-tar >Reporter: Michael Dürig >Assignee: Michael Dürig >Priority: Major > Labels: tooling > Fix For: 1.10 > > > h3. Current situation > Current segment store related tools are implemented ad-hoc by potentially > relying on internal implementation details of Oak Segment Tar. This makes > those tools less useful, portable, stable and potentially applicable than > they should be. > h3. Goal > Provide a common and sufficiently stable Oak Tooling API for implementing > segment store related tools. The API should be independent of Oak and not > available for normal production use of Oak. Specifically it should not be > possible to it to implement production features and production features must > not rely on it. It must be possible to implement the Oak Tooling API in Oak > 1.8 and it should be possible for Oak 1.6. > h3. Typical use cases > * Query the number of nodes / properties / values in a given path satisfying > some criteria > * Aggregate a certain value on queries like the above > * Calculate size of the content / size on disk > * Analyse changes. E.g. how many binaries bigger than a certain threshold > were added / removed between two given revisions. What is the sum of their > sizes? > * Analyse locality: measure of locality of node states. Incident plots (See > https://issues.apache.org/jira/browse/OAK-5655?focusedCommentId=15865973=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15865973). > * Analyse level of deduplication (e.g. of checkpoint) > h3. Validation > Reimplement [Script Oak|https://github.com/mduerig/script-oak] on top of the > tooling API. > h3. API draft > * Whiteboard shot of the [API > entities|https://wiki.apache.org/jackrabbit/Oakathon%20August%202017?action=AttachFile=view=IMG_20170822_163256.jpg] > identified initially. > * Further [drafting of the API|https://github.com/mduerig/oak-tooling-api] > takes place on Github for now. We'll move to the Apache SVN as soon as > considered mature enough and have a consensus of where to best move it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-7387) Update Oak trunk to Jackrabbit 2.17.2
Julian Reschke created OAK-7387: --- Summary: Update Oak trunk to Jackrabbit 2.17.2 Key: OAK-7387 URL: https://issues.apache.org/jira/browse/OAK-7387 Project: Jackrabbit Oak Issue Type: Task Components: parent Reporter: Julian Reschke Assignee: Julian Reschke -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7384) SegmentNodeStoreStats should expose stats for previous minute per thread group
[
https://issues.apache.org/jira/browse/OAK-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425360#comment-16425360
]
Michael Dürig commented on OAK-7384:
+1, looks good!
> SegmentNodeStoreStats should expose stats for previous minute per thread group
> --
>
> Key: OAK-7384
> URL: https://issues.apache.org/jira/browse/OAK-7384
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
> Labels: tooling
> Fix For: 1.9.0, 1.10
>
> Attachments: OAK-7384.patch
>
>
> The current "CommitsCountPerWriter" stats exposed by
> {{SegmentNodeStoreStats}} are hard to follow since there can be too many
> writers at a time. To improve this, a more coarse-grained version of this
> metric should be added, in which commits are recorded for groups of threads.
> The groups should be configurable and represent regexes to be matched by
> individual thread names. An additional group (i.e. "other") will group all
> threads not matching any of the defined group regexes.
> The current behaviour will be split in two:
> * "CommitsCountOtherThreads" will expose a snapshot of threads currently in
> "other" group
> * "CommitsCountPerGroup" will expose an aggregate of commits count per thread
> group for the previous minute.
> Both metrics will be reset each minute.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-7384) SegmentNodeStoreStats should expose stats for previous minute per thread group
[
https://issues.apache.org/jira/browse/OAK-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425357#comment-16425357
]
Andrei Dulceanu commented on OAK-7384:
--
Thanks for reviewing the initial patch, [~mduerig]! I included the changes you
suggested at [0] to track/compare them easier. Could you take another look,
please?
[0] https://github.com/dulceanu/jackrabbit-oak/tree/issues/OAK-7384
> SegmentNodeStoreStats should expose stats for previous minute per thread group
> --
>
> Key: OAK-7384
> URL: https://issues.apache.org/jira/browse/OAK-7384
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
> Labels: tooling
> Fix For: 1.9.0, 1.10
>
> Attachments: OAK-7384.patch
>
>
> The current "CommitsCountPerWriter" stats exposed by
> {{SegmentNodeStoreStats}} are hard to follow since there can be too many
> writers at a time. To improve this, a more coarse-grained version of this
> metric should be added, in which commits are recorded for groups of threads.
> The groups should be configurable and represent regexes to be matched by
> individual thread names. An additional group (i.e. "other") will group all
> threads not matching any of the defined group regexes.
> The current behaviour will be split in two:
> * "CommitsCountOtherThreads" will expose a snapshot of threads currently in
> "other" group
> * "CommitsCountPerGroup" will expose an aggregate of commits count per thread
> group for the previous minute.
> Both metrics will be reset each minute.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-6209) The benchmark runner should produce machine-friendly output
[
https://issues.apache.org/jira/browse/OAK-6209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425135#comment-16425135
]
Francesco Mari commented on OAK-6209:
-
[~maksim_kviatkouski], for whatever reason I can't assign the issue to you. I
assigned the issue to myself since I'm going to follow your work. I hope that
works for you.
> The benchmark runner should produce machine-friendly output
> ---
>
> Key: OAK-6209
> URL: https://issues.apache.org/jira/browse/OAK-6209
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: benchmarks
>Reporter: Francesco Mari
>Assignee: Francesco Mari
>Priority: Major
>
> The benchmark runner currently produce output in the following format.
> {noformat}
> Apache Jackrabbit Oak 1.8-SNAPSHOT
> # LoginTestC min 10% 50% 90% max
> N
> Oak-Segment-Tar1 472 494 522 552 631
>115
> # LoginLogoutTest C min 10% 50% 90% max
> N
> Oak-Segment-Tar1 472 479 513 543 568
>118
> {noformat}
> While this format is well formatted and easy to read, it's a pain to process
> with standard command line utilities. The benchmark runner should give the
> possibility to produce machine-friendly output, like the following.
> {noformat}
> LoginTest,Oak-Segment-Tar,1,472,494,522,552,631,115
> LoginLogoutTest,Oak-Segment-Tar,1,472,479,513,543,568,118
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (OAK-6209) The benchmark runner should produce machine-friendly output
[
https://issues.apache.org/jira/browse/OAK-6209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari reassigned OAK-6209:
---
Assignee: Francesco Mari
> The benchmark runner should produce machine-friendly output
> ---
>
> Key: OAK-6209
> URL: https://issues.apache.org/jira/browse/OAK-6209
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: benchmarks
>Reporter: Francesco Mari
>Assignee: Francesco Mari
>Priority: Major
>
> The benchmark runner currently produce output in the following format.
> {noformat}
> Apache Jackrabbit Oak 1.8-SNAPSHOT
> # LoginTestC min 10% 50% 90% max
> N
> Oak-Segment-Tar1 472 494 522 552 631
>115
> # LoginLogoutTest C min 10% 50% 90% max
> N
> Oak-Segment-Tar1 472 479 513 543 568
>118
> {noformat}
> While this format is well formatted and easy to read, it's a pain to process
> with standard command line utilities. The benchmark runner should give the
> possibility to produce machine-friendly output, like the following.
> {noformat}
> LoginTest,Oak-Segment-Tar,1,472,494,522,552,631,115
> LoginLogoutTest,Oak-Segment-Tar,1,472,479,513,543,568,118
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
