[jira] [Closed] (OAK-6132) Backport oak-upgrade to 1.0 and 1.2
[ https://issues.apache.org/jira/browse/OAK-6132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain closed OAK-6132. -- Close for 1.2.26 > Backport oak-upgrade to 1.0 and 1.2 > --- > > Key: OAK-6132 > URL: https://issues.apache.org/jira/browse/OAK-6132 > Project: Jackrabbit Oak > Issue Type: Task > Components: upgrade >Reporter: Tomek Rękawek >Assignee: Tomek Rękawek > Fix For: 1.0.39, 1.2.26 > > > Similarly to OAK-5290, let's use the trunk version of oak-upgrade in 1.0 and > 1.2 branches. They are very outdated, so backporting all the missing issues > would be very expensive. Branches 1.4 and 1.6 are up-to-date already. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (OAK-6266) SolrQueryIndexProviderService should always have NodeAggregator
[
https://issues.apache.org/jira/browse/OAK-6266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amit Jain closed OAK-6266.
--
Close for 1.2.26
> SolrQueryIndexProviderService should always have NodeAggregator
> ---
>
> Key: OAK-6266
> URL: https://issues.apache.org/jira/browse/OAK-6266
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: solr
>Affects Versions: 1.2.25
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: 1.8, 1.7.1, 1.6.2, 1.4.16, 1.2.26
>
>
> Currently the {{SolrQueryIndexProviderService}} has an optional reference to
> {{NodeAggregator}} which results in unexpected results, especially when query
> time aggregation is used. Such a reference should just be required.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6316) Build Jackrabbit Oak #394 failed
[ https://issues.apache.org/jira/browse/OAK-6316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16041306#comment-16041306 ] Hudson commented on OAK-6316: - Previously failing build now is OK. Passed run: [Jackrabbit Oak #397|https://builds.apache.org/job/Jackrabbit%20Oak/397/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/397/console] > Build Jackrabbit Oak #394 failed > > > Key: OAK-6316 > URL: https://issues.apache.org/jira/browse/OAK-6316 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson > > Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/ > The build Jackrabbit Oak #394 has failed. > First failed run: [Jackrabbit Oak > #394|https://builds.apache.org/job/Jackrabbit%20Oak/394/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/394/console] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-6316) Build Jackrabbit Oak #394 failed
[ https://issues.apache.org/jira/browse/OAK-6316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16041175#comment-16041175 ] Hudson commented on OAK-6316: - Previously failing build now is OK. Passed run: [Jackrabbit Oak #396|https://builds.apache.org/job/Jackrabbit%20Oak/396/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/396/console] > Build Jackrabbit Oak #394 failed > > > Key: OAK-6316 > URL: https://issues.apache.org/jira/browse/OAK-6316 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson > > Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/ > The build Jackrabbit Oak #394 has failed. > First failed run: [Jackrabbit Oak > #394|https://builds.apache.org/job/Jackrabbit%20Oak/394/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/394/console] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (OAK-6297) SimpleExcerptProvider may be package private and moved to o.a.j.oak.query
[
https://issues.apache.org/jira/browse/OAK-6297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved OAK-6297.
-
Resolution: Fixed
Committed revision 1797967.
> SimpleExcerptProvider may be package private and moved to o.a.j.oak.query
> -
>
> Key: OAK-6297
> URL: https://issues.apache.org/jira/browse/OAK-6297
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, query
>Reporter: angela
>Priority: Minor
> Attachments: OAK-6297.patch
>
>
> the utility {{o.a.j.oak.fulltext.SimpleExcerptProvider}} has a single usage
> inside the {{o.a.j.oak.query}} package space {{ResultRowImpl}}. therefore i
> would suggest to move it to {{o.a.j.oak.query}} and mark it package private.
> [~tmueller], i would appreciate if you could review the patch for this move.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6316) Build Jackrabbit Oak #394 failed
[ https://issues.apache.org/jira/browse/OAK-6316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16041051#comment-16041051 ] Hudson commented on OAK-6316: - Previously failing build now is OK. Passed run: [Jackrabbit Oak #395|https://builds.apache.org/job/Jackrabbit%20Oak/395/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/395/console] > Build Jackrabbit Oak #394 failed > > > Key: OAK-6316 > URL: https://issues.apache.org/jira/browse/OAK-6316 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson > > Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/ > The build Jackrabbit Oak #394 has failed. > First failed run: [Jackrabbit Oak > #394|https://builds.apache.org/job/Jackrabbit%20Oak/394/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/394/console] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-6315) Create CheckpointMBean implementation for the composite node store
[ https://issues.apache.org/jira/browse/OAK-6315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16041013#comment-16041013 ] Tomek Rękawek commented on OAK-6315: Fixed for trunk in [r1797938|https://svn.apache.org/r1797938]. > Create CheckpointMBean implementation for the composite node store > -- > > Key: OAK-6315 > URL: https://issues.apache.org/jira/browse/OAK-6315 > Project: Jackrabbit Oak > Issue Type: Task > Components: composite >Reporter: Tomek Rękawek >Assignee: Tomek Rękawek > Fix For: 1.8, 1.7.3 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-6315) Create CheckpointMBean implementation for the composite node store
[ https://issues.apache.org/jira/browse/OAK-6315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomek Rękawek updated OAK-6315: --- Fix Version/s: 1.7.3 > Create CheckpointMBean implementation for the composite node store > -- > > Key: OAK-6315 > URL: https://issues.apache.org/jira/browse/OAK-6315 > Project: Jackrabbit Oak > Issue Type: Task > Components: composite >Reporter: Tomek Rękawek >Assignee: Tomek Rękawek > Fix For: 1.8, 1.7.3 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (OAK-6311) Move generic part of PropertyStateValue and PropertyValues to oak-store-spi
[
https://issues.apache.org/jira/browse/OAK-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16040681#comment-16040681
]
angela edited comment on OAK-6311 at 6/7/17 2:09 PM:
-
[~mduerig], yes, that's an oversight... i thought i had moved it. will fix
right away (Committed revision 1797929)
was (Author: anchela):
[~mduerig], yes, that's an oversight... i thought i had moved it. will fix
right away.
> Move generic part of PropertyStateValue and PropertyValues to oak-store-spi
> ---
>
> Key: OAK-6311
> URL: https://issues.apache.org/jira/browse/OAK-6311
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: core, query, store-spi
>Reporter: angela
> Fix For: 1.8, 1.7.2
>
> Attachments: OAK-6311-2.patch, OAK-6311.patch, OAK-6311-tests.patch
>
>
> in the light of the modularisation effort i found that
> {{o.a.j.oak.spi.query.PropertyStateValue}} and
> {{o.a.j.oak.spi.query.PropertyValues}} are intended for generic usage and
> aren't any specific to the query spi.
> since it used in other parts of oak as utility to create {{PropertyValue}}
> instances, i would like to suggest that we move the generic parts of these 2
> classes to {{o.a.j.oak.plugins.memory}} thus to the _oak-store-spi_ module.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (OAK-6316) Build Jackrabbit Oak #394 failed
Hudson created OAK-6316: --- Summary: Build Jackrabbit Oak #394 failed Key: OAK-6316 URL: https://issues.apache.org/jira/browse/OAK-6316 Project: Jackrabbit Oak Issue Type: Bug Components: continuous integration Reporter: Hudson Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/ The build Jackrabbit Oak #394 has failed. First failed run: [Jackrabbit Oak #394|https://builds.apache.org/job/Jackrabbit%20Oak/394/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/394/console] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (OAK-6315) Create CheckpointMBean implementation for the composite node store
Tomek Rękawek created OAK-6315: -- Summary: Create CheckpointMBean implementation for the composite node store Key: OAK-6315 URL: https://issues.apache.org/jira/browse/OAK-6315 Project: Jackrabbit Oak Issue Type: Task Components: composite Reporter: Tomek Rękawek Assignee: Tomek Rękawek Fix For: 1.8 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (OAK-6314) ActiveDeletedBlobCollectorTest.multiThreadedCommits is failing intermittently for a few users
[
https://issues.apache.org/jira/browse/OAK-6314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16040812#comment-16040812
]
Vikas Saurabh edited comment on OAK-6314 at 6/7/17 12:54 PM:
-
[~tmueller], as you mentioned on 1.7.1 vote thread - you could reproduce fairly
consistently. Could you enable DEBUG log for
{{org.apache.jackrabbit.oak.plugins.index.lucene.directory.ActiveDeletedBlobCollectorFactory.ActiveDeletedBlobCollectorImpl}}
when it fails and attach it here. I'm hoping that the specific interleaving
has some clues (and that I've enough logs).
In the meantime, I'm ignoring the test in
[r1797918|https://svn.apache.org/r1797918].
was (Author: catholicon):
[~tmueller], as you mentioned on 1.7.1 vote thread - you could reproduce fairly
consistently. Could you enable DEBUG log for
{{org.apache.jackrabbit.oak.plugins.index.lucene.directory.ActiveDeletedBlobCollectorFactory.ActiveDeletedBlobCollectorImpl}}
when it fails and attach it here. I'm hoping that the specific interleaving
has some clues (and that I've enough logs).
In the meantime, I'm ignoring the test.
> ActiveDeletedBlobCollectorTest.multiThreadedCommits is failing intermittently
> for a few users
> -
>
> Key: OAK-6314
> URL: https://issues.apache.org/jira/browse/OAK-6314
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.7.1
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
> Fix For: 1.8, 1.7.2
>
>
> As mentioned in oak-1.7.1 vote thread \[0],
> ActiveDeletedBlobCollectorTest.multiThreadedCommits is failing intermittently.
> /cc [~tmueller], [~alex.parvulescu],
> \[0]:
> https://lists.apache.org/thread.html/5b0493c8ccf0dff486a14564d88ccf2baedc84922507ad7a39b07122@%3Coak-dev.jackrabbit.apache.org%3E
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6314) ActiveDeletedBlobCollectorTest.multiThreadedCommits is failing intermittently for a few users
[
https://issues.apache.org/jira/browse/OAK-6314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16040812#comment-16040812
]
Vikas Saurabh commented on OAK-6314:
[~tmueller], as you mentioned on 1.7.1 vote thread - you could reproduce fairly
consistently. Could you enable DEBUG log for
{{org.apache.jackrabbit.oak.plugins.index.lucene.directory.ActiveDeletedBlobCollectorFactory.ActiveDeletedBlobCollectorImpl}}
when it fails and attach it here. I'm hoping that the specific interleaving
has some clues (and that I've enough logs).
In the meantime, I'm ignoring the test.
> ActiveDeletedBlobCollectorTest.multiThreadedCommits is failing intermittently
> for a few users
> -
>
> Key: OAK-6314
> URL: https://issues.apache.org/jira/browse/OAK-6314
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.7.1
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
> Fix For: 1.8, 1.7.2
>
>
> As mentioned in oak-1.7.1 vote thread \[0],
> ActiveDeletedBlobCollectorTest.multiThreadedCommits is failing intermittently.
> /cc [~tmueller], [~alex.parvulescu],
> \[0]:
> https://lists.apache.org/thread.html/5b0493c8ccf0dff486a14564d88ccf2baedc84922507ad7a39b07122@%3Coak-dev.jackrabbit.apache.org%3E
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-2808) Active deletion of 'deleted' Lucene index files from DataStore without relying on full scale Blob GC
[ https://issues.apache.org/jira/browse/OAK-2808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16040797#comment-16040797 ] Vikas Saurabh commented on OAK-2808: Opened OAK-6314 for error reported by [~tmueller] above. > Active deletion of 'deleted' Lucene index files from DataStore without > relying on full scale Blob GC > > > Key: OAK-2808 > URL: https://issues.apache.org/jira/browse/OAK-2808 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Chetan Mehrotra >Assignee: Vikas Saurabh > Labels: datastore, performance > Fix For: 1.8, 1.7.1 > > Attachments: copyonread-stats.png, OAK-2808-1.patch > > > With storing of Lucene index files within DataStore our usage pattern > of DataStore has changed between JR2 and Oak. > With JR2 the writes were mostly application based i.e. if application > stores a pdf/image file then that would be stored in DataStore. JR2 by > default would not write stuff to DataStore. Further in deployment > where large number of binary content is present then systems tend to > share the DataStore to avoid duplication of storage. In such cases > running Blob GC is a non trivial task as it involves a manual step and > coordination across multiple deployments. Due to this systems tend to > delay frequency of GC > Now with Oak apart from application the Oak system itself *actively* > uses the DataStore to store the index files for Lucene and there the > churn might be much higher i.e. frequency of creation and deletion of > index file is lot higher. This would accelerate the rate of garbage > generation and thus put lot more pressure on the DataStore storage > requirements. > Discussion thread http://markmail.org/thread/iybd3eq2bh372zrl -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (OAK-6314) ActiveDeletedBlobCollectorTest.multiThreadedCommits is failing intermittently for a few users
[ https://issues.apache.org/jira/browse/OAK-6314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Saurabh reassigned OAK-6314: -- Assignee: Vikas Saurabh > ActiveDeletedBlobCollectorTest.multiThreadedCommits is failing intermittently > for a few users > - > > Key: OAK-6314 > URL: https://issues.apache.org/jira/browse/OAK-6314 > Project: Jackrabbit Oak > Issue Type: Bug > Components: lucene >Affects Versions: 1.7.1 >Reporter: Vikas Saurabh >Assignee: Vikas Saurabh >Priority: Minor > Fix For: 1.8, 1.7.2 > > > As mentioned in oak-1.7.1 vote thread \[0], > ActiveDeletedBlobCollectorTest.multiThreadedCommits is failing intermittently. > /cc [~tmueller], [~alex.parvulescu], > \[0]: > https://lists.apache.org/thread.html/5b0493c8ccf0dff486a14564d88ccf2baedc84922507ad7a39b07122@%3Coak-dev.jackrabbit.apache.org%3E -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (OAK-6314) ActiveDeletedBlobCollectorTest.multiThreadedCommits is failing intermittently for a few users
Vikas Saurabh created OAK-6314: -- Summary: ActiveDeletedBlobCollectorTest.multiThreadedCommits is failing intermittently for a few users Key: OAK-6314 URL: https://issues.apache.org/jira/browse/OAK-6314 Project: Jackrabbit Oak Issue Type: Bug Components: lucene Affects Versions: 1.7.1 Reporter: Vikas Saurabh Priority: Minor Fix For: 1.8, 1.7.2 As mentioned in oak-1.7.1 vote thread \[0], ActiveDeletedBlobCollectorTest.multiThreadedCommits is failing intermittently. /cc [~tmueller], [~alex.parvulescu], \[0]: https://lists.apache.org/thread.html/5b0493c8ccf0dff486a14564d88ccf2baedc84922507ad7a39b07122@%3Coak-dev.jackrabbit.apache.org%3E -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-6311) Move generic part of PropertyStateValue and PropertyValues to oak-store-spi
[
https://issues.apache.org/jira/browse/OAK-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16040763#comment-16040763
]
Thomas Mueller commented on OAK-6311:
-
[~anchela] thanks a lot for fixing this!
> i don't see the name was always null there... but
What I mean is, your patch was: {{if (name == null) throw new
IllegalArgumentException("Not a valid JCR name: " + name)}}, so that an
exception is only thrown if name is null, and therefore the message would be
alway "Not a valid JCR name: " + null.
> Move generic part of PropertyStateValue and PropertyValues to oak-store-spi
> ---
>
> Key: OAK-6311
> URL: https://issues.apache.org/jira/browse/OAK-6311
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: core, query, store-spi
>Reporter: angela
> Fix For: 1.8, 1.7.2
>
> Attachments: OAK-6311-2.patch, OAK-6311.patch, OAK-6311-tests.patch
>
>
> in the light of the modularisation effort i found that
> {{o.a.j.oak.spi.query.PropertyStateValue}} and
> {{o.a.j.oak.spi.query.PropertyValues}} are intended for generic usage and
> aren't any specific to the query spi.
> since it used in other parts of oak as utility to create {{PropertyValue}}
> instances, i would like to suggest that we move the generic parts of these 2
> classes to {{o.a.j.oak.plugins.memory}} thus to the _oak-store-spi_ module.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-5352) Enable RevisionGC task for non primary SegmentNodeStore
[ https://issues.apache.org/jira/browse/OAK-5352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16040759#comment-16040759 ] Tomek Rękawek commented on OAK-5352: Patch attached. It simply removes the if(isPrimary) condition before registering SegmentRevisionGC and RevisionGCMBean. > Enable RevisionGC task for non primary SegmentNodeStore > --- > > Key: OAK-5352 > URL: https://issues.apache.org/jira/browse/OAK-5352 > Project: Jackrabbit Oak > Issue Type: Task > Components: segment-tar >Reporter: Chetan Mehrotra >Assignee: Tomek Rękawek > Labels: gc, monitoring, operations, secondary-nodestore > Fix For: 1.8 > > Attachments: OAK-5352.patch > > > As explained in OAK-5351 the RevisionGCMBean is not being registered for > secondary SegmentNodeStore. This task is meant to enable that once OAK-5309 > is resolved -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (OAK-5352) Enable RevisionGC task for non primary SegmentNodeStore
[ https://issues.apache.org/jira/browse/OAK-5352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomek Rękawek reassigned OAK-5352: -- Assignee: Tomek Rękawek > Enable RevisionGC task for non primary SegmentNodeStore > --- > > Key: OAK-5352 > URL: https://issues.apache.org/jira/browse/OAK-5352 > Project: Jackrabbit Oak > Issue Type: Task > Components: segment-tar >Reporter: Chetan Mehrotra >Assignee: Tomek Rękawek > Labels: gc, monitoring, operations, secondary-nodestore > Fix For: 1.8 > > Attachments: OAK-5352.patch > > > As explained in OAK-5351 the RevisionGCMBean is not being registered for > secondary SegmentNodeStore. This task is meant to enable that once OAK-5309 > is resolved -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-5352) Enable RevisionGC task for non primary SegmentNodeStore
[ https://issues.apache.org/jira/browse/OAK-5352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomek Rękawek updated OAK-5352: --- Attachment: OAK-5352.patch > Enable RevisionGC task for non primary SegmentNodeStore > --- > > Key: OAK-5352 > URL: https://issues.apache.org/jira/browse/OAK-5352 > Project: Jackrabbit Oak > Issue Type: Task > Components: segment-tar >Reporter: Chetan Mehrotra > Labels: gc, monitoring, operations, secondary-nodestore > Fix For: 1.8 > > Attachments: OAK-5352.patch > > > As explained in OAK-5351 the RevisionGCMBean is not being registered for > secondary SegmentNodeStore. This task is meant to enable that once OAK-5309 > is resolved -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-5309) Supporting roles in RepositoryManager execution of maintenance tasks
[
https://issues.apache.org/jira/browse/OAK-5309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16040722#comment-16040722
]
Tomek Rękawek commented on OAK-5309:
Patch attached. It requires OAK-6313 to be merged first. [~chetanm], [~mduerig]
- any thoughts?
> Supporting roles in RepositoryManager execution of maintenance tasks
>
>
> Key: OAK-5309
> URL: https://issues.apache.org/jira/browse/OAK-5309
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Chetan Mehrotra
>Assignee: Tomek Rękawek
> Fix For: 1.8
>
> Attachments: OAK-5309.patch
>
>
> With recent support for maintenance task MBeans exposed for secondary stores
> via OAK-4978 its now possible to have multiple implementations of
> RevisionGCMBean present in same setup.
> However o.a.j.o.management.RepositoryManager implementation only supports
> single implementation by design. This needs to be updated to support
> # Looking up RevisionGCMBean which does not have {{role}} OSGi property
> defined
> # Expose a management op like startRevisionGCForRole
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-5309) Supporting roles in RepositoryManager execution of maintenance tasks
[
https://issues.apache.org/jira/browse/OAK-5309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomek Rękawek updated OAK-5309:
---
Attachment: OAK-5309.patch
> Supporting roles in RepositoryManager execution of maintenance tasks
>
>
> Key: OAK-5309
> URL: https://issues.apache.org/jira/browse/OAK-5309
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Chetan Mehrotra
>Assignee: Tomek Rękawek
> Fix For: 1.8
>
> Attachments: OAK-5309.patch
>
>
> With recent support for maintenance task MBeans exposed for secondary stores
> via OAK-4978 its now possible to have multiple implementations of
> RevisionGCMBean present in same setup.
> However o.a.j.o.management.RepositoryManager implementation only supports
> single implementation by design. This needs to be updated to support
> # Looking up RevisionGCMBean which does not have {{role}} OSGi property
> defined
> # Expose a management op like startRevisionGCForRole
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6313) Support properties filtering in the Whiteboard track method
[
https://issues.apache.org/jira/browse/OAK-6313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16040719#comment-16040719
]
Tomek Rękawek commented on OAK-6313:
Patch attached. [~chetanm], [~mduerig] - thoughts?
> Support properties filtering in the Whiteboard track method
> ---
>
> Key: OAK-6313
> URL: https://issues.apache.org/jira/browse/OAK-6313
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core-spi
>Reporter: Tomek Rękawek
> Fix For: 1.8
>
> Attachments: OAK-6313.patch
>
>
> Since the Whiteboard#register() method supports passing properties, we should
> be able to track only services which are configured with specific values. In
> order to do this, let's add a new method to the Whiteboard interface:
> {noformat}
> Tracker track(Class type, Map filterProperties);
> {noformat}
> If a null value is passed for a given key map, only services without this
> property set will be returned. If a service is registered with a non-String
> property, the toString() method will be invoked first.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-6313) Support properties filtering in the Whiteboard track method
[
https://issues.apache.org/jira/browse/OAK-6313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomek Rękawek updated OAK-6313:
---
Attachment: OAK-6313.patch
> Support properties filtering in the Whiteboard track method
> ---
>
> Key: OAK-6313
> URL: https://issues.apache.org/jira/browse/OAK-6313
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core-spi
>Reporter: Tomek Rękawek
> Fix For: 1.8
>
> Attachments: OAK-6313.patch
>
>
> Since the Whiteboard#register() method supports passing properties, we should
> be able to track only services which are configured with specific values. In
> order to do this, let's add a new method to the Whiteboard interface:
> {noformat}
> Tracker track(Class type, Map filterProperties);
> {noformat}
> If a null value is passed for a given key map, only services without this
> property set will be returned. If a service is registered with a non-String
> property, the toString() method will be invoked first.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-6313) Support properties filtering in the Whiteboard track method
[
https://issues.apache.org/jira/browse/OAK-6313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomek Rękawek updated OAK-6313:
---
Summary: Support properties filtering in the Whiteboard track method (was:
Support proeprties filtering in the Whiteboard track method)
> Support properties filtering in the Whiteboard track method
> ---
>
> Key: OAK-6313
> URL: https://issues.apache.org/jira/browse/OAK-6313
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core-spi
>Reporter: Tomek Rękawek
> Fix For: 1.8
>
>
> Since the Whiteboard#register() method supports passing properties, we should
> be able to track only services which are configured with specific values. In
> order to do this, let's add a new method to the Whiteboard interface:
> {noformat}
> Tracker track(Class type, Map filterProperties);
> {noformat}
> If a null value is passed for a given key map, only services without this
> property set will be returned. If a service is registered with a non-String
> property, the toString() method will be invoked first.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (OAK-6313) Support proeprties filtering in the Whiteboard track method
Tomek Rękawek created OAK-6313:
--
Summary: Support proeprties filtering in the Whiteboard track
method
Key: OAK-6313
URL: https://issues.apache.org/jira/browse/OAK-6313
Project: Jackrabbit Oak
Issue Type: Improvement
Components: core-spi
Reporter: Tomek Rękawek
Fix For: 1.8
Since the Whiteboard#register() method supports passing properties, we should
be able to track only services which are configured with specific values. In
order to do this, let's add a new method to the Whiteboard interface:
{noformat}
Tracker track(Class type, Map filterProperties);
{noformat}
If a null value is passed for a given key map, only services without this
property set will be returned. If a service is registered with a non-String
property, the toString() method will be invoked first.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-5309) Supporting roles in RepositoryManager execution of maintenance tasks
[
https://issues.apache.org/jira/browse/OAK-5309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16040703#comment-16040703
]
Tomek Rękawek commented on OAK-5309:
Created OAK-6313 for the whiteboard changes.
> Supporting roles in RepositoryManager execution of maintenance tasks
>
>
> Key: OAK-5309
> URL: https://issues.apache.org/jira/browse/OAK-5309
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Chetan Mehrotra
>Assignee: Tomek Rękawek
> Fix For: 1.8
>
>
> With recent support for maintenance task MBeans exposed for secondary stores
> via OAK-4978 its now possible to have multiple implementations of
> RevisionGCMBean present in same setup.
> However o.a.j.o.management.RepositoryManager implementation only supports
> single implementation by design. This needs to be updated to support
> # Looking up RevisionGCMBean which does not have {{role}} OSGi property
> defined
> # Expose a management op like startRevisionGCForRole
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6311) Move generic part of PropertyStateValue and PropertyValues to oak-store-spi
[
https://issues.apache.org/jira/browse/OAK-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16040681#comment-16040681
]
angela commented on OAK-6311:
-
[~mduerig], yes, that's an oversight... i thought i had moved it. will fix
right away.
> Move generic part of PropertyStateValue and PropertyValues to oak-store-spi
> ---
>
> Key: OAK-6311
> URL: https://issues.apache.org/jira/browse/OAK-6311
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: core, query, store-spi
>Reporter: angela
> Fix For: 1.8, 1.7.2
>
> Attachments: OAK-6311-2.patch, OAK-6311.patch, OAK-6311-tests.patch
>
>
> in the light of the modularisation effort i found that
> {{o.a.j.oak.spi.query.PropertyStateValue}} and
> {{o.a.j.oak.spi.query.PropertyValues}} are intended for generic usage and
> aren't any specific to the query spi.
> since it used in other parts of oak as utility to create {{PropertyValue}}
> instances, i would like to suggest that we move the generic parts of these 2
> classes to {{o.a.j.oak.plugins.memory}} thus to the _oak-store-spi_ module.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-2808) Active deletion of 'deleted' Lucene index files from DataStore without relying on full scale Blob GC
[
https://issues.apache.org/jira/browse/OAK-2808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16040674#comment-16040674
]
Thomas Mueller commented on OAK-2808:
-
I had a test failure today with the 1.7.1 release candidate, and can reproduce
it locally (most of the time) on trunk:
{noformat}
[ERROR] ActiveDeletedBlobCollectorTest.multiThreadedCommits:230
Expected: iterable
over ["Thread0Blob0-1", "Thread0Blob0-2", ..., "Thread3Blob499-1",
"Thread3Blob499-2"] in any order
but: No item matches:
"Thread2Blob497-1", "Thread2Blob497-2", "Thread2Blob498-1", "Thread2Blob498-2",
"Thread2Blob499-1", "Thread2Blob499-2"
in ["Thread1Blob0-1", "Thread1Blob0-2", ..., "Thread2Blob495-2",
"Thread2Blob496-1", "Thread2Blob496-2"]
{noformat}
If I change the test slightly, then the error message is much shorter:
{noformat}
HashSet list = new HashSet<>(deletedChunks);
list.removeAll(blobStore.deletedChunkIds);
assertTrue(list.toString(), list.isEmpty());
assertThat(blobStore.deletedChunkIds,
containsInAnyOrder(deletedChunks.toArray()));
java.lang.AssertionError: [Thread0Blob499-1, Thread0Blob499-2,
Thread0Blob498-2, Thread0Blob498-1]
java.lang.AssertionError: [Thread3Blob498-2, Thread3Blob498-1,
Thread3Blob499-1, Thread3Blob499-2, Thread3Blob497-1, Thread3Blob497-2]
java.lang.AssertionError: [Thread3Blob498-2, Thread3Blob498-1,
Thread3Blob499-1, Thread3Blob499-2, Thread3Blob496-1, Thread3Blob496-2,
Thread3Blob497-1, Thread3Blob497-2]
{noformat}
> Active deletion of 'deleted' Lucene index files from DataStore without
> relying on full scale Blob GC
>
>
> Key: OAK-2808
> URL: https://issues.apache.org/jira/browse/OAK-2808
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Vikas Saurabh
> Labels: datastore, performance
> Fix For: 1.8, 1.7.1
>
> Attachments: copyonread-stats.png, OAK-2808-1.patch
>
>
> With storing of Lucene index files within DataStore our usage pattern
> of DataStore has changed between JR2 and Oak.
> With JR2 the writes were mostly application based i.e. if application
> stores a pdf/image file then that would be stored in DataStore. JR2 by
> default would not write stuff to DataStore. Further in deployment
> where large number of binary content is present then systems tend to
> share the DataStore to avoid duplication of storage. In such cases
> running Blob GC is a non trivial task as it involves a manual step and
> coordination across multiple deployments. Due to this systems tend to
> delay frequency of GC
> Now with Oak apart from application the Oak system itself *actively*
> uses the DataStore to store the index files for Lucene and there the
> churn might be much higher i.e. frequency of creation and deletion of
> index file is lot higher. This would accelerate the rate of garbage
> generation and thus put lot more pressure on the DataStore storage
> requirements.
> Discussion thread http://markmail.org/thread/iybd3eq2bh372zrl
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6311) Move generic part of PropertyStateValue and PropertyValues to oak-store-spi
[
https://issues.apache.org/jira/browse/OAK-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16040672#comment-16040672
]
Michael Dürig commented on OAK-6311:
Just noted one more thing: shouldn't {{PropertyValues.canConvert()}} also go to
{{ValueConverter}}?
> Move generic part of PropertyStateValue and PropertyValues to oak-store-spi
> ---
>
> Key: OAK-6311
> URL: https://issues.apache.org/jira/browse/OAK-6311
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: core, query, store-spi
>Reporter: angela
> Fix For: 1.8, 1.7.2
>
> Attachments: OAK-6311-2.patch, OAK-6311.patch, OAK-6311-tests.patch
>
>
> in the light of the modularisation effort i found that
> {{o.a.j.oak.spi.query.PropertyStateValue}} and
> {{o.a.j.oak.spi.query.PropertyValues}} are intended for generic usage and
> aren't any specific to the query spi.
> since it used in other parts of oak as utility to create {{PropertyValue}}
> instances, i would like to suggest that we move the generic parts of these 2
> classes to {{o.a.j.oak.plugins.memory}} thus to the _oak-store-spi_ module.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (OAK-6311) Move generic part of PropertyStateValue and PropertyValues to oak-store-spi
[
https://issues.apache.org/jira/browse/OAK-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved OAK-6311.
-
Resolution: Fixed
Fix Version/s: 1.7.2
1.8
thanks a lot for the reviews!
Committed revision 1797907.
> Move generic part of PropertyStateValue and PropertyValues to oak-store-spi
> ---
>
> Key: OAK-6311
> URL: https://issues.apache.org/jira/browse/OAK-6311
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: core, query, store-spi
>Reporter: angela
> Fix For: 1.8, 1.7.2
>
> Attachments: OAK-6311-2.patch, OAK-6311.patch, OAK-6311-tests.patch
>
>
> in the light of the modularisation effort i found that
> {{o.a.j.oak.spi.query.PropertyStateValue}} and
> {{o.a.j.oak.spi.query.PropertyValues}} are intended for generic usage and
> aren't any specific to the query spi.
> since it used in other parts of oak as utility to create {{PropertyValue}}
> instances, i would like to suggest that we move the generic parts of these 2
> classes to {{o.a.j.oak.plugins.memory}} thus to the _oak-store-spi_ module.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (OAK-2968) Reduce commits memory footprint of ModifiedNodeState
[
https://issues.apache.org/jira/browse/OAK-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig resolved OAK-2968.
Resolution: Not A Problem
This should not be a problem when using the {{NodeBuilder}} API as the
underlying store should write ahead changes to the store once there are many.
> Reduce commits memory footprint of ModifiedNodeState
>
>
> Key: OAK-2968
> URL: https://issues.apache.org/jira/browse/OAK-2968
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.2.2
>Reporter: Timothee Maret
> Labels: perfomance
>
> As described in [0] large commits consume a fair amount of memory. With very
> large commits, this become problematic as commits may eat up 100GB or more
> and thus causing OOME and aborting the commit.
> The current representation of commits in memory uses a tree which each node
> contains HashMaps for the changed properties as well as sub-nodes.
> In cases where the tree is deep but not sparse, most of the children HashMaps
> will contain 1 element yet they are created with the default capacity (16)
> thus wasting space.
> This issue covers a simple way to reduce the memory consumption in this case
> by simply creating HashMaps of the required capacity (where applicable) or of
> minimal capacity (1) where unknown.
> [0] http://permalink.gmane.org/gmane.comp.apache.jackrabbit.oak.devel/8196
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (OAK-5583) Build failure: unable to create new native thread
[ https://issues.apache.org/jira/browse/OAK-5583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig resolved OAK-5583. Resolution: Cannot Reproduce > Build failure: unable to create new native thread > - > > Key: OAK-5583 > URL: https://issues.apache.org/jira/browse/OAK-5583 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson > Labels: CI, ubuntu > Attachments: consoleText.txt > > > Jenkins CI failure: > https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/ > The build Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.8 > (latest),nsfixtures=SEGMENT_MK,profile=integrationTesting #1404 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.8 (latest),nsfixtures=SEGMENT_MK,profile=integrationTesting > #1404|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=SEGMENT_MK,profile=integrationTesting/1404/] > [console > log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=SEGMENT_MK,profile=integrationTesting/1404/console] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (OAK-5731) Build failure: Backing channel '......' is disconnected/already closed
[ https://issues.apache.org/jira/browse/OAK-5731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig resolved OAK-5731. Resolution: Cannot Reproduce > Build failure: Backing channel '..' is disconnected/already closed > -- > > Key: OAK-5731 > URL: https://issues.apache.org/jira/browse/OAK-5731 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Affects Versions: 1.0.37, 1.4.13, 1.6.0, 1.7.0 >Reporter: Hudson > Labels: CI, ubuntu, windows > > Jenkins CI failure: > https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/ > The build Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.7 > (latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting #1437 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.7 (latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting > #1437|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting/1437/] > [console > log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting/1437/console] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (OAK-5856) Build aborted for no apparent reason
[ https://issues.apache.org/jira/browse/OAK-5856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig resolved OAK-5856. Resolution: Cannot Reproduce > Build aborted for no apparent reason > > > Key: OAK-5856 > URL: https://issues.apache.org/jira/browse/OAK-5856 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson > Labels: CI, ubuntu > Attachments: logs.zip > > > Jenkins CI failure: > https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/ > The build Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.8 > (latest),nsfixtures=SEGMENT_TAR,profile=unittesting #1465 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.8 (latest),nsfixtures=SEGMENT_TAR,profile=unittesting > #1465|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=SEGMENT_TAR,profile=unittesting/1465/] > [console > log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=SEGMENT_TAR,profile=unittesting/1465/console] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (OAK-5872) Hudson.remoting.ChannelClosedException: channel is already closed
[ https://issues.apache.org/jira/browse/OAK-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig resolved OAK-5872. Resolution: Cannot Reproduce > Hudson.remoting.ChannelClosedException: channel is already closed > - > > Key: OAK-5872 > URL: https://issues.apache.org/jira/browse/OAK-5872 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson > Labels: CI, ubuntu > > Jenkins CI failure: > https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/ > The build Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.8 > (latest),nsfixtures=SEGMENT_TAR,profile=unittesting #1469 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.8 (latest),nsfixtures=SEGMENT_TAR,profile=unittesting > #1469|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=SEGMENT_TAR,profile=unittesting/1469/] > [console > log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=SEGMENT_TAR,profile=unittesting/1469/console] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (OAK-5564) Build failure: Cannot allocate memory
[ https://issues.apache.org/jira/browse/OAK-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig resolved OAK-5564. Resolution: Cannot Reproduce > Build failure: Cannot allocate memory > - > > Key: OAK-5564 > URL: https://issues.apache.org/jira/browse/OAK-5564 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Affects Versions: 1.0.36, 1.2.23, 1.4.12, 1.6.0 >Reporter: Hudson > Labels: CI > > Jenkins CI failure: > https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/ > The build Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.7 > (latest),nsfixtures=SEGMENT_MK,profile=integrationTesting #1395 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.7 (latest),nsfixtures=SEGMENT_MK,profile=integrationTesting > #1395|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=SEGMENT_MK,profile=integrationTesting/1395/] > [console > log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=SEGMENT_MK,profile=integrationTesting/1395/console] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-6311) Move generic part of PropertyStateValue and PropertyValues to oak-store-spi
[
https://issues.apache.org/jira/browse/OAK-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16040555#comment-16040555
]
angela commented on OAK-6311:
-
[~tmueller], i don't see the {{name}} was always null there... but the
suggested variant looks better to me and is closer to the original code.
adjusted accordingly.
> Move generic part of PropertyStateValue and PropertyValues to oak-store-spi
> ---
>
> Key: OAK-6311
> URL: https://issues.apache.org/jira/browse/OAK-6311
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: core, query, store-spi
>Reporter: angela
> Attachments: OAK-6311-2.patch, OAK-6311.patch, OAK-6311-tests.patch
>
>
> in the light of the modularisation effort i found that
> {{o.a.j.oak.spi.query.PropertyStateValue}} and
> {{o.a.j.oak.spi.query.PropertyValues}} are intended for generic usage and
> aren't any specific to the query spi.
> since it used in other parts of oak as utility to create {{PropertyValue}}
> instances, i would like to suggest that we move the generic parts of these 2
> classes to {{o.a.j.oak.plugins.memory}} thus to the _oak-store-spi_ module.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-6312) Unify NodeStore/DataStore configurations
[ https://issues.apache.org/jira/browse/OAK-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-6312: --- Component/s: (was: mk) segment-tar rdbmk documentmk > Unify NodeStore/DataStore configurations > > > Key: OAK-6312 > URL: https://issues.apache.org/jira/browse/OAK-6312 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: blob, blob-plugins, composite, documentmk, rdbmk, > segment-tar >Reporter: Arek Kita > Fix For: 1.8 > > > I've noticed recently that with many different NodeStore > implementation (Segment, Document, Composite) but also DataStore > implementation (File, S3, Azure) and some composite ones like > (Hierarchical, Federated) it > becomes more and more difficult to set up everything correctly and be > able to know the current persistence state of repository (especially > with pretty aged repos). The factory code/required options are more complex > not only from user perspective but also from maintenance point. > We should have the same means of *describing* layouts of Oak repository no > matter if it is simple or more layered/composite instance. > Some work has already been done in scope of OAK-6210 so I guess we have good > foundations to continue working in that direction. > /cc [~mattvryan], [~chetanm] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-6312) Unify NodeStore/DataStore configurations
[ https://issues.apache.org/jira/browse/OAK-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-6312: --- Fix Version/s: 1.8 > Unify NodeStore/DataStore configurations > > > Key: OAK-6312 > URL: https://issues.apache.org/jira/browse/OAK-6312 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: blob, blob-plugins, composite, documentmk, rdbmk, > segment-tar >Reporter: Arek Kita > Fix For: 1.8 > > > I've noticed recently that with many different NodeStore > implementation (Segment, Document, Composite) but also DataStore > implementation (File, S3, Azure) and some composite ones like > (Hierarchical, Federated) it > becomes more and more difficult to set up everything correctly and be > able to know the current persistence state of repository (especially > with pretty aged repos). The factory code/required options are more complex > not only from user perspective but also from maintenance point. > We should have the same means of *describing* layouts of Oak repository no > matter if it is simple or more layered/composite instance. > Some work has already been done in scope of OAK-6210 so I guess we have good > foundations to continue working in that direction. > /cc [~mattvryan], [~chetanm] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-6309) Not always convert XPath "primaryType in a, b" to union
[
https://issues.apache.org/jira/browse/OAK-6309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-6309:
Priority: Critical (was: Major)
> Not always convert XPath "primaryType in a, b" to union
> ---
>
> Key: OAK-6309
> URL: https://issues.apache.org/jira/browse/OAK-6309
> Project: Jackrabbit Oak
> Issue Type: Improvement
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Critical
> Fix For: 1.8
>
>
> Currently, queries with multiple primary types are always converted to a
> "union", but this is not alway the best solution. The main problem is that
> results are not sorted by score as expected. Example:
> {noformat}
> /jcr:root/content//element(*, nt:hierarchyNode)[jcr:contains(., 'abc)
> and (@jcr:primaryType = 'acme:Page' or @jcr:primaryType = 'acme:Asset')]
> {noformat}
> This is currently converted to a union, even if the same index is used for
> buth subqueries (assuming there is an index on nt:hierarchyNode).
> A workaround is to use:
> {noformat}
> /jcr:root/content//element(*, nt:hierarchyNode)[jcr:contains(., 'abc)
> and (./@jcr:primaryType = 'acme:Page' or ./@jcr:primaryType = 'acme:Asset')]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6295) Move constants from oak.query.QueryImpl to oak.spi.query.QueryConstants
[
https://issues.apache.org/jira/browse/OAK-6295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16040508#comment-16040508
]
Tommaso Teofili commented on OAK-6295:
--
late +1, thanks Angela!
> Move constants from oak.query.QueryImpl to oak.spi.query.QueryConstants
> ---
>
> Key: OAK-6295
> URL: https://issues.apache.org/jira/browse/OAK-6295
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, query
>Reporter: angela
> Fix For: 1.8, 1.7.2
>
> Attachments: OAK-6295.patch
>
>
> in the light of the modularisation effort i had a look at the query code and
> noticed that the constants defined on {{QueryImpl}} are needed outside of the
> scope of the query implementation.
> IMO that indicates that those constants are of broader use and might better
> be located at {{oak.spi.query.QueryConstants}}. moving would in fact remove
> all imports of {{QueryImpl}} in the _oak-lucene_ module.
> [~tmueller], [~teofili], it will attach a proposed patch for this improvement
> and would appreciate if you could review if you are ok with that change.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6312) Unify NodeStore/DataStore configurations
[
https://issues.apache.org/jira/browse/OAK-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16040504#comment-16040504
]
Arek Kita commented on OAK-6312:
I'm by purpose not specifying here any solution like {{nstab}} proposal as some
part of the work has already been done by [~chetanm] and I think we should
follow that path.
> Unify NodeStore/DataStore configurations
>
>
> Key: OAK-6312
> URL: https://issues.apache.org/jira/browse/OAK-6312
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: blob, blob-plugins, composite, mk
>Reporter: Arek Kita
>
> I've noticed recently that with many different NodeStore
> implementation (Segment, Document, Composite) but also DataStore
> implementation (File, S3, Azure) and some composite ones like
> (Hierarchical, Federated) it
> becomes more and more difficult to set up everything correctly and be
> able to know the current persistence state of repository (especially
> with pretty aged repos). The factory code/required options are more complex
> not only from user perspective but also from maintenance point.
> We should have the same means of *describing* layouts of Oak repository no
> matter if it is simple or more layered/composite instance.
> Some work has already been done in scope of OAK-6210 so I guess we have good
> foundations to continue working in that direction.
> /cc [~mattvryan], [~chetanm]
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6312) Unify NodeStore/DataStore configurations
[
https://issues.apache.org/jira/browse/OAK-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16040498#comment-16040498
]
Arek Kita commented on OAK-6312:
>From [~mattvryan] to discuss:
{quote}
>From the perspective of an AbstractDataStoreService subclass, will the
config still be passed into the "createDataStore()" method as a Map after having been read from the nstab-formatted config file? I
assume so but wonder if that is the case.
{quote}
[~chetanm]: Is there any additional documentation we can follow or we should
just be familiar with OAK-6210? Thanks!
> Unify NodeStore/DataStore configurations
>
>
> Key: OAK-6312
> URL: https://issues.apache.org/jira/browse/OAK-6312
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: blob, blob-plugins, composite, mk
>Reporter: Arek Kita
>
> I've noticed recently that with many different NodeStore
> implementation (Segment, Document, Composite) but also DataStore
> implementation (File, S3, Azure) and some composite ones like
> (Hierarchical, Federated) it
> becomes more and more difficult to set up everything correctly and be
> able to know the current persistence state of repository (especially
> with pretty aged repos). The factory code/required options are more complex
> not only from user perspective but also from maintenance point.
> We should have the same means of *describing* layouts of Oak repository no
> matter if it is simple or more layered/composite instance.
> Some work has already been done in scope of OAK-6210 so I guess we have good
> foundations to continue working in that direction.
> /cc [~mattvryan], [~chetanm]
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (OAK-6312) Unify NodeStore/DataStore configurations
Arek Kita created OAK-6312: -- Summary: Unify NodeStore/DataStore configurations Key: OAK-6312 URL: https://issues.apache.org/jira/browse/OAK-6312 Project: Jackrabbit Oak Issue Type: Improvement Components: blob, blob-plugins, composite, mk Reporter: Arek Kita I've noticed recently that with many different NodeStore implementation (Segment, Document, Composite) but also DataStore implementation (File, S3, Azure) and some composite ones like (Hierarchical, Federated) it becomes more and more difficult to set up everything correctly and be able to know the current persistence state of repository (especially with pretty aged repos). The factory code/required options are more complex not only from user perspective but also from maintenance point. We should have the same means of *describing* layouts of Oak repository no matter if it is simple or more layered/composite instance. Some work has already been done in scope of OAK-6210 so I guess we have good foundations to continue working in that direction. /cc [~mattvryan], [~chetanm] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-6311) Move generic part of PropertyStateValue and PropertyValues to oak-store-spi
[
https://issues.apache.org/jira/browse/OAK-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16040448#comment-16040448
]
Michael Dürig commented on OAK-6311:
The new patch LGTM.
> Move generic part of PropertyStateValue and PropertyValues to oak-store-spi
> ---
>
> Key: OAK-6311
> URL: https://issues.apache.org/jira/browse/OAK-6311
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: core, query, store-spi
>Reporter: angela
> Attachments: OAK-6311-2.patch, OAK-6311.patch, OAK-6311-tests.patch
>
>
> in the light of the modularisation effort i found that
> {{o.a.j.oak.spi.query.PropertyStateValue}} and
> {{o.a.j.oak.spi.query.PropertyValues}} are intended for generic usage and
> aren't any specific to the query spi.
> since it used in other parts of oak as utility to create {{PropertyValue}}
> instances, i would like to suggest that we move the generic parts of these 2
> classes to {{o.a.j.oak.plugins.memory}} thus to the _oak-store-spi_ module.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6311) Move generic part of PropertyStateValue and PropertyValues to oak-store-spi
[
https://issues.apache.org/jira/browse/OAK-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16040450#comment-16040450
]
angela commented on OAK-6311:
-
[~tmueller], thanks a lot for the insight. see updated patch (doesn't make
usage of QueryImpl.getOakPath)
> Move generic part of PropertyStateValue and PropertyValues to oak-store-spi
> ---
>
> Key: OAK-6311
> URL: https://issues.apache.org/jira/browse/OAK-6311
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: core, query, store-spi
>Reporter: angela
> Attachments: OAK-6311-2.patch, OAK-6311.patch, OAK-6311-tests.patch
>
>
> in the light of the modularisation effort i found that
> {{o.a.j.oak.spi.query.PropertyStateValue}} and
> {{o.a.j.oak.spi.query.PropertyValues}} are intended for generic usage and
> aren't any specific to the query spi.
> since it used in other parts of oak as utility to create {{PropertyValue}}
> instances, i would like to suggest that we move the generic parts of these 2
> classes to {{o.a.j.oak.plugins.memory}} thus to the _oak-store-spi_ module.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6311) Move generic part of PropertyStateValue and PropertyValues to oak-store-spi
[
https://issues.apache.org/jira/browse/OAK-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16040445#comment-16040445
]
Thomas Mueller commented on OAK-6311:
-
There is a typo in the patch:
{noformat}
-name = PropertyValues.getOakPath(name, query.getNamePathMapper());
-if (PathUtils.isAbsolute(name)) {
+if (query.getNamePathMapper() != null) {
+name = query.getNamePathMapper().getOakPath(name);
+}
+if (name == null) {
+throw new IllegalArgumentException("Not a valid JCR name: " +
name); <=== here
+} else if (PathUtils.isAbsolute(name)) {
{noformat}
name is always null here, so the message would be "Not a valid JCR name: null".
What about (not tested):
{noformat}
if (query.getNamePathMapper() != null) {
String mappedName = query.getNamePathMapper().getOakPath(name);
if (mappedName == null) {
throw new IllegalArgumentException("Not a valid JCR name: " + name);
}
name = mappedName;
}
{noformat}
> Move generic part of PropertyStateValue and PropertyValues to oak-store-spi
> ---
>
> Key: OAK-6311
> URL: https://issues.apache.org/jira/browse/OAK-6311
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: core, query, store-spi
>Reporter: angela
> Attachments: OAK-6311-2.patch, OAK-6311.patch, OAK-6311-tests.patch
>
>
> in the light of the modularisation effort i found that
> {{o.a.j.oak.spi.query.PropertyStateValue}} and
> {{o.a.j.oak.spi.query.PropertyValues}} are intended for generic usage and
> aren't any specific to the query spi.
> since it used in other parts of oak as utility to create {{PropertyValue}}
> instances, i would like to suggest that we move the generic parts of these 2
> classes to {{o.a.j.oak.plugins.memory}} thus to the _oak-store-spi_ module.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6311) Move generic part of PropertyStateValue and PropertyValues to oak-store-spi
[
https://issues.apache.org/jira/browse/OAK-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16040431#comment-16040431
]
Thomas Mueller commented on OAK-6311:
-
Behavior in NodeNameImpl.getName is slightly different than in
QueryImpl.getOakPath, for example QueryImpl.getOakPath does not allow invalid
names (JcrNameParser.validate), while NodeNameImpl does. I think the reason for
that is OAK-108. By the way NodeNameImpl.getName is also used in
NodeLocalNameImpl.
> Move generic part of PropertyStateValue and PropertyValues to oak-store-spi
> ---
>
> Key: OAK-6311
> URL: https://issues.apache.org/jira/browse/OAK-6311
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: core, query, store-spi
>Reporter: angela
> Attachments: OAK-6311-2.patch, OAK-6311.patch, OAK-6311-tests.patch
>
>
> in the light of the modularisation effort i found that
> {{o.a.j.oak.spi.query.PropertyStateValue}} and
> {{o.a.j.oak.spi.query.PropertyValues}} are intended for generic usage and
> aren't any specific to the query spi.
> since it used in other parts of oak as utility to create {{PropertyValue}}
> instances, i would like to suggest that we move the generic parts of these 2
> classes to {{o.a.j.oak.plugins.memory}} thus to the _oak-store-spi_ module.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-6311) Move generic part of PropertyStateValue and PropertyValues to oak-store-spi
[
https://issues.apache.org/jira/browse/OAK-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-6311:
Attachment: OAK-6311-2.patch
updated patch for non-test code incorporating feedback from [~mduerig]
> Move generic part of PropertyStateValue and PropertyValues to oak-store-spi
> ---
>
> Key: OAK-6311
> URL: https://issues.apache.org/jira/browse/OAK-6311
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: core, query, store-spi
>Reporter: angela
> Attachments: OAK-6311-2.patch, OAK-6311.patch, OAK-6311-tests.patch
>
>
> in the light of the modularisation effort i found that
> {{o.a.j.oak.spi.query.PropertyStateValue}} and
> {{o.a.j.oak.spi.query.PropertyValues}} are intended for generic usage and
> aren't any specific to the query spi.
> since it used in other parts of oak as utility to create {{PropertyValue}}
> instances, i would like to suggest that we move the generic parts of these 2
> classes to {{o.a.j.oak.plugins.memory}} thus to the _oak-store-spi_ module.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6311) Move generic part of PropertyStateValue and PropertyValues to oak-store-spi
[
https://issues.apache.org/jira/browse/OAK-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16040408#comment-16040408
]
angela commented on OAK-6311:
-
[~mduerig], fine with me... the usage in {{NodeNameImpl}} is still a bit
strange because there exists {{QueryImpl.getOakPath(String jcrPath)}}, which is
widely used across the query code base _except_ for that single usage in
{{NodeNameImpl}}:
{{PropertyValues.getOakPath(name, query.getNamePathMapper())}}.
So, the {{QueryImpl}} was actually available. [~tmueller], do you remember the
reason for _not_ using {{QueryImpl.getOakPath(String)}} here?
> Move generic part of PropertyStateValue and PropertyValues to oak-store-spi
> ---
>
> Key: OAK-6311
> URL: https://issues.apache.org/jira/browse/OAK-6311
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: core, query, store-spi
>Reporter: angela
> Attachments: OAK-6311.patch, OAK-6311-tests.patch
>
>
> in the light of the modularisation effort i found that
> {{o.a.j.oak.spi.query.PropertyStateValue}} and
> {{o.a.j.oak.spi.query.PropertyValues}} are intended for generic usage and
> aren't any specific to the query spi.
> since it used in other parts of oak as utility to create {{PropertyValue}}
> instances, i would like to suggest that we move the generic parts of these 2
> classes to {{o.a.j.oak.plugins.memory}} thus to the _oak-store-spi_ module.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6311) Move generic part of PropertyStateValue and PropertyValues to oak-store-spi
[
https://issues.apache.org/jira/browse/OAK-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16040307#comment-16040307
]
angela commented on OAK-6311:
-
[~mduerig], good point. i will try to refactor it (there is another getOakPath
utility method somewhere in the query code base which happens to be slightly
different) and at the same time try to replace the query-conversion with
{{Conversions}} from _oak-store-spi_
> Move generic part of PropertyStateValue and PropertyValues to oak-store-spi
> ---
>
> Key: OAK-6311
> URL: https://issues.apache.org/jira/browse/OAK-6311
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: core, query, store-spi
>Reporter: angela
> Attachments: OAK-6311.patch, OAK-6311-tests.patch
>
>
> in the light of the modularisation effort i found that
> {{o.a.j.oak.spi.query.PropertyStateValue}} and
> {{o.a.j.oak.spi.query.PropertyValues}} are intended for generic usage and
> aren't any specific to the query spi.
> since it used in other parts of oak as utility to create {{PropertyValue}}
> instances, i would like to suggest that we move the generic parts of these 2
> classes to {{o.a.j.oak.plugins.memory}} thus to the _oak-store-spi_ module.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
