[jira] [Updated] (OAK-6459) VisibleValidator duplicated in chain for each hierarchy level
[
https://issues.apache.org/jira/browse/OAK-6459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Deparvu updated OAK-6459:
--
Fix Version/s: 1.7.4
> VisibleValidator duplicated in chain for each hierarchy level
> -
>
> Key: OAK-6459
> URL: https://issues.apache.org/jira/browse/OAK-6459
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Alexander Klimetschek
>Assignee: Alex Deparvu
>Priority: Minor
> Fix For: 1.7.4
>
>
> VisibleValidator gets chained multiple times, while each one working on the
> same NodeState will run the exact same check, NodeStateUtils.isHidden(name).
> One execution should be enough.
> Below stacktrace has 9 instances chained. Code for propertyAdded as in the
> stacktrace below in 1.4 is
> [here|https://github.com/apache/jackrabbit-oak/blob/1.4/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/commit/VisibleValidator.java#L82-L83].
>
> Also found a similar stacktrace in OAK-6358 with 12 instances.
> This might be a small optimization to make, especially if there are many
> properties added, and if there is apparently another variable factor in how
> many instances there are.
> According to [~stillalex]:
> This is directly related to the hierarchy level (so if a change is 5 levels
> deep, you'll see 5 validators chained there) and the short fix is to fix
> calls [creating new
> VisibleValidators|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-store-spi/src/main/java/org/apache/jackrabbit/oak/spi/commit/VisibleValidator.java#L44]
> to unwrap if needed, like
> [here|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-store-spi/src/main/java/org/apache/jackrabbit/oak/spi/commit/VisibleEditor.java#L38].
> {noformat}
> Caused by: org.apache.jackrabbit.oak.api.CommitFailedException:
> OakAccess: Access denied
> at
> org.apache.jackrabbit.oak.security.authorization.permission.PermissionValidator.checkPermissions(PermissionValidator.java:242)
> at
> org.apache.jackrabbit.oak.security.authorization.permission.PermissionValidator.propertyAdded(PermissionValidator.java:112)
> at
> org.apache.jackrabbit.oak.spi.commit.VisibleValidator.propertyAdded(VisibleValidator.java:83)
> at
> org.apache.jackrabbit.oak.spi.commit.VisibleValidator.propertyAdded(VisibleValidator.java:83)
> at
> org.apache.jackrabbit.oak.spi.commit.VisibleValidator.propertyAdded(VisibleValidator.java:83)
> at
> org.apache.jackrabbit.oak.spi.commit.VisibleValidator.propertyAdded(VisibleValidator.java:83)
> at
> org.apache.jackrabbit.oak.spi.commit.VisibleValidator.propertyAdded(VisibleValidator.java:83)
> at
> org.apache.jackrabbit.oak.spi.commit.VisibleValidator.propertyAdded(VisibleValidator.java:83)
> at
> org.apache.jackrabbit.oak.spi.commit.VisibleValidator.propertyAdded(VisibleValidator.java:83)
> at
> org.apache.jackrabbit.oak.spi.commit.VisibleValidator.propertyAdded(VisibleValidator.java:83)
> at
> org.apache.jackrabbit.oak.spi.commit.VisibleValidator.propertyAdded(VisibleValidator.java:83)
> at
> org.apache.jackrabbit.oak.spi.commit.CompositeEditor.propertyAdded(CompositeEditor.java:83)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.propertyAdded(EditorDiff.java:82)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:593)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:491)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:148)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:531)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:148)
> at
> org.apache.jackrabbit.oak.plugins.segment.MapRecord.compare(MapRecord.java:483)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:584)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:148)
> at
> org.apache.jackrabbit.oak.plugins.segment.MapRecord.compare(MapRecord.java:483)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:584)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:148)
> at
> org.apache.jackrabbit.oak.plugins.segment.MapRecord.compare(MapRecord.java:483)
> at
> org.apache.jackrabbit.oak.plugins.segment.MapRecord.compareBranch(MapRecord.java:561)
> at
> org.apache.jackrabbit.oak.plugins.segment.MapRecord.compare(MapRecord.java:466)
>
[jira] [Assigned] (OAK-6459) VisibleValidator duplicated in chain for each hierarchy level
[
https://issues.apache.org/jira/browse/OAK-6459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Deparvu reassigned OAK-6459:
-
Assignee: Alex Deparvu
Priority: Minor (was: Major)
Component/s: core
> VisibleValidator duplicated in chain for each hierarchy level
> -
>
> Key: OAK-6459
> URL: https://issues.apache.org/jira/browse/OAK-6459
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Alexander Klimetschek
>Assignee: Alex Deparvu
>Priority: Minor
>
> VisibleValidator gets chained multiple times, while each one working on the
> same NodeState will run the exact same check, NodeStateUtils.isHidden(name).
> One execution should be enough.
> Below stacktrace has 9 instances chained. Code for propertyAdded as in the
> stacktrace below in 1.4 is
> [here|https://github.com/apache/jackrabbit-oak/blob/1.4/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/commit/VisibleValidator.java#L82-L83].
>
> Also found a similar stacktrace in OAK-6358 with 12 instances.
> This might be a small optimization to make, especially if there are many
> properties added, and if there is apparently another variable factor in how
> many instances there are.
> According to [~stillalex]:
> This is directly related to the hierarchy level (so if a change is 5 levels
> deep, you'll see 5 validators chained there) and the short fix is to fix
> calls [creating new
> VisibleValidators|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-store-spi/src/main/java/org/apache/jackrabbit/oak/spi/commit/VisibleValidator.java#L44]
> to unwrap if needed, like
> [here|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-store-spi/src/main/java/org/apache/jackrabbit/oak/spi/commit/VisibleEditor.java#L38].
> {noformat}
> Caused by: org.apache.jackrabbit.oak.api.CommitFailedException:
> OakAccess: Access denied
> at
> org.apache.jackrabbit.oak.security.authorization.permission.PermissionValidator.checkPermissions(PermissionValidator.java:242)
> at
> org.apache.jackrabbit.oak.security.authorization.permission.PermissionValidator.propertyAdded(PermissionValidator.java:112)
> at
> org.apache.jackrabbit.oak.spi.commit.VisibleValidator.propertyAdded(VisibleValidator.java:83)
> at
> org.apache.jackrabbit.oak.spi.commit.VisibleValidator.propertyAdded(VisibleValidator.java:83)
> at
> org.apache.jackrabbit.oak.spi.commit.VisibleValidator.propertyAdded(VisibleValidator.java:83)
> at
> org.apache.jackrabbit.oak.spi.commit.VisibleValidator.propertyAdded(VisibleValidator.java:83)
> at
> org.apache.jackrabbit.oak.spi.commit.VisibleValidator.propertyAdded(VisibleValidator.java:83)
> at
> org.apache.jackrabbit.oak.spi.commit.VisibleValidator.propertyAdded(VisibleValidator.java:83)
> at
> org.apache.jackrabbit.oak.spi.commit.VisibleValidator.propertyAdded(VisibleValidator.java:83)
> at
> org.apache.jackrabbit.oak.spi.commit.VisibleValidator.propertyAdded(VisibleValidator.java:83)
> at
> org.apache.jackrabbit.oak.spi.commit.VisibleValidator.propertyAdded(VisibleValidator.java:83)
> at
> org.apache.jackrabbit.oak.spi.commit.CompositeEditor.propertyAdded(CompositeEditor.java:83)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.propertyAdded(EditorDiff.java:82)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:593)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:491)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:148)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:531)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:148)
> at
> org.apache.jackrabbit.oak.plugins.segment.MapRecord.compare(MapRecord.java:483)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:584)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:148)
> at
> org.apache.jackrabbit.oak.plugins.segment.MapRecord.compare(MapRecord.java:483)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:584)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:148)
> at
> org.apache.jackrabbit.oak.plugins.segment.MapRecord.compare(MapRecord.java:483)
> at
> org.apache.jackrabbit.oak.plugins.segment.MapRecord.compareBranch(MapRecord.java:561)
> at
> org.apache.jackrabbit.oak.plugins.segment
[jira] [Comment Edited] (OAK-6409) Oak-run indexing: improved (user friendly) output
[
https://issues.apache.org/jira/browse/OAK-6409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16091171#comment-16091171
]
Chetan Mehrotra edited comment on OAK-6409 at 7/18/17 6:22 AM:
---
Done following changes with 1802241,1802242
# oak-run index would now copy a logback-index.xml to work dir (default ./temp)
and use that for configuring
# Logback is configured to scan the config periodically and if any change is
done at runtime the changes would be picked up
# By default all info logs would be routed to temp/indexing.log
# In addition logs from following categories would be logged at info level to
stdout with just time and message
{noformat}
org.apache.jackrabbit.oak.index
org.apache.jackrabbit.oak.plugins.index.importer
org.apache.jackrabbit.oak.plugins.index.IndexUpdate
org.apache.jackrabbit.oak.plugins.index.progress
{noformat}
Some run
{noformat}
Apache Jackrabbit Oak
11:28:41 - Logging configured from
/mnt/hdd/data/oak/oak-run-indexing/temp/logback-indexing.xml
11:28:41 - Any change in logging config would be picked up
11:28:41 - Logs would be written to temp/indexing.log
/content/oak:index/enablementResourceName => valid
/oak:index/authorizables => valid
/oak:index/commerceLucene => valid
/oak:index/cqMobileAppLucene => valid
/oak:index/cqPageLucene => valid
/oak:index/cqProjectLucene => valid
/oak:index/cqTagLucene => valid
/oak:index/damAssetLucene => valid
/oak:index/lucene => valid
/oak:index/ntBaseLucene => valid
/oak:index/slingeventJob => valid
/oak:index/socialLucene => valid
/oak:index/versionStoreIndex => valid
/oak:index/workflowDataLucene => valid
Index consistency check report stored at
/mnt/hdd/data/oak/oak-run-indexing/indexing-result/index-consistency-check-report.txt
{noformat}
Sample run for indexing
{noformat}
Apache Jackrabbit Oak 1.8-SNAPSHOT
11:39:50 - Logging configured from
/mnt/hdd/data/oak/oak-run-indexing/import/temp/logback-indexing.xml
11:39:50 - Any change in logging config would be picked up
11:39:50 - Logs would be written to temp/indexing.log
11:39:51 - Created checkpoint [r15d54512839-0-2] for indexing
11:39:51 - Proceeding to reindex with read only access to NodeStore
11:39:51 - Proceeding to index [/oak:index/lucene] upto checkpoint
r15d54512839-0-2 {creator=IndexCommand, created=2017-07-18T11:39:51.160+05:30}
11:39:51 - Switched the async lane for indexes at [/oak:index/lucene] to
offline-reindex-async and marked them for reindex
11:39:51 - Reindexing will be performed for following indexes:
[/oak:index/lucene]
11:39:51 - Paths to be traversed includedPath : [/], excludedPaths :
[/etc/workflow/instances, /jcr:system, /etc/replication, /var]
11:39:51 - Estimated node count to be traversed for reindexing under / is
[131072]
11:40:02 - Reindexing Traversed #1
/content/mobileapps/we-retail/shell/jcr:content/pge-app/app-content/phonegap/res/screens/android/screen-hdpi-portrait.png/jcr:content
[999.90 nodes/s, 3599640.00 nodes/hr] (Elapsed 10.76 s, Expected 2.017 min,
Completed 7.63%)
11:40:02 - /oak:index/lucene => Indexed 1 nodes in 10.75 s ...
11:40:09 - Reindexing Traversed #2
/content/we-retail/us/en/experience/skiing-deep-powder-in-siberia/jcr:content/root/responsivegrid/content_fragment
[.06 nodes/s, 3999800.00 nodes/hr] (Elapsed 18.06 s, Expected 99.00 s,
Completed 15.26%)
11:40:09 - /oak:index/lucene => Indexed 2 nodes in 7.303 s ...
11:40:18 - Reindexing Traversed #3
/etc/clientlibs/social/thirdparty/ckeditor/plugins/docprops/dialogs/docprops.js
[1153.81 nodes/s, 4153707.69 nodes/hr] (Elapsed 26.80 s, Expected 87.00 s,
Completed 22.89%)
11:40:18 - /oak:index/lucene => Indexed 3 nodes in 8.742 s ...
11:40:26 - Reindexing Traversed #4
/etc/packages/day/cq560/social/calendar/cq-social-calendar-pkg-1.4.33.zip/jcr:content/vlt:definition/filter/f2
[1176.44 nodes/s, 4235188.24 nodes/hr] (Elapsed 34.57 s, Expected 77.00 s,
Completed 30.52%)
11:40:26 - /oak:index/lucene => Indexed 4 nodes in 7.771 s ...
11:40:32 - Reindexing Traversed #5
/libs/cq/contentsync/widgets/source/widgets/ConsolePanel.js/jcr:content
[1249.98 nodes/s, 4499910.00 nodes/hr] (Elapsed 40.73 s, Expected 64.00 s,
Completed 38.15%)
11:40:32 - /oak:index/lucene => Indexed 5 nodes in 6.158 s ...
11:40:41 - Reindexing Traversed #6
/libs/cq/personalization/clientlib/kernel/source/teaser/teaser-client.js/jcr:content
[1199.98 nodes/s, 4319928.00 nodes/hr] (Elapsed 50.30 s, Expected 59.00 s,
Completed 45.78%)
11:40:41 - /oak:index/lucene => Indexed 6 nodes in 9.569 s ...
11:40:48 - Reindexing Traversed #7
/libs/cq/workflow/components/model/step/tab_common/items/timeout/items/timeoutHandler
[1249.98 nodes/s, 4499935.71 nodes/hr] (Elapsed 56.54 s, Expected 48.00 s,
Completed 53.41%)
11:40:48 - /oak:index/lucene => Indexed 7 nodes in 6.240 s ...
11:40:55 - Reindexing Traversed #8
/libs/dam/gui/conten
[jira] [Commented] (OAK-6409) Oak-run indexing: improved (user friendly) output
[
https://issues.apache.org/jira/browse/OAK-6409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16091171#comment-16091171
]
Chetan Mehrotra commented on OAK-6409:
--
Done following changes with 1802241,1802242
# oak-run index would now copy a logback-index.xml to work dir (default ./temp)
and use that for configuring
# Logback is configured to scan the config periodically and if any change is
done at runtime the changes would be picked up
# By default all info logs would be routed to temp/indexing.log
# In addition logs from following categories would be logged at info level to
stdout with just time and message
{noformat}
org.apache.jackrabbit.oak.index
org.apache.jackrabbit.oak.plugins.index.importer
org.apache.jackrabbit.oak.plugins.index.IndexUpdate
org.apache.jackrabbit.oak.plugins.index.progress
{noformat}
Same run
{noformat}
Apache Jackrabbit Oak
11:28:41 - Logging configured from
/mnt/hdd/data/oak/oak-run-indexing/temp/logback-indexing.xml
11:28:41 - Any change in logging config would be picked up
11:28:41 - Logs would be written to temp/indexing.log
/content/oak:index/enablementResourceName => valid
/oak:index/authorizables => valid
/oak:index/commerceLucene => valid
/oak:index/cqMobileAppLucene => valid
/oak:index/cqPageLucene => valid
/oak:index/cqProjectLucene => valid
/oak:index/cqTagLucene => valid
/oak:index/damAssetLucene => valid
/oak:index/lucene => valid
/oak:index/ntBaseLucene => valid
/oak:index/slingeventJob => valid
/oak:index/socialLucene => valid
/oak:index/versionStoreIndex => valid
/oak:index/workflowDataLucene => valid
Index consistency check report stored at
/mnt/hdd/data/oak/oak-run-indexing/indexing-result/index-consistency-check-report.txt
{noformat}
Sample run for indexing
{noformat}
Apache Jackrabbit Oak 1.8-SNAPSHOT
11:39:50 - Logging configured from
/mnt/hdd/data/oak/oak-run-indexing/import/temp/logback-indexing.xml
11:39:50 - Any change in logging config would be picked up
11:39:50 - Logs would be written to temp/indexing.log
11:39:51 - Created checkpoint [r15d54512839-0-2] for indexing
11:39:51 - Proceeding to reindex with read only access to NodeStore
11:39:51 - Proceeding to index [/oak:index/lucene] upto checkpoint
r15d54512839-0-2 {creator=IndexCommand, created=2017-07-18T11:39:51.160+05:30}
11:39:51 - Switched the async lane for indexes at [/oak:index/lucene] to
offline-reindex-async and marked them for reindex
11:39:51 - Reindexing will be performed for following indexes:
[/oak:index/lucene]
11:39:51 - Paths to be traversed includedPath : [/], excludedPaths :
[/etc/workflow/instances, /jcr:system, /etc/replication, /var]
11:39:51 - Estimated node count to be traversed for reindexing under / is
[131072]
11:40:02 - Reindexing Traversed #1
/content/mobileapps/we-retail/shell/jcr:content/pge-app/app-content/phonegap/res/screens/android/screen-hdpi-portrait.png/jcr:content
[999.90 nodes/s, 3599640.00 nodes/hr] (Elapsed 10.76 s, Expected 2.017 min,
Completed 7.63%)
11:40:02 - /oak:index/lucene => Indexed 1 nodes in 10.75 s ...
11:40:09 - Reindexing Traversed #2
/content/we-retail/us/en/experience/skiing-deep-powder-in-siberia/jcr:content/root/responsivegrid/content_fragment
[.06 nodes/s, 3999800.00 nodes/hr] (Elapsed 18.06 s, Expected 99.00 s,
Completed 15.26%)
11:40:09 - /oak:index/lucene => Indexed 2 nodes in 7.303 s ...
11:40:18 - Reindexing Traversed #3
/etc/clientlibs/social/thirdparty/ckeditor/plugins/docprops/dialogs/docprops.js
[1153.81 nodes/s, 4153707.69 nodes/hr] (Elapsed 26.80 s, Expected 87.00 s,
Completed 22.89%)
11:40:18 - /oak:index/lucene => Indexed 3 nodes in 8.742 s ...
11:40:26 - Reindexing Traversed #4
/etc/packages/day/cq560/social/calendar/cq-social-calendar-pkg-1.4.33.zip/jcr:content/vlt:definition/filter/f2
[1176.44 nodes/s, 4235188.24 nodes/hr] (Elapsed 34.57 s, Expected 77.00 s,
Completed 30.52%)
11:40:26 - /oak:index/lucene => Indexed 4 nodes in 7.771 s ...
11:40:32 - Reindexing Traversed #5
/libs/cq/contentsync/widgets/source/widgets/ConsolePanel.js/jcr:content
[1249.98 nodes/s, 4499910.00 nodes/hr] (Elapsed 40.73 s, Expected 64.00 s,
Completed 38.15%)
11:40:32 - /oak:index/lucene => Indexed 5 nodes in 6.158 s ...
11:40:41 - Reindexing Traversed #6
/libs/cq/personalization/clientlib/kernel/source/teaser/teaser-client.js/jcr:content
[1199.98 nodes/s, 4319928.00 nodes/hr] (Elapsed 50.30 s, Expected 59.00 s,
Completed 45.78%)
11:40:41 - /oak:index/lucene => Indexed 6 nodes in 9.569 s ...
11:40:48 - Reindexing Traversed #7
/libs/cq/workflow/components/model/step/tab_common/items/timeout/items/timeoutHandler
[1249.98 nodes/s, 4499935.71 nodes/hr] (Elapsed 56.54 s, Expected 48.00 s,
Completed 53.41%)
11:40:48 - /oak:index/lucene => Indexed 7 nodes in 6.240 s ...
11:40:55 - Reindexing Traversed #8
/libs/dam/gui/content/assets/moveassetwizard/jcr:content/head [1249.9
[jira] [Resolved] (OAK-6341) oak-run redirects reindexing info to STDERR
[ https://issues.apache.org/jira/browse/OAK-6341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved OAK-6341. -- Resolution: Fixed Fix Version/s: 1.7.4 Done as part of OAK-6409. Now logs are routed to stdout > oak-run redirects reindexing info to STDERR > --- > > Key: OAK-6341 > URL: https://issues.apache.org/jira/browse/OAK-6341 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene, run >Affects Versions: 1.8, 1.7.1 >Reporter: Paul Chibulcuteanu >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: 1.8, 1.7.4 > > > Reindexing run via oak-run tool redirects all the important reindexing > information to STDERR. > This is due to > https://github.com/apache/jackrabbit-oak/blob/trunk/oak-run/src/main/resources/logback.xml#L55-L57 > In this particular case, the information should be redirected to STDOUT since > it is important information related to reindexing. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (OAK-6409) Oak-run indexing: improved (user friendly) output
[ https://issues.apache.org/jira/browse/OAK-6409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra reassigned OAK-6409: Assignee: Chetan Mehrotra > Oak-run indexing: improved (user friendly) output > - > > Key: OAK-6409 > URL: https://issues.apache.org/jira/browse/OAK-6409 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing >Reporter: Thomas Mueller >Assignee: Chetan Mehrotra > Fix For: 1.8 > > > The oak-run indexing (OAK-6081) output should be human readable, and if > possible minimal. Detailed output should be written to a log file, but stdout > should be easy for a user to understand. For example some header info when > starting, where to find the detailed output, then one line every 3 seconds > about the progress (in %, number of nodes read, ETA), and when done some info > on what to do next. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6460) Index related tooling
[ https://issues.apache.org/jira/browse/OAK-6460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated OAK-6460: - Epic Name: Index Tooling 1.8 (was: Index Tooling 1.6) > Index related tooling > - > > Key: OAK-6460 > URL: https://issues.apache.org/jira/browse/OAK-6460 > Project: Jackrabbit Oak > Issue Type: Epic > Components: indexing, run >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: 1.8 > > > To enable better management for indexing related operation specially around > reindexing indexes on large repository setup we should implement some tooling > as part of oak-run. This epic is meant to track all work done in this area -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (OAK-6460) Index related tooling
Chetan Mehrotra created OAK-6460: Summary: Index related tooling Key: OAK-6460 URL: https://issues.apache.org/jira/browse/OAK-6460 Project: Jackrabbit Oak Issue Type: Epic Components: indexing, run Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Fix For: 1.8 To enable better management for indexing related operation specially around reindexing indexes on large repository setup we should implement some tooling as part of oak-run. This epic is meant to track all work done in this area -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (OAK-6459) VisibleValidator duplicated in chain for each hierarchy level
Alexander Klimetschek created OAK-6459:
--
Summary: VisibleValidator duplicated in chain for each hierarchy
level
Key: OAK-6459
URL: https://issues.apache.org/jira/browse/OAK-6459
Project: Jackrabbit Oak
Issue Type: Improvement
Reporter: Alexander Klimetschek
VisibleValidator gets chained multiple times, while each one working on the
same NodeState will run the exact same check, NodeStateUtils.isHidden(name).
One execution should be enough.
Below stacktrace has 9 instances chained. Code for propertyAdded as in the
stacktrace below in 1.4 is
[here|https://github.com/apache/jackrabbit-oak/blob/1.4/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/commit/VisibleValidator.java#L82-L83].
Also found a similar stacktrace in OAK-6358 with 12 instances.
This might be a small optimization to make, especially if there are many
properties added, and if there is apparently another variable factor in how
many instances there are.
According to [~stillalex]:
This is directly related to the hierarchy level (so if a change is 5 levels
deep, you'll see 5 validators chained there) and the short fix is to fix calls
[creating new
VisibleValidators|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-store-spi/src/main/java/org/apache/jackrabbit/oak/spi/commit/VisibleValidator.java#L44]
to unwrap if needed, like
[here|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-store-spi/src/main/java/org/apache/jackrabbit/oak/spi/commit/VisibleEditor.java#L38].
{noformat}
Caused by: org.apache.jackrabbit.oak.api.CommitFailedException: OakAccess:
Access denied
at
org.apache.jackrabbit.oak.security.authorization.permission.PermissionValidator.checkPermissions(PermissionValidator.java:242)
at
org.apache.jackrabbit.oak.security.authorization.permission.PermissionValidator.propertyAdded(PermissionValidator.java:112)
at
org.apache.jackrabbit.oak.spi.commit.VisibleValidator.propertyAdded(VisibleValidator.java:83)
at
org.apache.jackrabbit.oak.spi.commit.VisibleValidator.propertyAdded(VisibleValidator.java:83)
at
org.apache.jackrabbit.oak.spi.commit.VisibleValidator.propertyAdded(VisibleValidator.java:83)
at
org.apache.jackrabbit.oak.spi.commit.VisibleValidator.propertyAdded(VisibleValidator.java:83)
at
org.apache.jackrabbit.oak.spi.commit.VisibleValidator.propertyAdded(VisibleValidator.java:83)
at
org.apache.jackrabbit.oak.spi.commit.VisibleValidator.propertyAdded(VisibleValidator.java:83)
at
org.apache.jackrabbit.oak.spi.commit.VisibleValidator.propertyAdded(VisibleValidator.java:83)
at
org.apache.jackrabbit.oak.spi.commit.VisibleValidator.propertyAdded(VisibleValidator.java:83)
at
org.apache.jackrabbit.oak.spi.commit.VisibleValidator.propertyAdded(VisibleValidator.java:83)
at
org.apache.jackrabbit.oak.spi.commit.CompositeEditor.propertyAdded(CompositeEditor.java:83)
at
org.apache.jackrabbit.oak.spi.commit.EditorDiff.propertyAdded(EditorDiff.java:82)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:593)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:491)
at
org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:148)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:531)
at
org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:148)
at
org.apache.jackrabbit.oak.plugins.segment.MapRecord.compare(MapRecord.java:483)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:584)
at
org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:148)
at
org.apache.jackrabbit.oak.plugins.segment.MapRecord.compare(MapRecord.java:483)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:584)
at
org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:148)
at
org.apache.jackrabbit.oak.plugins.segment.MapRecord.compare(MapRecord.java:483)
at
org.apache.jackrabbit.oak.plugins.segment.MapRecord.compareBranch(MapRecord.java:561)
at
org.apache.jackrabbit.oak.plugins.segment.MapRecord.compare(MapRecord.java:466)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:584)
at
org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:148)
at
org.apache.jackrabbit.oak.plugins.segment.MapRecord.compare(MapRecord.java:483)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState.compareAgains
[jira] [Commented] (OAK-5960) Multi blob store support
[ https://issues.apache.org/jira/browse/OAK-5960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16090046#comment-16090046 ] Matt Ryan commented on OAK-5960: AKA CompositeDataStore (not ConsolidatedDataStore) - this is my fault, for some reason the word "Consolidated" keeps sticking in my brain, but CompositeDataStore was the name chosen on oak-dev. I'm pretty sure [~tmueller] got the name from me when I used the wrong name stuck in my brain, my bad. > Multi blob store support > > > Key: OAK-5960 > URL: https://issues.apache.org/jira/browse/OAK-5960 > Project: Jackrabbit Oak > Issue Type: Epic > Components: blob >Reporter: Amit Jain > > Epic to collect issues and discussion for support for multi blob store which > could potentially support the following scenarios: > * A primary writable blob store and read only secondary blob stores - useful > for cloud cross-geo deployments > * Typed blob store where based on type passed the blobs are written and read > from corresponding blob stores. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6457) Increment the segment version number
[ https://issues.apache.org/jira/browse/OAK-6457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Mari updated OAK-6457: Fix Version/s: 1.7.5 > Increment the segment version number > > > Key: OAK-6457 > URL: https://issues.apache.org/jira/browse/OAK-6457 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: segment-tar >Reporter: Francesco Mari >Assignee: Francesco Mari > Fix For: 1.8, 1.7.5 > > > OAK-3349 introduced the tail generation number in the segment header. This > change assigns semantics to a portion of the header that was previously not > used. As such, the segment version should be incremented. Proper checks > should also be put in place to transparently migrate segments from the old to > the new version number. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6458) Increment the manifest version number
[ https://issues.apache.org/jira/browse/OAK-6458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Mari updated OAK-6458: Fix Version/s: 1.7.5 > Increment the manifest version number > - > > Key: OAK-6458 > URL: https://issues.apache.org/jira/browse/OAK-6458 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: segment-tar >Reporter: Francesco Mari >Assignee: Francesco Mari > Fix For: 1.8, 1.7.5 > > > OAK-3349 introduces a tail generation number, and OAK-6456 plans to adding > the tail generation number in the TAR index. To avoid old version of the code > to attempt reading data that would be considered malformed, the manifest > version number should be incremented. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (OAK-6458) Increment the manifest version number
Francesco Mari created OAK-6458: --- Summary: Increment the manifest version number Key: OAK-6458 URL: https://issues.apache.org/jira/browse/OAK-6458 Project: Jackrabbit Oak Issue Type: New Feature Components: segment-tar Reporter: Francesco Mari Assignee: Francesco Mari Fix For: 1.8 OAK-3349 introduces a tail generation number, and OAK-6456 plans to adding the tail generation number in the TAR index. To avoid old version of the code to attempt reading data that would be considered malformed, the manifest version number should be incremented. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (OAK-6457) Increment the segment version number
Francesco Mari created OAK-6457: --- Summary: Increment the segment version number Key: OAK-6457 URL: https://issues.apache.org/jira/browse/OAK-6457 Project: Jackrabbit Oak Issue Type: New Feature Components: segment-tar Reporter: Francesco Mari Assignee: Francesco Mari Fix For: 1.8 OAK-3349 introduced the tail generation number in the segment header. This change assigns semantics to a portion of the header that was previously not used. As such, the segment version should be incremented. Proper checks should also be put in place to transparently migrate segments from the old to the new version number. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (OAK-6456) Include the tail generation in the TAR index
Francesco Mari created OAK-6456: --- Summary: Include the tail generation in the TAR index Key: OAK-6456 URL: https://issues.apache.org/jira/browse/OAK-6456 Project: Jackrabbit Oak Issue Type: New Feature Components: segment-tar Reporter: Francesco Mari Assignee: Francesco Mari Fix For: 1.8 OAK-3349 introduces the tail generation, an additional generation number associated to each segment that is consulted during the cleanup phase to determine if a segment should be removed. The tail generation is currently only preset in the segments. For efficiency purposes, it should be added to the TAR index instead, like the full generation number. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (OAK-6427) Duplicate class: MongoDocumentStoreHelper
[ https://issues.apache.org/jira/browse/OAK-6427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-6427. - Bulk close for 1.6.3 > Duplicate class: MongoDocumentStoreHelper > - > > Key: OAK-6427 > URL: https://issues.apache.org/jira/browse/OAK-6427 > Project: Jackrabbit Oak > Issue Type: Test > Components: core >Affects Versions: 1.7.0, 1.6.2, 1.4.16 >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.8, 1.7.4, 1.4.17, 1.6.3 > > > OAK-6223 introduced the test class MongoDocumentStoreHelper which is already > present in oak-run-commons. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (OAK-6413) FileCache getIfPresent doesn't update cache hit/miss counters
[
https://issues.apache.org/jira/browse/OAK-6413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-6413.
-
Bulk close for 1.6.3
> FileCache getIfPresent doesn't update cache hit/miss counters
> -
>
> Key: OAK-6413
> URL: https://issues.apache.org/jira/browse/OAK-6413
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: blob
>Affects Versions: 1.6.1
>Reporter: Ioan-Cristian Linte
>Assignee: Amit Jain
>Priority: Minor
> Fix For: 1.8, 1.7.4, 1.6.3
>
>
> {{FileCache.getIfPresent}} bypasses cache access if key is not in cache and
> CacheStats for "DataStore-DownloadCache" MBean will always have 100% hit rate
> even when Blobs will be downloaded from the BlobStore backend by
> {{AbstractSharedCachingDataStore}} because of the miss in the cache.
> I suggest the following change:
> {{FileCache.getIfPresent}} to call {{CacheLIRS.getIfPresent}} which will
> update the cache stats (miss and hit counters).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (OAK-5899) PropertyDefinitions should allow for some tweakability to declare usefulness
[
https://issues.apache.org/jira/browse/OAK-5899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-5899.
-
Bulk close for 1.6.3
> PropertyDefinitions should allow for some tweakability to declare usefulness
>
>
> Key: OAK-5899
> URL: https://issues.apache.org/jira/browse/OAK-5899
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Chetan Mehrotra
>Priority: Blocker
> Fix For: 1.8, 1.7.4, 1.6.3
>
> Attachments: OAK-5899-v1.patch
>
>
> At times, we have property definitions which are added to support for dense
> results right out of the index (e.g. {{contains(\*, 'foo') AND
> \[bar]='baz'}}).
> In such cases, the added property definition "might" not be the best one to
> answer queries which only have the property restriction (eg only
> {{\[bar]='baz'}}
> There should be a way for property definition to declare this. May be there
> are cases of some spectrum too - i.e. not only a boolean-usable-or-not, but
> some kind of scale of how-usable is it.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (OAK-6374) S3Backend masks actual thrown error when problem in filtering properties
[ https://issues.apache.org/jira/browse/OAK-6374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-6374. - Bulk close for 1.6.3 > S3Backend masks actual thrown error when problem in filtering properties > > > Key: OAK-6374 > URL: https://issues.apache.org/jira/browse/OAK-6374 > Project: Jackrabbit Oak > Issue Type: Bug > Components: blob, blob-cloud >Reporter: Amit Jain >Assignee: Amit Jain > Fix For: 1.8, 1.7.3, 1.6.3 > > > S3Backend masks the actual error making debugging hard if there's a problem > in filtering properties when value for some key is null. > Currently, guava's Maps.fromProprties is being used and it throws a NPE when > the value is null. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (OAK-5949) XPath: string literals parsed as identifiers
[
https://issues.apache.org/jira/browse/OAK-5949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-5949.
-
Bulk close for 1.6.3
> XPath: string literals parsed as identifiers
>
>
> Key: OAK-5949
> URL: https://issues.apache.org/jira/browse/OAK-5949
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Critical
> Labels: candidate_oak_1_2, candidate_oak_1_4, candidate_oak_1_6
> Fix For: 1.8, 1.7.1, 1.2.27, 1.4.17, 1.6.3
>
>
> The following query (for example) is not parsed correctly, as {{@}} is parsed
> as attribute prefix:
> {noformat}
> /jcr:root/home//element(*,rep:Authorizable)[jcr:like(@rep:authorizableId,'@')]
> {noformat}
> Possibly XPathToSQL2Converter should use currentTokenQuoted for this.
> Possibly a similar problem can occur in SQL2Parser (needs to be tested).
> Right now, it looks like currentTokenQuoted is never set to true; that should
> probably happen in read().
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6450) Stop relying on the service.pid property in SecurityProviderRegistration
[
https://issues.apache.org/jira/browse/OAK-6450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16089832#comment-16089832
]
Chetan Mehrotra commented on OAK-6450:
--
Looks fine to me
> Stop relying on the service.pid property in SecurityProviderRegistration
>
>
> Key: OAK-6450
> URL: https://issues.apache.org/jira/browse/OAK-6450
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: security
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: 1.8, 1.7.4
>
> Attachments:
> 0001-OAK-6450-Stop-relying-on-the-service.pid-property-in.patch,
> 0002-OAK-6450-Stop-relying-on-the-service.pid-property-in.patch
>
>
> As discussed in OAK-6111, we should stop relying on the {{service.pid}} OSGi
> property for tracking required services as it was incorrectly set so far by
> the {{maven-scr-plugin}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-5740) deliver overflow change even without new commit
[
https://issues.apache.org/jira/browse/OAK-5740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated OAK-5740:
-
Attachment: OAK-5740.v3.patch
Attached [^OAK-5740.v3.patch] which combines [~catholicon]'s v2-patch.patch
ontop of v2.patch.
Reiterating the main change this would introduce:
* prior behavior was that the {{full}} boolean carried the overflow flag. Upon
arrival of a new commit and this flag being true and the queue was not empty,
an overflow entry would be added to the queue. Without any new commit arriving
though, this overflow entry (in the form of the {{full}} flag) would just sit
and wait (for a new commit).
* new behavior is that the {{full}} flag is gone. when a commit doesn't fit
into the queue, the last entry is removed and a compaction entry is added. if
more new commits arrive this procedure is repeated. This is a slight slower
implementation as it has to check-for-full, then remove, then add, while as
previously it was just doing a check-for-full. But this is when the queue is
full, so shouldnt influence normal behavior, and it is a rather academic aspect
anyway.
[~catholicon], [~mduerig], [~chetanm], [~mreutegg], wdyt, should I push the
patch?
> deliver overflow change even without new commit
> ---
>
> Key: OAK-5740
> URL: https://issues.apache.org/jira/browse/OAK-5740
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.6.0
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Minor
> Fix For: 1.8
>
> Attachments: OAK-5740.StuffAtop-v2-patch.patch,
> OAK-5740.testcase.patch, OAK-5740.testcase.patch, OAK-5740.v2.patch,
> OAK-5740.v3.patch
>
>
> As [reported|http://markmail.org/message/2qxle24f6zu2vpms] by [~catholicon]
> on oak-dev the observation queue only delivers the so-called _overflow
> entry/change_ only when new commits are 'coming in'. We might want to
> consider fixing this, even though arguably this is a very rare case (since
> typically the observation queue is configured to be very large)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6450) Stop relying on the service.pid property in SecurityProviderRegistration
[
https://issues.apache.org/jira/browse/OAK-6450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16089787#comment-16089787
]
Robert Munteanu commented on OAK-6450:
--
[~chetanm] was kind enough to spell it out more be in an offline discussion -
for existing components we will keep using the FQCN with {{oak.security.name}},
but for new components added to trunk we are free to use a simpler name.
Obviously, I fully agree with this statement.
Chetan - do you have any other comments related to the patch?
> Stop relying on the service.pid property in SecurityProviderRegistration
>
>
> Key: OAK-6450
> URL: https://issues.apache.org/jira/browse/OAK-6450
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: security
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: 1.8, 1.7.4
>
> Attachments:
> 0001-OAK-6450-Stop-relying-on-the-service.pid-property-in.patch,
> 0002-OAK-6450-Stop-relying-on-the-service.pid-property-in.patch
>
>
> As discussed in OAK-6111, we should stop relying on the {{service.pid}} OSGi
> property for tracking required services as it was incorrectly set so far by
> the {{maven-scr-plugin}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6450) Stop relying on the service.pid property in SecurityProviderRegistration
[
https://issues.apache.org/jira/browse/OAK-6450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16089769#comment-16089769
]
Robert Munteanu commented on OAK-6450:
--
Wouldn't that complicate upgrades from older versions? I think we should keep
upgrade work to a minimum.
> Stop relying on the service.pid property in SecurityProviderRegistration
>
>
> Key: OAK-6450
> URL: https://issues.apache.org/jira/browse/OAK-6450
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: security
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: 1.8, 1.7.4
>
> Attachments:
> 0001-OAK-6450-Stop-relying-on-the-service.pid-property-in.patch,
> 0002-OAK-6450-Stop-relying-on-the-service.pid-property-in.patch
>
>
> As discussed in OAK-6111, we should stop relying on the {{service.pid}} OSGi
> property for tracking required services as it was incorrectly set so far by
> the {{maven-scr-plugin}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6450) Stop relying on the service.pid property in SecurityProviderRegistration
[
https://issues.apache.org/jira/browse/OAK-6450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16089765#comment-16089765
]
Chetan Mehrotra commented on OAK-6450:
--
What I meant was for new entries made to SecurityProviderRegistration after 1.6
need not be FQCN. Existing ones should continue as FQCN
> Stop relying on the service.pid property in SecurityProviderRegistration
>
>
> Key: OAK-6450
> URL: https://issues.apache.org/jira/browse/OAK-6450
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: security
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: 1.8, 1.7.4
>
> Attachments:
> 0001-OAK-6450-Stop-relying-on-the-service.pid-property-in.patch,
> 0002-OAK-6450-Stop-relying-on-the-service.pid-property-in.patch
>
>
> As discussed in OAK-6111, we should stop relying on the {{service.pid}} OSGi
> property for tracking required services as it was incorrectly set so far by
> the {{maven-scr-plugin}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6450) Stop relying on the service.pid property in SecurityProviderRegistration
[
https://issues.apache.org/jira/browse/OAK-6450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16089761#comment-16089761
]
Robert Munteanu commented on OAK-6450:
--
Right. But then how do we set the properties? Currently the default required
services list is
{noformat}
"org.apache.jackrabbit.oak.security.authorization.AuthorizationConfigurationImpl",
"org.apache.jackrabbit.oak.security.principal.PrincipalConfigurationImpl",
"org.apache.jackrabbit.oak.security.authentication.token.TokenConfigurationImpl",
"org.apache.jackrabbit.oak.spi.security.user.action.DefaultAuthorizableActionProvider",
"org.apache.jackrabbit.oak.security.authorization.restriction.RestrictionProviderImpl",
"org.apache.jackrabbit.oak.security.user.UserAuthenticationFactoryImpl"{noformat}
If we use the short names we need to change this value. All users of the
{{SecurityProviderRegistration}} need to do the same in their configurations.
But once we do that the check for the {{service.pid}} properties will no longer
be valid as the values are different.
> Stop relying on the service.pid property in SecurityProviderRegistration
>
>
> Key: OAK-6450
> URL: https://issues.apache.org/jira/browse/OAK-6450
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: security
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: 1.8, 1.7.4
>
> Attachments:
> 0001-OAK-6450-Stop-relying-on-the-service.pid-property-in.patch,
> 0002-OAK-6450-Stop-relying-on-the-service.pid-property-in.patch
>
>
> As discussed in OAK-6111, we should stop relying on the {{service.pid}} OSGi
> property for tracking required services as it was incorrectly set so far by
> the {{maven-scr-plugin}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6425) Make the CompositeNodeStore thread-safe
[ https://issues.apache.org/jira/browse/OAK-6425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16089756#comment-16089756 ] Tomek Rękawek commented on OAK-6425: [~chetanm], thanks for noticing the observer issue. Created OAK-6455 to cover this. > Make the CompositeNodeStore thread-safe > --- > > Key: OAK-6425 > URL: https://issues.apache.org/jira/browse/OAK-6425 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: composite >Reporter: Tomek Rękawek >Assignee: Tomek Rękawek > Fix For: 1.8, 1.7.4 > > > The CompositeNodeStore, unlike other *NodeStore implementations, is not > thread safe (eg. two concurrent merge() invocations may leave the repository > in inconsistent state). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6455) Don't call observer concurrently from the CompositeNodeStore
[
https://issues.apache.org/jira/browse/OAK-6455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomek Rękawek updated OAK-6455:
---
Description:
Per Observer interface
{noformat}
However, each observer is
* always guaranteed to see a linear sequence of changes. In other words the
* method will not be called concurrently from multiple threads and successive
* calls represent a linear sequence of repository states, i.e. the root
* state passed to a call is guaranteed to represent a repository state
{noformat}
Currently concurrent merge would result in concurrent calls to Observer. So
that would need to be serialized
> Don't call observer concurrently from the CompositeNodeStore
>
>
> Key: OAK-6455
> URL: https://issues.apache.org/jira/browse/OAK-6455
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: composite
>Reporter: Tomek Rękawek
> Fix For: 1.8
>
>
> Per Observer interface
> {noformat}
> However, each observer is
> * always guaranteed to see a linear sequence of changes. In other words the
> * method will not be called concurrently from multiple threads and successive
> * calls represent a linear sequence of repository states, i.e. the root
> * state passed to a call is guaranteed to represent a repository state
> {noformat}
> Currently concurrent merge would result in concurrent calls to Observer. So
> that would need to be serialized
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (OAK-6455) Don't call observer concurrently from the CompositeNodeStore
Tomek Rękawek created OAK-6455: -- Summary: Don't call observer concurrently from the CompositeNodeStore Key: OAK-6455 URL: https://issues.apache.org/jira/browse/OAK-6455 Project: Jackrabbit Oak Issue Type: Bug Components: composite Reporter: Tomek Rękawek Fix For: 1.8 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-6450) Stop relying on the service.pid property in SecurityProviderRegistration
[
https://issues.apache.org/jira/browse/OAK-6450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16089741#comment-16089741
]
Chetan Mehrotra commented on OAK-6450:
--
Sorry was not clear before - What I meant was for newer names we need not use
FQCN. For existing ones yes they need to be FQCN
> Stop relying on the service.pid property in SecurityProviderRegistration
>
>
> Key: OAK-6450
> URL: https://issues.apache.org/jira/browse/OAK-6450
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: security
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: 1.8, 1.7.4
>
> Attachments:
> 0001-OAK-6450-Stop-relying-on-the-service.pid-property-in.patch,
> 0002-OAK-6450-Stop-relying-on-the-service.pid-property-in.patch
>
>
> As discussed in OAK-6111, we should stop relying on the {{service.pid}} OSGi
> property for tracking required services as it was incorrectly set so far by
> the {{maven-scr-plugin}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6425) Make the CompositeNodeStore thread-safe
[
https://issues.apache.org/jira/browse/OAK-6425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16089701#comment-16089701
]
Chetan Mehrotra commented on OAK-6425:
--
Have not looked at new change closely yet. However looking at current flow I
think Observation handling needs bit of locking.
Per Observer interface
{noformat}
However, each observer is
* always guaranteed to see a linear sequence of changes. In other words the
* method will not be called concurrently from multiple threads and successive
* calls represent a linear sequence of repository states, i.e. the root
* state passed to a call is guaranteed to represent a repository state
{noformat}
Currently concurrent merge would result in concurrent calls to Observer. So
that would need to be serialized. As for changed merge logic it would be good
if [~mreutegg] can have a look
> Make the CompositeNodeStore thread-safe
> ---
>
> Key: OAK-6425
> URL: https://issues.apache.org/jira/browse/OAK-6425
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: composite
>Reporter: Tomek Rękawek
>Assignee: Tomek Rękawek
> Fix For: 1.8, 1.7.4
>
>
> The CompositeNodeStore, unlike other *NodeStore implementations, is not
> thread safe (eg. two concurrent merge() invocations may leave the repository
> in inconsistent state).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (OAK-6454) Inaccurate data in the oak-upgrade progress logger
Tomek Rękawek created OAK-6454: -- Summary: Inaccurate data in the oak-upgrade progress logger Key: OAK-6454 URL: https://issues.apache.org/jira/browse/OAK-6454 Project: Jackrabbit Oak Issue Type: Bug Components: upgrade Reporter: Tomek Rękawek Fix For: 1.8 After recent oak-upgrade improvements related to the checkpoint migration, the node counter inside the progress logger displays 2 times higher values. The progress logger should be fixed to provide more accurate values. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (OAK-6454) Inaccurate data in the oak-upgrade progress logger
[ https://issues.apache.org/jira/browse/OAK-6454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomek Rękawek reassigned OAK-6454: -- Assignee: Tomek Rękawek > Inaccurate data in the oak-upgrade progress logger > -- > > Key: OAK-6454 > URL: https://issues.apache.org/jira/browse/OAK-6454 > Project: Jackrabbit Oak > Issue Type: Bug > Components: upgrade >Reporter: Tomek Rękawek >Assignee: Tomek Rękawek > Fix For: 1.8 > > > After recent oak-upgrade improvements related to the checkpoint migration, > the node counter inside the progress logger displays 2 times higher values. > The progress logger should be fixed to provide more accurate values. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-6450) Stop relying on the service.pid property in SecurityProviderRegistration
[
https://issues.apache.org/jira/browse/OAK-6450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16089660#comment-16089660
]
Robert Munteanu commented on OAK-6450:
--
If the values are not FQCN then we can't be backwards compatible with
properties registered using the service.pid property, which I consider useful.
> Stop relying on the service.pid property in SecurityProviderRegistration
>
>
> Key: OAK-6450
> URL: https://issues.apache.org/jira/browse/OAK-6450
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: security
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: 1.8, 1.7.4
>
> Attachments:
> 0001-OAK-6450-Stop-relying-on-the-service.pid-property-in.patch,
> 0002-OAK-6450-Stop-relying-on-the-service.pid-property-in.patch
>
>
> As discussed in OAK-6111, we should stop relying on the {{service.pid}} OSGi
> property for tracking required services as it was incorrectly set so far by
> the {{maven-scr-plugin}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6450) Stop relying on the service.pid property in SecurityProviderRegistration
[
https://issues.apache.org/jira/browse/OAK-6450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16089659#comment-16089659
]
Chetan Mehrotra commented on OAK-6450:
--
bq. I don't have to duplicate the class names everywhere
Thats useful. However given similar change in Sling side were done by using
custom property names ... lets follow same pattern here and avoid depending on
DS specific property. Also the property value need not be FQCN. Just some
logically unique name
> Stop relying on the service.pid property in SecurityProviderRegistration
>
>
> Key: OAK-6450
> URL: https://issues.apache.org/jira/browse/OAK-6450
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: security
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: 1.8, 1.7.4
>
> Attachments:
> 0001-OAK-6450-Stop-relying-on-the-service.pid-property-in.patch,
> 0002-OAK-6450-Stop-relying-on-the-service.pid-property-in.patch
>
>
> As discussed in OAK-6111, we should stop relying on the {{service.pid}} OSGi
> property for tracking required services as it was incorrectly set so far by
> the {{maven-scr-plugin}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-6450) Stop relying on the service.pid property in SecurityProviderRegistration
[
https://issues.apache.org/jira/browse/OAK-6450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated OAK-6450:
-
Attachment: 0002-OAK-6450-Stop-relying-on-the-service.pid-property-in.patch
[~chetanm] - I've uploaded a second patch ( cumulates with the first ) which
uses the {{oak.security.name}} component property instead of {{component.name}}.
I slight prefer the first variant as
- I don't have to duplicate the class names everywhere
- components registered outside of SCR can set the {{component.name}} property
themselves
All in all it's not a big deal, if the second variant looks better to you I
will commit it.
> Stop relying on the service.pid property in SecurityProviderRegistration
>
>
> Key: OAK-6450
> URL: https://issues.apache.org/jira/browse/OAK-6450
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: security
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: 1.8, 1.7.4
>
> Attachments:
> 0001-OAK-6450-Stop-relying-on-the-service.pid-property-in.patch,
> 0002-OAK-6450-Stop-relying-on-the-service.pid-property-in.patch
>
>
> As discussed in OAK-6111, we should stop relying on the {{service.pid}} OSGi
> property for tracking required services as it was incorrectly set so far by
> the {{maven-scr-plugin}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6425) Make the CompositeNodeStore thread-safe
[
https://issues.apache.org/jira/browse/OAK-6425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16089636#comment-16089636
]
Tomek Rękawek commented on OAK-6425:
Actually, locking the merge locally won't help with the underlying node store
is distributed. I created new AtomicCompositeMergeTest to show this behaviour.
There are two test methods, for the local and shared stores. The second test
method fails.
So, maybe rather than using locks, we can pass the commit hook to the global
node store, as [~chetanm] suggested? However, [~mduerig] is also right, that
these commit hooks need to have access to the whole repo. My idea is to wrap
the passed commit hook with an extra class, that will replace the {{before}}
and {{after}} node states with their composite equivalents. See
CommitHookEnhancer for more details.
Fixed as above in [r1802126|https://svn.apache.org/r1802126].
> Make the CompositeNodeStore thread-safe
> ---
>
> Key: OAK-6425
> URL: https://issues.apache.org/jira/browse/OAK-6425
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: composite
>Reporter: Tomek Rękawek
>Assignee: Tomek Rękawek
> Fix For: 1.8, 1.7.4
>
>
> The CompositeNodeStore, unlike other *NodeStore implementations, is not
> thread safe (eg. two concurrent merge() invocations may leave the repository
> in inconsistent state).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-6081) Indexing tooling via oak-run
[ https://issues.apache.org/jira/browse/OAK-6081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated OAK-6081: - Description: To enable better management for indexing related operation specially around reindexing indexes on large repository setup we should implement some tooling as part of oak-run The tool would support # For DocumentNodeStore setup it would be possible to connect oak-run to a live cluster and it would take care of indexing -> storing index on disk -> merging index -> importing it back at end. This would ensure that live setup faces minimum disruption and is not loaded much # For SegementNodeStore setup it would be possible to index on a cloned setup and then provide a way to copy the index back Future Enhancements # *Resumable tarversal* - It should be able to reindex large repo with resumable traversal such that even if indexing breaks due to some issue it can resume from last state (OAK-5833) # *Multithreaded traversal* - Current indexing is single threaded and hence for large repo it can take long time. Plan here is to support multi threaded indexing where each thread can be assigned a part of repository tree to index and in the end the indexes are merged was: To enable better management for indexing related operation specially around reindexing indexes on large repository setup we should implement some tooling as part of oak-run The tool would support # *Resumable tarversal* - It should be able to reindex large repo with resumable traversal such that even if indexing breaks due to some issue it can resume from last state (OAK-5833) # *Multithreaded traversal* - Current indexing is single threaded and hence for large repo it can take long time. Plan here is to support multi threaded indexing where each thread can be assigned a part of repository tree to index and in the end the indexes are merged # For DocumentNodeStore setup it would be possible to connect oak-run to a live cluster and it would take care of indexing -> storing index on disk -> merging index -> importing it back at end. This would ensure that live setup faces minimum disruption and is not loaded much # For SegementNodeStore setup it would be possible to index on a cloned setup and then provide a way to copy the index back > Indexing tooling via oak-run > > > Key: OAK-6081 > URL: https://issues.apache.org/jira/browse/OAK-6081 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: indexing, run >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: 1.8, 1.7.4 > > > To enable better management for indexing related operation specially around > reindexing indexes on large repository setup we should implement some tooling > as part of oak-run > The tool would support > # For DocumentNodeStore setup it would be possible to connect oak-run to a > live cluster and it would take care of indexing -> storing index on disk -> > merging index -> importing it back at end. This would ensure that live setup > faces minimum disruption and is not loaded much > # For SegementNodeStore setup it would be possible to index on a cloned setup > and then provide a way to copy the index back > Future Enhancements > # *Resumable tarversal* - It should be able to reindex large repo with > resumable traversal such that even if indexing breaks due to some issue it > can resume from last state (OAK-5833) > # *Multithreaded traversal* - Current indexing is single threaded and hence > for large repo it can take long time. Plan here is to support multi threaded > indexing where each thread can be assigned a part of repository tree to index > and in the end the indexes are merged -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (OAK-6081) Indexing tooling via oak-run
[ https://issues.apache.org/jira/browse/OAK-6081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved OAK-6081. -- Resolution: Fixed Fix Version/s: 1.7.4 All initial planned work for tooling is done now. > Indexing tooling via oak-run > > > Key: OAK-6081 > URL: https://issues.apache.org/jira/browse/OAK-6081 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: indexing, run >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: 1.8, 1.7.4 > > > To enable better management for indexing related operation specially around > reindexing indexes on large repository setup we should implement some tooling > as part of oak-run > The tool would support > # *Resumable tarversal* - It should be able to reindex large repo with > resumable traversal such that even if indexing breaks due to some issue it > can resume from last state (OAK-5833) > # *Multithreaded traversal* - Current indexing is single threaded and hence > for large repo it can take long time. Plan here is to support multi threaded > indexing where each thread can be assigned a part of repository tree to index > and in the end the indexes are merged > # For DocumentNodeStore setup it would be possible to connect oak-run to a > live cluster and it would take care of indexing -> storing index on disk -> > merging index -> importing it back at end. This would ensure that live setup > faces minimum disruption and is not loaded much > # For SegementNodeStore setup it would be possible to index on a cloned setup > and then provide a way to copy the index back -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-5566) TestFailure: remote.http.handler.RemoteServerIT.testPatchLastRevisionAddMultiReferenceProperty
[ https://issues.apache.org/jira/browse/OAK-5566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-5566: -- Fix Version/s: (was: 1.4.17) 1.4.18 > TestFailure: > remote.http.handler.RemoteServerIT.testPatchLastRevisionAddMultiReferenceProperty > -- > > Key: OAK-5566 > URL: https://issues.apache.org/jira/browse/OAK-5566 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration, remoting >Reporter: Hudson > Labels: test-failure, ubuntu > Fix For: 1.4.18 > > > 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=DOCUMENT_RDB,profile=integrationTesting #1396 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.8 (latest),nsfixtures=DOCUMENT_RDB,profile=integrationTesting > #1396|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=DOCUMENT_RDB,profile=integrationTesting/1396/] > [console > log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=DOCUMENT_RDB,profile=integrationTesting/1396/console] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-5509) Backport Lucene index stability improvements to 1.4
[ https://issues.apache.org/jira/browse/OAK-5509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-5509: -- Fix Version/s: (was: 1.4.17) 1.4.18 > Backport Lucene index stability improvements to 1.4 > --- > > Key: OAK-5509 > URL: https://issues.apache.org/jira/browse/OAK-5509 > Project: Jackrabbit Oak > Issue Type: Task > Components: lucene >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: 1.4.18 > > > In 1.6 (trunk) quite a few improvement were in Lucene indexing to make it > more resilient against corruption (OAK-3269). This task is meant to determine > which all are safe to backport to 1.4 branch -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-5418) Test failure: TomcatIT.testTomcat()
[ https://issues.apache.org/jira/browse/OAK-5418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-5418: -- Fix Version/s: (was: 1.4.17) 1.4.18 > Test failure: TomcatIT.testTomcat() > --- > > Key: OAK-5418 > URL: https://issues.apache.org/jira/browse/OAK-5418 > Project: Jackrabbit Oak > Issue Type: Test > Components: continuous integration, examples >Affects Versions: 1.4 >Reporter: Hudson >Assignee: Chetan Mehrotra > Labels: test-failure, ubuntu > Fix For: 1.4.18 > > > 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=DOCUMENT_NS,profile=unittesting #1357 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.7 (latest),nsfixtures=DOCUMENT_NS,profile=unittesting > #1357|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=DOCUMENT_NS,profile=unittesting/1357/] > [console > log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=DOCUMENT_NS,profile=unittesting/1357/console] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-5458) Test failure: RepositoryBootIT.repositoryLogin
[ https://issues.apache.org/jira/browse/OAK-5458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-5458: -- Fix Version/s: (was: 1.4.17) 1.4.18 > Test failure: RepositoryBootIT.repositoryLogin > -- > > Key: OAK-5458 > URL: https://issues.apache.org/jira/browse/OAK-5458 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration, examples >Affects Versions: 1.4, 1.5.18 >Reporter: Hudson >Assignee: Chetan Mehrotra > Labels: test-failure, ubuntu > Fix For: 1.8, 1.6.4, 1.4.18 > > Attachments: unit-tests-1379.log > > > 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 #1369 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.8 (latest),nsfixtures=SEGMENT_MK,profile=integrationTesting > #1369|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=SEGMENT_MK,profile=integrationTesting/1369/] > [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/1369/console] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-5470) Test failure: SecurityProviderRegistrationTest.testSecurityConfigurations2
[ https://issues.apache.org/jira/browse/OAK-5470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-5470: -- Fix Version/s: (was: 1.4.17) 1.4.18 > Test failure: SecurityProviderRegistrationTest.testSecurityConfigurations2 > -- > > Key: OAK-5470 > URL: https://issues.apache.org/jira/browse/OAK-5470 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration, pojosr >Affects Versions: 1.2.23, 1.4.13 >Reporter: Hudson > Labels: test-failure, windows > Fix For: 1.2.27, 1.4.18 > > Attachments: sysout-1380.log, unit-tests-build-1371.log, > unit-tests.log > > > 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=unittesting #1371 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.7 (latest),nsfixtures=SEGMENT_TAR,profile=unittesting > #1371|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=SEGMENT_TAR,profile=unittesting/1371/] > [console > log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=SEGMENT_TAR,profile=unittesting/1371/console] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (OAK-6453) Script to import oak-run generated indexing to older Oak setup
Chetan Mehrotra created OAK-6453: Summary: Script to import oak-run generated indexing to older Oak setup Key: OAK-6453 URL: https://issues.apache.org/jira/browse/OAK-6453 Project: Jackrabbit Oak Issue Type: Improvement Components: indexing, run Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Fix For: 1.8 The indexing tooling implemented in OAK-6081 can be used to perform reindex and import the indexes for any Oak 1.7+ setups. For older setups we would be using 2 phase approach # Perform [out-of-band indexing|https://jackrabbit.apache.org/oak/docs/query/oak-run-indexing.html#out-of-band-indexing]. This can be done via oak-run from 1.7.x against any older version of Oak # Import index - For this step we cannot use oak-run from trunk for older branches as write operations would not be compatible with older version of Oak. For import then we have 2 options either # backport all the work in OAK-6271 to older branch # OR implement a script which can be used with oak-run or Felix Script Console to just import the lucene index with any other manual step Purpose of this task is to implement such a script -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (OAK-6061) Test failure: StandbyTestIT.testSyncLoop
[
https://issues.apache.org/jira/browse/OAK-6061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari resolved OAK-6061.
-
Resolution: Fixed
This test doesn't fail since a while. Resolving this issue.
> Test failure: StandbyTestIT.testSyncLoop
>
>
> Key: OAK-6061
> URL: https://issues.apache.org/jira/browse/OAK-6061
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration, segment-tar
>Reporter: Hudson
>Assignee: Francesco Mari
> Labels: CI, flaky-test, jenkins
> Fix For: 1.7.4
>
> Attachments: stdout.log
>
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #144 has failed.
> First failed run: [Jackrabbit Oak
> #144|https://builds.apache.org/job/Jackrabbit%20Oak/144/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/144/console]
> Error Message
> {code}
> expected: org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints =
> { ... }, root = { ... } }> but was:
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... },
> root = { ... } }>
> {code}
> Stacktrace
> {code}
> java.lang.AssertionError: expected:
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... },
> root = { ... } }> but was:
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... },
> root = { ... } }>
> at
> org.apache.jackrabbit.oak.segment.standby.StandbyTestIT.testSyncLoop(StandbyTestIT.java:126)
> {code}
> Standard Output
> [^stdout.log]
> Also failed at https://builds.apache.org/job/Jackrabbit%20Oak/394/
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6081) Indexing tooling via oak-run
[ https://issues.apache.org/jira/browse/OAK-6081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16089420#comment-16089420 ] Chetan Mehrotra commented on OAK-6081: -- Documented now at https://jackrabbit.apache.org/oak/docs/query/oak-run-indexing.html > Indexing tooling via oak-run > > > Key: OAK-6081 > URL: https://issues.apache.org/jira/browse/OAK-6081 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: indexing, run >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: 1.8 > > > To enable better management for indexing related operation specially around > reindexing indexes on large repository setup we should implement some tooling > as part of oak-run > The tool would support > # *Resumable tarversal* - It should be able to reindex large repo with > resumable traversal such that even if indexing breaks due to some issue it > can resume from last state (OAK-5833) > # *Multithreaded traversal* - Current indexing is single threaded and hence > for large repo it can take long time. Plan here is to support multi threaded > indexing where each thread can be assigned a part of repository tree to index > and in the end the indexes are merged > # For DocumentNodeStore setup it would be possible to connect oak-run to a > live cluster and it would take care of indexing -> storing index on disk -> > merging index -> importing it back at end. This would ensure that live setup > faces minimum disruption and is not loaded much > # For SegementNodeStore setup it would be possible to index on a cloned setup > and then provide a way to copy the index back -- This message was sent by Atlassian JIRA (v6.4.14#64029)
