[jira] [Created] (OAK-7417) Build Jackrabbit Oak #1379 failed
Hudson created OAK-7417: --- Summary: Build Jackrabbit Oak #1379 failed Key: OAK-7417 URL: https://issues.apache.org/jira/browse/OAK-7417 Project: Jackrabbit Oak Issue Type: Bug Components: continuous integration Reporter: Hudson No description is provided The build Jackrabbit Oak #1379 has failed. First failed run: [Jackrabbit Oak #1379|https://builds.apache.org/job/Jackrabbit%20Oak/1379/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/1379/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7254) Indexes with excludedPaths, or includedPaths should not be picked for queries without path
[
https://issues.apache.org/jira/browse/OAK-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-7254:
Sprint: L16
> Indexes with excludedPaths, or includedPaths should not be picked for queries
> without path
> --
>
> Key: OAK-7254
> URL: https://issues.apache.org/jira/browse/OAK-7254
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene, query
>Reporter: Thomas Mueller
>Assignee: Matt Ryan
>Priority: Critical
> Fix For: 1.10
>
>
> Queries that don't have a clear path restriction should not use indexes that
> have excludedPaths or includedPaths set, except in some exceptional cases (to
> be defined).
> For example, if a query doesn't have a path restriction, say:
> {noformat}
> /jcr:root//element(*, nt:base)[@status='RUNNING']
> {noformat}
> Then an index that has excludedPaths set (for example to /etc) shouldn't be
> used, at least not if a different index is available. Currently it is used
> currently, actually in _favor_ of another index, if the property "status" is
> commonly used in /etc. Because of that, the index that doesn't have
> excludedPath has a higher cost (as it indexes the property "status" in /etc,
> and so has more entries for "status", than the index that doesn't index /etc).
> The same for includedPaths, in case queryPaths isn't set to the same value(s).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7416) Contribute a 'proc' subtree for the Segment Node Store
[ https://issues.apache.org/jira/browse/OAK-7416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-7416: --- Labels: tooling (was: ) > Contribute a 'proc' subtree for the Segment Node Store > -- > > Key: OAK-7416 > URL: https://issues.apache.org/jira/browse/OAK-7416 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar >Reporter: Francesco Mari >Assignee: Francesco Mari >Priority: Major > Labels: tooling > Fix For: 1.10 > > > With guidance from [~mduerig], I recently developed a way to expose Segment > Node Store's internal information through the NodeState API. > The concept is similar in spirit to the proc file system in Linux: the proc > subtree exposes internal information in a straightforward manner, enabling > consumers to rely on a well-understood API to access the data. This proc > subtree shelters tooling from variations of the internal APIs of the Segment > Store. As long as the data exported through the proc subtree is stable, the > same tools are going to work across different versions of the Segment Store > with minimal to no modifications. > The proc subtree has been developed in [this branch on > GitHub|https://github.com/francescomari/jackrabbit-oak/tree/proc]. I created > this issue in order to review the work done so far, and to track the > contribution of the proc subtree in Oak. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7416) Contribute a 'proc' subtree for the Segment Node Store
[ https://issues.apache.org/jira/browse/OAK-7416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16440531#comment-16440531 ] Michael Dürig commented on OAK-7416: [~frm] from my perspective as a user of this feature via [https://github.com/mduerig/oak-tooling-api/commits/proc] and [https://github.com/mduerig/script-oak/commits/proc] this is tremendously useful. It eases a lot of the pain described in OAK-6584. IMO we should * care fully review your branch * contribute it to Oak trunk * resolve OAK-6584 as superseded by this issue. Will follow up with a more detailed review of your branch later today. > Contribute a 'proc' subtree for the Segment Node Store > -- > > Key: OAK-7416 > URL: https://issues.apache.org/jira/browse/OAK-7416 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar >Reporter: Francesco Mari >Assignee: Francesco Mari >Priority: Major > Fix For: 1.10 > > > With guidance from [~mduerig], I recently developed a way to expose Segment > Node Store's internal information through the NodeState API. > The concept is similar in spirit to the proc file system in Linux: the proc > subtree exposes internal information in a straightforward manner, enabling > consumers to rely on a well-understood API to access the data. This proc > subtree shelters tooling from variations of the internal APIs of the Segment > Store. As long as the data exported through the proc subtree is stable, the > same tools are going to work across different versions of the Segment Store > with minimal to no modifications. > The proc subtree has been developed in [this branch on > GitHub|https://github.com/francescomari/jackrabbit-oak/tree/proc]. I created > this issue in order to review the work done so far, and to track the > contribution of the proc subtree in Oak. -- 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=16440500#comment-16440500
]
Francesco Mari commented on OAK-6209:
-
[~maksim_kviatkouski], sorry, my bad. I was confused by the fact that
{{CSVResultGenerator}} is implemented by both {{AbstractTest}} and
{{ScalabilityAbstractSuite}}, but there is no relation between the two
implementations. There is no need to touch {{ScalabilityAbstractSuite}} and
related classes, it's definitely out of scope. In the light of this, I wonder
whether {{AbstractTest}} should still implement {{CSVResultGenerator}}.
> 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
> Attachments: oak-6209.patch, oak-6209.patch,
> sample-machine-readable-output.txt
>
>
> 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] [Created] (OAK-7416) Contribute a 'proc' subtree for the Segment Node Store
Francesco Mari created OAK-7416: --- Summary: Contribute a 'proc' subtree for the Segment Node Store Key: OAK-7416 URL: https://issues.apache.org/jira/browse/OAK-7416 Project: Jackrabbit Oak Issue Type: Improvement Components: segment-tar Reporter: Francesco Mari Assignee: Francesco Mari Fix For: 1.10 With guidance from [~mduerig], I recently developed a way to expose Segment Node Store's internal information through the NodeState API. The concept is similar in spirit to the proc file system in Linux: the proc subtree exposes internal information in a straightforward manner, enabling consumers to rely on a well-understood API to access the data. This proc subtree shelters tooling from variations of the internal APIs of the Segment Store. As long as the data exported through the proc subtree is stable, the same tools are going to work across different versions of the Segment Store with minimal to no modifications. The proc subtree has been developed in [this branch on GitHub|https://github.com/francescomari/jackrabbit-oak/tree/proc]. I created this issue in order to review the work done so far, and to track the contribution of the proc subtree in Oak. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
