[jira] [Updated] (OAK-5931) Inconsistent behaviour when removing nodes with rep:policy subnodes for users without modify ACL permissions
[
https://issues.apache.org/jira/browse/OAK-5931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Saar updated OAK-5931:
Fix Version/s: 1.8
> Inconsistent behaviour when removing nodes with rep:policy subnodes for
> users without modify ACL permissions
> -
>
> Key: OAK-5931
> URL: https://issues.apache.org/jira/browse/OAK-5931
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security
>Affects Versions: 1.4.14, 1.6.1
>Reporter: Tom Blackford
> Fix For: 1.8
>
> Attachments: ACLTest.java
>
>
> If a session (without rep:modifyAccessControl) removes a node with a
> rep:policy subnode and then recreates it within the same save (without the
> rep:policy subnode) the commit diff will mistake the action for the removal
> of the ACL, which this session is not authorised to do.
> If the session is saved prior to recreating the node, both saves (after
> remove and after recreate) will succeed.
> From discussion with angela:
> {quote}
> the diff mechanism used within Root.commit cannot distinguish between the
> removal of a policy or the replace of the access controlled node with one
> that doesn't have the policy set. within that diff it looks like the removal
> of the policy node
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (OAK-5923) Document S3 datastore
[ https://issues.apache.org/jira/browse/OAK-5923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Saar reassigned OAK-5923: --- Assignee: Amit Jain > Document S3 datastore > - > > Key: OAK-5923 > URL: https://issues.apache.org/jira/browse/OAK-5923 > Project: Jackrabbit Oak > Issue Type: Documentation > Components: blob >Reporter: Alexander Klimetschek >Assignee: Amit Jain > Fix For: 1.6.2 > > > The S3 datastore is currently hardly documented. > The [generic blobstore > documentation|http://jackrabbit.apache.org/oak/docs/plugins/blobstore.html] > is very much focused about the internal class structures, but quite confusing > for someone who wants to configure a specific datastore such as file and s3 > (the only ones right now). S3 settings are not documented at all, the [config > page|http://jackrabbit.apache.org/oak/docs/osgi_config.html#config-blobstore] > only mentions the generic maxCachedBinarySize and cacheSizeInMB. > The best bet is the [Adobe AEM product > documentation|https://docs.adobe.com/docs/en/aem/6-2/deploy/platform/data-store-config.html], > but that is for an older version and a few things changed since then. > Specific items below. Some have been confusing people using oak-blob-cloud > 1.5.15: > - "secret" property unclear (new) > - secretKey & accessKey can be omitted to leverage IAM roles (new) > - drop of proactiveCaching property (new) > - aws bucket/region/etc. settings > - config options (timeout, retries, threads) > - understanding caching behavior and performance optimization > - shared vs. non-shared options > - migrating from a previous version, how to update the config > - requirements on the AWS (account) side -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-5923) Document S3 datastore
[ https://issues.apache.org/jira/browse/OAK-5923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Saar updated OAK-5923: Fix Version/s: 1.6.2 > Document S3 datastore > - > > Key: OAK-5923 > URL: https://issues.apache.org/jira/browse/OAK-5923 > Project: Jackrabbit Oak > Issue Type: Documentation > Components: blob >Reporter: Alexander Klimetschek >Assignee: Amit Jain > Fix For: 1.6.2 > > > The S3 datastore is currently hardly documented. > The [generic blobstore > documentation|http://jackrabbit.apache.org/oak/docs/plugins/blobstore.html] > is very much focused about the internal class structures, but quite confusing > for someone who wants to configure a specific datastore such as file and s3 > (the only ones right now). S3 settings are not documented at all, the [config > page|http://jackrabbit.apache.org/oak/docs/osgi_config.html#config-blobstore] > only mentions the generic maxCachedBinarySize and cacheSizeInMB. > The best bet is the [Adobe AEM product > documentation|https://docs.adobe.com/docs/en/aem/6-2/deploy/platform/data-store-config.html], > but that is for an older version and a few things changed since then. > Specific items below. Some have been confusing people using oak-blob-cloud > 1.5.15: > - "secret" property unclear (new) > - secretKey & accessKey can be omitted to leverage IAM roles (new) > - drop of proactiveCaching property (new) > - aws bucket/region/etc. settings > - config options (timeout, retries, threads) > - understanding caching behavior and performance optimization > - shared vs. non-shared options > - migrating from a previous version, how to update the config > - requirements on the AWS (account) side -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (OAK-5772) Test failure: segment.standby.MBeanIT.testClientAndServerEmptyConfig
[ https://issues.apache.org/jira/browse/OAK-5772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Saar reassigned OAK-5772: --- Assignee: Chetan Mehrotra > Test failure: segment.standby.MBeanIT.testClientAndServerEmptyConfig > > > Key: OAK-5772 > URL: https://issues.apache.org/jira/browse/OAK-5772 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration, segment-tar >Affects Versions: 1.6.0 >Reporter: Hudson >Assignee: Chetan Mehrotra > Labels: test-failure, windows > Fix For: 1.6.1 > > > Jenkins Windows CI failure: https://builds.apache.org/job/Oak-Win/ > The build Oak-Win/Windows slaves=Windows,jdk=JDK 1.8 (unlimited security) > 64-bit Windows only,nsfixtures=SEGMENT_TAR,profile=integrationTesting #472 > has failed. > First failed run: [Oak-Win/Windows slaves=Windows,jdk=JDK 1.8 (unlimited > security) 64-bit Windows > only,nsfixtures=SEGMENT_TAR,profile=integrationTesting > #472|https://builds.apache.org/job/Oak-Win/Windows%20slaves=Windows,jdk=JDK%201.8%20(unlimited%20security)%2064-bit%20Windows%20only,nsfixtures=SEGMENT_TAR,profile=integrationTesting/472/] > [console > log|https://builds.apache.org/job/Oak-Win/Windows%20slaves=Windows,jdk=JDK%201.8%20(unlimited%20security)%2064-bit%20Windows%20only,nsfixtures=SEGMENT_TAR,profile=integrationTesting/472/console] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (OAK-5750) Test failure: PojoSR run.osgi.SecurityProviderRegistrationTest
[ https://issues.apache.org/jira/browse/OAK-5750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Saar reassigned OAK-5750: --- Assignee: angela > Test failure: PojoSR run.osgi.SecurityProviderRegistrationTest > -- > > Key: OAK-5750 > URL: https://issues.apache.org/jira/browse/OAK-5750 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration, pojosr >Affects Versions: 1.6.0 >Reporter: Hudson >Assignee: angela > Labels: test-failure, ubuntu > Fix For: 1.6.1 > > Attachments: pojosr-unit-tests.log.bz2 > > > 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 #1441 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.7 (latest),nsfixtures=SEGMENT_TAR,profile=unittesting > #1441|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=SEGMENT_TAR,profile=unittesting/1441/] > [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/1441/console] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (OAK-5736) Test failure: org.apache.jackrabbit.oak.run.osgi.SegmentNodeStoreConfigTest.testDeadlock
[ https://issues.apache.org/jira/browse/OAK-5736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Saar reassigned OAK-5736: --- Assignee: Michael Dürig > Test failure: > org.apache.jackrabbit.oak.run.osgi.SegmentNodeStoreConfigTest.testDeadlock > > > Key: OAK-5736 > URL: https://issues.apache.org/jira/browse/OAK-5736 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration, pojosr >Affects Versions: 1.6.0 >Reporter: Hudson >Assignee: Michael Dürig > Labels: test-failure, windows > Fix For: 1.6.1 > > Attachments: unit-tests.log > > > Jenkins Windows CI failure: https://builds.apache.org/job/Oak-Win/ > The build Oak-Win/Windows slaves=Windows,jdk=JDK 1.8 (unlimited security) > 64-bit Windows only,nsfixtures=SEGMENT_TAR,profile=unittesting #465 has > failed. > First failed run: [Oak-Win/Windows slaves=Windows,jdk=JDK 1.8 (unlimited > security) 64-bit Windows only,nsfixtures=SEGMENT_TAR,profile=unittesting > #465|https://builds.apache.org/job/Oak-Win/Windows%20slaves=Windows,jdk=JDK%201.8%20(unlimited%20security)%2064-bit%20Windows%20only,nsfixtures=SEGMENT_TAR,profile=unittesting/465/] > [console > log|https://builds.apache.org/job/Oak-Win/Windows%20slaves=Windows,jdk=JDK%201.8%20(unlimited%20security)%2064-bit%20Windows%20only,nsfixtures=SEGMENT_TAR,profile=unittesting/465/console] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (OAK-5603) Test failure: oak.upgrade.cli.blob.CopyBinariesTest
[ https://issues.apache.org/jira/browse/OAK-5603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Saar reassigned OAK-5603: --- Assignee: Arek Kita > Test failure: oak.upgrade.cli.blob.CopyBinariesTest > --- > > Key: OAK-5603 > URL: https://issues.apache.org/jira/browse/OAK-5603 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration, upgrade >Reporter: Hudson >Assignee: Arek Kita > Labels: test-failure, windows > Fix For: 1.8, 1.6.1 > > Attachments: unit-tests.log > > > Jenkins Windows CI failure: https://builds.apache.org/job/Oak-Win/ > The build Oak-Win/Windows slaves=Windows,jdk=JDK 1.7 (unlimited security) > 64-bit Windows only,nsfixtures=DOCUMENT_NS,profile=unittesting #438 has > failed. > First failed run: [Oak-Win/Windows slaves=Windows,jdk=JDK 1.7 (unlimited > security) 64-bit Windows only,nsfixtures=DOCUMENT_NS,profile=unittesting > #438|https://builds.apache.org/job/Oak-Win/Windows%20slaves=Windows,jdk=JDK%201.7%20(unlimited%20security)%2064-bit%20Windows%20only,nsfixtures=DOCUMENT_NS,profile=unittesting/438/] > [console > log|https://builds.apache.org/job/Oak-Win/Windows%20slaves=Windows,jdk=JDK%201.7%20(unlimited%20security)%2064-bit%20Windows%20only,nsfixtures=DOCUMENT_NS,profile=unittesting/438/console] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (OAK-5573) org.apache.jackrabbit.oak.segment.standby.StandbyTestIT.testSyncLoop
[ https://issues.apache.org/jira/browse/OAK-5573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Saar reassigned OAK-5573: --- Assignee: Francesco Mari > org.apache.jackrabbit.oak.segment.standby.StandbyTestIT.testSyncLoop > > > Key: OAK-5573 > URL: https://issues.apache.org/jira/browse/OAK-5573 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration, segment-tar >Affects Versions: 1.6.0 >Reporter: Hudson >Assignee: Francesco Mari > Labels: test-failure, ubuntu, windows > Fix For: 1.7.0, 1.8, 1.6.1 > > Attachments: std-output.log, unit-tests-1422.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_MK,profile=integrationTesting #1399 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.7 (latest),nsfixtures=SEGMENT_MK,profile=integrationTesting > #1399|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=SEGMENT_MK,profile=integrationTesting/1399/] > [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/1399/console] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-5636) potential NPE in ReplicaSetInfo
[
https://issues.apache.org/jira/browse/OAK-5636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Saar updated OAK-5636:
Priority: Critical (was: Major)
> potential NPE in ReplicaSetInfo
> ---
>
> Key: OAK-5636
> URL: https://issues.apache.org/jira/browse/OAK-5636
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, mongomk
>Affects Versions: 1.6.0
>Reporter: Julian Reschke
>Assignee: Tomek Rękawek
>Priority: Critical
> Fix For: 1.8, 1.6.1
>
> Attachments: OAK-5636.patch
>
>
> seen in log:
> {noformat}
> java.lang.NullPointerException: null
> at
> com.google.common.base.Preconditions.checkNotNull(Preconditions.java:192)
> ~[oak-run-1.8-SNAPSHOT.jar:1.8-SNAPSHOT]
> at
> com.google.common.collect.SingletonImmutableSet.(SingletonImmutableSet.java:47)
> ~[oak-run-1.8-SNAPSHOT.jar:1.8-SNAPSHOT]
> at com.google.common.collect.ImmutableSet.of(ImmutableSet.java:94)
> ~[oak-run-1.8-SNAPSHOT.jar:1.8-SNAPSHOT]
> at
> org.apache.jackrabbit.oak.plugins.document.mongo.replica.ReplicaSetInfo.updateRevisions(ReplicaSetInfo.java:264)
> ~[oak-run-1.8-SNAPSHOT.jar:1.8-SNAPSHOT]
> at
> org.apache.jackrabbit.oak.plugins.document.mongo.replica.ReplicaSetInfo.updateReplicaStatus(ReplicaSetInfo.java:182)
> ~[oak-run-1.8-SNAPSHOT.jar:1.8-SNAPSHOT]
> at
> org.apache.jackrabbit.oak.plugins.document.mongo.replica.ReplicaSetInfo.updateLoop(ReplicaSetInfo.java:145)
> ~[oak-run-1.8-SNAPSHOT.jar:1.8-SNAPSHOT]
> at
> org.apache.jackrabbit.oak.plugins.document.mongo.replica.ReplicaSetInfo.run(ReplicaSetInfo.java:134)
> ~[oak-run-1.8-SNAPSHOT.jar:1.8-SNAPSHOT]
> at java.lang.Thread.run(Unknown Source) [na:1.8.0_121]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-5519) Skip problematic binaries instead of blocking indexing
[ https://issues.apache.org/jira/browse/OAK-5519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Saar updated OAK-5519: Description: If a text extraction is blocked (weird PDF) or a blob cannot be found in the datastore or any other error upon indexing one item from the repository that is outside the scope of the indexer, it currently halts the indexing (lane). Thus one item (that maybe isn't important to the users at all) can block the indexing of other, new content (that might be important to users), and it always requires manual intervention (which is also not easy and requires oak experts). Instead, the item could be remembered in a known issue list, proper warnings given, and indexing continue. Maintenance operations should be available to come back to reindex these, or the indexer could automatically retry after some time. This would allow normal user activity to go on without manual intervention, and solving the problem (if it's isolated to some binaries) can be deferred. I think the line should probably be drawn for binary properties. Not sure if other JCR property types could trigger a similar issue, and if a failure in them might actually warrant a halt, as it could lead to an "incorrect" index, if these properties are important. But maybe the line is simply a try & catch around "full text extraction". was: If a text extraction is blocked (weird PDF) or a blob cannot be found in the datastore or any other error upon indexing one item from the repository that is outside the scope of the indexer, it currently halts the indexing (lane). Thus one item (that maybe isn't important to the users at all) can block the indexing of other, new content (that might be important to users), and it always requires manual intervention (which is also not easy and requires oak experts). Instead, the item could be remembered in a known issue list, proper warnings given, and indexing continue. Maintenance operations should be available to come back to reindex these once the issue is fixed, or the indexer could automatically retry after some time. This would allow normal user activity to go on, and solving the problem (if it's isolated to some binaries) can be deferred. I think the line should probably be drawn for binary properties. Not sure if other JCR property types could trigger a similar issue, and if a failure in them might actually warrant a halt, as it could lead to an "incorrect" index, if these properties are important. But maybe the line is simply a try & catch around "full text extraction". > Skip problematic binaries instead of blocking indexing > -- > > Key: OAK-5519 > URL: https://issues.apache.org/jira/browse/OAK-5519 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: query >Reporter: Alexander Klimetschek > > If a text extraction is blocked (weird PDF) or a blob cannot be found in the > datastore or any other error upon indexing one item from the repository that > is outside the scope of the indexer, it currently halts the indexing (lane). > Thus one item (that maybe isn't important to the users at all) can block the > indexing of other, new content (that might be important to users), and it > always requires manual intervention (which is also not easy and requires oak > experts). > Instead, the item could be remembered in a known issue list, proper warnings > given, and indexing continue. Maintenance operations should be available to > come back to reindex these, or the indexer could automatically retry after > some time. This would allow normal user activity to go on without manual > intervention, and solving the problem (if it's isolated to some binaries) can > be deferred. > I think the line should probably be drawn for binary properties. Not sure if > other JCR property types could trigger a similar issue, and if a failure in > them might actually warrant a halt, as it could lead to an "incorrect" index, > if these properties are important. But maybe the line is simply a try & catch > around "full text extraction". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-5519) Skip problematic binaries instead of blocking indexing
[ https://issues.apache.org/jira/browse/OAK-5519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Saar updated OAK-5519: Issue Type: New Feature (was: Improvement) > Skip problematic binaries instead of blocking indexing > -- > > Key: OAK-5519 > URL: https://issues.apache.org/jira/browse/OAK-5519 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: query >Reporter: Alexander Klimetschek > > If a text extraction is blocked (weird PDF) or a blob cannot be found in the > datastore or any other error upon indexing one item from the repository that > is outside the scope of the indexer, it currently halts the indexing (lane). > Thus one item (that maybe isn't important to the users at all) can block the > indexing of other, new content (that might be important to users), and it > always requires manual intervention (which is also not easy and requires oak > experts). > Instead, the item could be remembered in a known issue list, proper warnings > given, and indexing continue. Maintenance operations should be available to > come back to reindex these once the issue is fixed, or the indexer could > automatically retry after some time. This would allow normal user activity to > go on, and solving the problem (if it's isolated to some binaries) can be > deferred. > I think the line should probably be drawn for binary properties. Not sure if > other JCR property types could trigger a similar issue, and if a failure in > them might actually warrant a halt, as it could lead to an "incorrect" index, > if these properties are important. But maybe the line is simply a try & catch > around "full text extraction". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-5519) Skip problematic binaries instead of blocking indexing
[ https://issues.apache.org/jira/browse/OAK-5519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Saar updated OAK-5519: Description: If a text extraction is blocked (weird PDF) or a blob cannot be found in the datastore or any other error upon indexing one item from the repository that is outside the scope of the indexer, it currently halts the indexing (lane). Thus one item (that maybe isn't important to the users at all) can block the indexing of other, new content (that might be important to users), and it always requires manual intervention (which is also not easy and requires oak experts). Instead, the item could be remembered in a known issue list, proper warnings given, and indexing continue. Maintenance operations should be available to come back to reindex these once the issue is fixed, or the indexer could automatically retry after some time. This would allow normal user activity to go on, and solving the problem (if it's isolated to some binaries) can be deferred. I think the line should probably be drawn for binary properties. Not sure if other JCR property types could trigger a similar issue, and if a failure in them might actually warrant a halt, as it could lead to an "incorrect" index, if these properties are important. But maybe the line is simply a try & catch around "full text extraction". was: If a text extraction is broken (weird PDF) or a blob cannot be found in the datastore or any other error upon indexing one item from the repository that is outside the scope of the indexer, it currently halts the complete indexing (lane). Thus one broken item (that maybe isn't important to the users at all) can block the indexing of other, new content (that might be important to users), and it always requires manual intervention to fix (which is also not easy and requires oak experts). Instead, the item could be remembered in a known issue list, proper warnings given, and indexing continue. Maintenance operations should be available to come back to reindex these once the issue is fixed, or the indexer could automatically retry after some time. This would allow normal user activity to go on, and solving the problem (if it's isolated to some binaries) can be deferred. I think the line should probably be drawn for binary properties. Not sure if other JCR property types could trigger a similar issue, and if a failure in them might actually warrant a halt, as it could lead to an "incorrect" index, if these properties are important. But maybe the line is simply a try & catch around "full text extraction". > Skip problematic binaries instead of blocking indexing > -- > > Key: OAK-5519 > URL: https://issues.apache.org/jira/browse/OAK-5519 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Alexander Klimetschek > > If a text extraction is blocked (weird PDF) or a blob cannot be found in the > datastore or any other error upon indexing one item from the repository that > is outside the scope of the indexer, it currently halts the indexing (lane). > Thus one item (that maybe isn't important to the users at all) can block the > indexing of other, new content (that might be important to users), and it > always requires manual intervention (which is also not easy and requires oak > experts). > Instead, the item could be remembered in a known issue list, proper warnings > given, and indexing continue. Maintenance operations should be available to > come back to reindex these once the issue is fixed, or the indexer could > automatically retry after some time. This would allow normal user activity to > go on, and solving the problem (if it's isolated to some binaries) can be > deferred. > I think the line should probably be drawn for binary properties. Not sure if > other JCR property types could trigger a similar issue, and if a failure in > them might actually warrant a halt, as it could lead to an "incorrect" index, > if these properties are important. But maybe the line is simply a try & catch > around "full text extraction". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-5400) Test failure: ...stats.ClockTest.testClockDrift
[ https://issues.apache.org/jira/browse/OAK-5400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Saar updated OAK-5400: Assignee: Michael Dürig > Test failure: ...stats.ClockTest.testClockDrift > --- > > Key: OAK-5400 > URL: https://issues.apache.org/jira/browse/OAK-5400 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Assignee: Michael Dürig > Labels: test-failure > Fix For: 1.6 > > > 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 #1351 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.7 (latest),nsfixtures=DOCUMENT_NS,profile=unittesting > #1351|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=DOCUMENT_NS,profile=unittesting/1351/] > [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/1351/console] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-5388) Test failure: persistentCache.BroadcastTest.broadcastTCP
[ https://issues.apache.org/jira/browse/OAK-5388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Saar updated OAK-5388: Assignee: Thomas Mueller > Test failure: persistentCache.BroadcastTest.broadcastTCP > > > Key: OAK-5388 > URL: https://issues.apache.org/jira/browse/OAK-5388 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Assignee: Thomas Mueller > Labels: test-failure > Fix For: 1.6 > > > 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_NS,profile=unittesting #1347 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.8 (latest),nsfixtures=DOCUMENT_NS,profile=unittesting > #1347|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=DOCUMENT_NS,profile=unittesting/1347/] > [console > log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=DOCUMENT_NS,profile=unittesting/1347/console] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-5356) Test failures: BrokenNetworkIT and CompactionAndCleanupIT
[ https://issues.apache.org/jira/browse/OAK-5356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Saar updated OAK-5356: Assignee: Michael Dürig > Test failures: BrokenNetworkIT and CompactionAndCleanupIT > - > > Key: OAK-5356 > URL: https://issues.apache.org/jira/browse/OAK-5356 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration, segment-tar >Affects Versions: 1.5.16 >Reporter: Hudson >Assignee: Michael Dürig > Labels: test-failure > Fix For: 1.6 > > > 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=integrationTesting #1338 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.7 (latest),nsfixtures=DOCUMENT_NS,profile=integrationTesting > #1338|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=DOCUMENT_NS,profile=integrationTesting/1338/] > [console > log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=DOCUMENT_NS,profile=integrationTesting/1338/console] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-5427) Test Failure: org.apache.jackrabbit.oak.segment.CompactionAndCleanupIT.compactionNoBinaryClone
[ https://issues.apache.org/jira/browse/OAK-5427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Saar updated OAK-5427: Assignee: Michael Dürig > Test Failure: > org.apache.jackrabbit.oak.segment.CompactionAndCleanupIT.compactionNoBinaryClone > -- > > Key: OAK-5427 > URL: https://issues.apache.org/jira/browse/OAK-5427 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration, segment-tar >Reporter: Hudson >Assignee: Michael Dürig > Labels: test-failure > Fix For: 1.6 > > > 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_NS,profile=integrationTesting #1360 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.8 (latest),nsfixtures=DOCUMENT_NS,profile=integrationTesting > #1360|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=DOCUMENT_NS,profile=integrationTesting/1360/] > [console > log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=DOCUMENT_NS,profile=integrationTesting/1360/console] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-5408) Test failure: segment.standby.BrokenNetworkTest.testProxyFlippedStartByte
[ https://issues.apache.org/jira/browse/OAK-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Saar updated OAK-5408: Assignee: Francesco Mari > Test failure: segment.standby.BrokenNetworkTest.testProxyFlippedStartByte > - > > Key: OAK-5408 > URL: https://issues.apache.org/jira/browse/OAK-5408 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration, tarmk-standby >Reporter: Hudson >Assignee: Francesco Mari > Labels: test-failure > Fix For: 1.6 > > > 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=unittesting #1355 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.7 (latest),nsfixtures=SEGMENT_MK,profile=unittesting > #1355|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=SEGMENT_MK,profile=unittesting/1355/] > [console > log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=SEGMENT_MK,profile=unittesting/1355/console] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-5387) Test failure: ConcurrentQueryAndUpdateIT.cacheUpdate[RDBFixture: RDB-H2(file)]
[ https://issues.apache.org/jira/browse/OAK-5387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Saar updated OAK-5387: Assignee: Julian Reschke > Test failure: ConcurrentQueryAndUpdateIT.cacheUpdate[RDBFixture: RDB-H2(file)] > -- > > Key: OAK-5387 > URL: https://issues.apache.org/jira/browse/OAK-5387 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Assignee: Julian Reschke > Labels: test-failure > Fix For: 1.6 > > > 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 #1345 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.8 (latest),nsfixtures=DOCUMENT_RDB,profile=integrationTesting > #1345|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=DOCUMENT_RDB,profile=integrationTesting/1345/] > [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/1345/console] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-5369) Lucene Property Index: Syntax Error, cannot parse
[
https://issues.apache.org/jira/browse/OAK-5369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Saar updated OAK-5369:
Fix Version/s: (was: 1.4.13)
(was: 1.5.18)
(was: 1.6)
1.8
> Lucene Property Index: Syntax Error, cannot parse
> -
>
> Key: OAK-5369
> URL: https://issues.apache.org/jira/browse/OAK-5369
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
> Fix For: 1.8
>
>
> The following query throws an exception in Apache Lucene:
> {noformat}
> /jcr:root//*[jcr:contains(., 'hello -- world')]
> 22.12.2016 16:42:54.511 *WARN* [qtp1944702753-3846]
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex query via
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex@1c0006db
> failed.
> java.lang.RuntimeException: INVALID_SYNTAX_CANNOT_PARSE: Syntax Error, cannot
> parse hello -- world:
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.tokenToQuery(LucenePropertyIndex.java:1450)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.tokenToQuery(LucenePropertyIndex.java:1418)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.access$900(LucenePropertyIndex.java:180)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$3.visitTerm(LucenePropertyIndex.java:1353)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$3.visit(LucenePropertyIndex.java:1307)
> at
> org.apache.jackrabbit.oak.query.fulltext.FullTextContains.accept(FullTextContains.java:63)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.getFullTextQuery(LucenePropertyIndex.java:1303)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.getLuceneRequest(LucenePropertyIndex.java:791)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.access$300(LucenePropertyIndex.java:180)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$1.loadDocs(LucenePropertyIndex.java:375)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$1.computeNext(LucenePropertyIndex.java:317)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$1.computeNext(LucenePropertyIndex.java:306)
> at
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
> at
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$LucenePathCursor$1.hasNext(LucenePropertyIndex.java:1571)
> at com.google.common.collect.Iterators$7.computeNext(Iterators.java:645)
> at
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
> at
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
> at
> org.apache.jackrabbit.oak.spi.query.Cursors$PathCursor.hasNext(Cursors.java:205)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$LucenePathCursor.hasNext(LucenePropertyIndex.java:1595)
> at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.next(SelectorImpl.java:420)
> at
> org.apache.jackrabbit.oak.query.QueryImpl$RowIterator.fetchNext(QueryImpl.java:828)
> at
> org.apache.jackrabbit.oak.query.QueryImpl$RowIterator.hasNext(QueryImpl.java:853)
> at
> org.apache.jackrabbit.oak.jcr.query.QueryResultImpl$1.fetch(QueryResultImpl.java:98)
> at
> org.apache.jackrabbit.oak.jcr.query.QueryResultImpl$1.(QueryResultImpl.java:94)
> at
> org.apache.jackrabbit.oak.jcr.query.QueryResultImpl.getRows(QueryResultImpl.java:78)
> Caused by:
> org.apache.lucene.queryparser.flexible.standard.parser.ParseException: Syntax
> Error, cannot parse hello -- world:
> at
> org.apache.lucene.queryparser.flexible.standard.parser.StandardSyntaxParser.generateParseException(StandardSyntaxParser.java:1054)
> at
> org.apache.lucene.queryparser.flexible.standard.parser.StandardSyntaxParser.jj_consume_token(StandardSyntaxParser.java:936)
> at
> org.apache.lucene.queryparser.flexible.standard.parser.StandardSyntaxParser.Clause(StandardSyntaxParser.java:486)
> at
> org.apache.lucene.queryparser.flexible.standard.parser.StandardSyntaxParser.ModClause(StandardSyntaxParser.java:303)
> at
> org.apache.lucene.queryparser.flexible.standard.parser.StandardSyntaxParser.ConjQuery(StandardSyntaxParser.java:234)
> at
> org.apache.lucene.queryparser.flexible.standard.parser.StandardSyntaxParser.DisjQuery(StandardSyntaxPa
[jira] [Updated] (OAK-5229) Using Node.setPrimaryType() should fail if non-matching childnodes
[
https://issues.apache.org/jira/browse/OAK-5229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Saar updated OAK-5229:
Fix Version/s: (was: 1.5.17)
1.5.18
> Using Node.setPrimaryType() should fail if non-matching childnodes
> --
>
> Key: OAK-5229
> URL: https://issues.apache.org/jira/browse/OAK-5229
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.5.14
>Reporter: Tobias Bocanegra
>Priority: Critical
> Fix For: 1.5.18
>
>
> 1. Assume the following:
> {noformat}
> /testNode [nt:unstructured]
> /unstructured_child [nt:unstructured]
> {noformat}
> 2. setting "/testNode".setPrimaryType("nt:folder")
> 3. save the session.
> Altering the primary type works, thus leaving the repository in an
> inconsistent state.
> Interestingly, subsequent calls to
> "/testNiode/unstructured_child".setProperty() will fail:
> {noformat}
> javax.jcr.nodetype.ConstraintViolationException: OakConstraint0001:
> /test_node[[nt:folder]]: No matching definition found for child node
> unstructured_child with effective type [nt:unstructured]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5239) Test failure: ExternalPrivateStoreIT. testSyncUpdatedBinaryProperty()
[ https://issues.apache.org/jira/browse/OAK-5239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Saar updated OAK-5239: Assignee: Francesco Mari > Test failure: ExternalPrivateStoreIT. testSyncUpdatedBinaryProperty() > - > > Key: OAK-5239 > URL: https://issues.apache.org/jira/browse/OAK-5239 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration, segment-tar >Affects Versions: 1.5.15 >Reporter: Hudson >Assignee: Francesco Mari > Fix For: 1.5.17 > > > Jenkins CI failure: > https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/ > The build Apache Jackrabbit Oak matrix/jdk=JDK 1.7 > (latest),nsfixtures=DOCUMENT_RDB,profile=integrationTesting #1320 has failed. > First failed run: [Apache Jackrabbit Oak matrix/jdk=JDK 1.7 > (latest),nsfixtures=DOCUMENT_RDB,profile=integrationTesting > #1320|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/jdk=JDK%201.7%20(latest),nsfixtures=DOCUMENT_RDB,profile=integrationTesting/1320/] > [console > log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/jdk=JDK%201.7%20(latest),nsfixtures=DOCUMENT_RDB,profile=integrationTesting/1320/console] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-5335) Clarify the various directories and their usages in SegmentNodeStoreService
[
https://issues.apache.org/jira/browse/OAK-5335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Saar updated OAK-5335:
Fix Version/s: 1.5.18
> Clarify the various directories and their usages in SegmentNodeStoreService
> ---
>
> Key: OAK-5335
> URL: https://issues.apache.org/jira/browse/OAK-5335
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Andrei Dulceanu
> Labels: technical_debt
> Fix For: 1.5.18, 1.6
>
> Attachments: OAK-5335-01.patch
>
>
> In {{SegmentNodeStoreService}} there is {{repository.home}}, {{DIRECTORY}},
> {{getRootDirectory()}}, {{getDirectory()}} and {{getBaseDirectory()}} mostly
> without documentation about their intention. I think we should clarify,
> document and consolidate them.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3960) Boosted field don't work if parent nodes are covered in aggregate definition
[
https://issues.apache.org/jira/browse/OAK-3960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Saar updated OAK-3960:
Fix Version/s: 1.5.17
> Boosted field don't work if parent nodes are covered in aggregate definition
>
>
> Key: OAK-3960
> URL: https://issues.apache.org/jira/browse/OAK-3960
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
> Labels: lucene
> Fix For: 1.5.17, 1.6
>
> Attachments: OAK-3960.patch
>
>
> With index def of the form:
> {noformat}
> +/indexName/indexRules/nodeType1/properties/prop0
> -name=subChild/indexedProp
> -nodeScopeIndex=true
> -boost=2.0
> +indexName/aggregates/nodeType1/include0
> -path=subChild
> -relativeNode=true
> {noformat}
> A query like {{//element(*, nodeType1)\[jcr:contains(subChild, 'bar')]}}
> should rank nodes with {{subChild/\@indexedProp=bar}} above other nodes with
> any prop {{=bar}} under subChild.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-5318) Update Oak trunk to Jackrabbit 2.13.7
[ https://issues.apache.org/jira/browse/OAK-5318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15761561#comment-15761561 ] Alexander Saar commented on OAK-5318: - made this a blocker so we don't forget about it > Update Oak trunk to Jackrabbit 2.13.7 > - > > Key: OAK-5318 > URL: https://issues.apache.org/jira/browse/OAK-5318 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Blocker > Fix For: 1.5.17, 1.6 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-5318) Update Oak trunk to Jackrabbit 2.13.7
[ https://issues.apache.org/jira/browse/OAK-5318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Saar updated OAK-5318: Priority: Blocker (was: Trivial) > Update Oak trunk to Jackrabbit 2.13.7 > - > > Key: OAK-5318 > URL: https://issues.apache.org/jira/browse/OAK-5318 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Blocker > Fix For: 1.5.17, 1.6 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-5335) Clarify the various directories and there usages in SegmentNodeStoreService
[
https://issues.apache.org/jira/browse/OAK-5335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Saar updated OAK-5335:
Issue Type: Task (was: Improvement)
> Clarify the various directories and there usages in SegmentNodeStoreService
> ---
>
> Key: OAK-5335
> URL: https://issues.apache.org/jira/browse/OAK-5335
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Andrei Dulceanu
> Labels: technical_debt
> Fix For: 1.6
>
>
> In {{SegmentNodeStoreService}} there is {{repository.home}}, {{DIRECTORY}},
> {{getRootDirectory()}}, {{getDirectory()}} and {{getBaseDirectory()}} mostly
> without documentation about their intention. I think we should clarify,
> document and consolidate them.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4453) Cleanup blob gc related tests
[ https://issues.apache.org/jira/browse/OAK-4453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Saar updated OAK-4453: Issue Type: Task (was: Improvement) > Cleanup blob gc related tests > - > > Key: OAK-4453 > URL: https://issues.apache.org/jira/browse/OAK-4453 > Project: Jackrabbit Oak > Issue Type: Task > Components: blob >Reporter: Amit Jain >Assignee: Amit Jain >Priority: Minor > Labels: technical_debt > Fix For: 1.6 > > > The various blob gc related tests have a fair bit of duplication. These > should be de duplicated and cleaned up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4460) Bogus lock token
[ https://issues.apache.org/jira/browse/OAK-4460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Saar updated OAK-4460: Fix Version/s: 1.8 > Bogus lock token > > > Key: OAK-4460 > URL: https://issues.apache.org/jira/browse/OAK-4460 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: jcr >Reporter: angela >Priority: Blocker > Fix For: 1.8 > > > The current implementation uses the node's path a lock token which is IMHO > totally bogus and defeats the purpose as it means that every single session > can easily become lock-holder by just adding the nodes path as lock token to > the session. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4726) Add Metrics coverage to the Lucene Indexer
[ https://issues.apache.org/jira/browse/OAK-4726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Saar updated OAK-4726: Fix Version/s: 1.5.17 > Add Metrics coverage to the Lucene Indexer > -- > > Key: OAK-4726 > URL: https://issues.apache.org/jira/browse/OAK-4726 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Affects Versions: 1.5.8 >Reporter: Ian Boston >Assignee: Chetan Mehrotra > Fix For: 1.6, 1.5.17 > > > Although there are some stats surrounding the Lucene indexing processes it > would be useful to have metrics style stats available. > Looking at the code, the implementations IndexWriter look like the right > place to add the metrics. These could be global aggregate metrics, ie one set > of metrics covering all IndexWriter implementations, or there could be > individual metrics for each Lucene index definition. The latter would be more > useful as it will allow detailed stats on individual metrics. > These metrics will only give information on the writer operations, and not > any Tokenizing operations. > Patch in the form of a pull request will flow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4809) JMX Stats for NRT Indexing
[ https://issues.apache.org/jira/browse/OAK-4809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Saar updated OAK-4809: Fix Version/s: 1.5.17 > JMX Stats for NRT Indexing > -- > > Key: OAK-4809 > URL: https://issues.apache.org/jira/browse/OAK-4809 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: 1.6, 1.5.17 > > > The hybrid index feature currently exposes some stats via metrics. It would > be good to expose some more stats around > # How many times NRT index got updated in refreshed > # Current generation of index - NRT Index gets switched to new gen after each > async index cycle and old gen are deleted. So some stats around that > # Expose NRT Index size as part of LuceneIndexStats MBean -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4960) Review the support for wildcards in bundling pattern
[ https://issues.apache.org/jira/browse/OAK-4960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Saar updated OAK-4960: Fix Version/s: 1.5.17 > Review the support for wildcards in bundling pattern > > > Key: OAK-4960 > URL: https://issues.apache.org/jira/browse/OAK-4960 > Project: Jackrabbit Oak > Issue Type: Task > Components: documentmk >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Labels: bundling > Fix For: 1.6, 1.5.17 > > > Bundling pattern currently supports wild card pattern. This makes it powerful > but at same time can cause issue if it misconfigured. > We should review this aspect before 1.6 release to determine if this feature > needs to be exposed or not. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4959) Review the security aspect of bundling configuration
[
https://issues.apache.org/jira/browse/OAK-4959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Saar updated OAK-4959:
Fix Version/s: 1.5.17
> Review the security aspect of bundling configuration
>
>
> Key: OAK-4959
> URL: https://issues.apache.org/jira/browse/OAK-4959
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: documentmk
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Labels: bundling
> Fix For: 1.6, 1.5.17
>
>
> The config for node bundling feature in DocumentNodeStore is currently stored
> under {{jcr:system/rep:documentStore/bundlor}}. This task is meant to
> * Review the access control aspect - This config should be only updatetable
> by system admin
> * Config under here should be writeable via JCR api
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5078) Improper handling of relative paths in OakFileDataStore#getAllIdentifiers
[
https://issues.apache.org/jira/browse/OAK-5078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Saar updated OAK-5078:
Issue Type: Improvement (was: Bug)
> Improper handling of relative paths in OakFileDataStore#getAllIdentifiers
> -
>
> Key: OAK-5078
> URL: https://issues.apache.org/jira/browse/OAK-5078
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: blob
>Reporter: Amit Jain
>Assignee: Amit Jain
> Fix For: 1.6, 1.5.13
>
>
> OakFileDataStore#getAllIdentifiers normalizes paths using the
> FileNameUtils.normalizeNoEndSeparator method directly. But this will fail for
> paths defined as {{../datastore}} for example.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4857) Support space chars common in CJK inside node names
[
https://issues.apache.org/jira/browse/OAK-4857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Saar updated OAK-4857:
Assignee: Julian Reschke (was: Marcel Reutegger)
> Support space chars common in CJK inside node names
> ---
>
> Key: OAK-4857
> URL: https://issues.apache.org/jira/browse/OAK-4857
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.4.7, 1.5.10
>Reporter: Alexander Klimetschek
>Assignee: Julian Reschke
> Fix For: 1.8
>
> Attachments: OAK-4857-tests.patch
>
>
> Oak (like Jackrabbit) does not allow spaces commonly used in CJK like
> {{u3000}} (ideographic space) or {{u00A0}} (no-break space) _inside_ a node
> name, while allowing some of them (the non breaking spaces) at the _beginning
> or end_.
> They should be supported for better globalization readiness, and filesystems
> allow them, making common filesystem to JCR mappings unnecessarily hard.
> Escaping would be an option for applications, but there is currently no
> utility method for it
> ([Text.escapeIllegalJcrChars|https://jackrabbit.apache.org/api/2.8/org/apache/jackrabbit/util/Text.html#escapeIllegalJcrChars(java.lang.String)]
> will not escape these spaces), nor is it documented for applications how to
> do so.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4857) Support space chars common in CJK inside node names
[
https://issues.apache.org/jira/browse/OAK-4857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Saar updated OAK-4857:
Fix Version/s: (was: 1.6)
1.8
> Support space chars common in CJK inside node names
> ---
>
> Key: OAK-4857
> URL: https://issues.apache.org/jira/browse/OAK-4857
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.4.7, 1.5.10
>Reporter: Alexander Klimetschek
>Assignee: Marcel Reutegger
> Fix For: 1.8
>
> Attachments: OAK-4857-tests.patch
>
>
> Oak (like Jackrabbit) does not allow spaces commonly used in CJK like
> {{u3000}} (ideographic space) or {{u00A0}} (no-break space) _inside_ a node
> name, while allowing some of them (the non breaking spaces) at the _beginning
> or end_.
> They should be supported for better globalization readiness, and filesystems
> allow them, making common filesystem to JCR mappings unnecessarily hard.
> Escaping would be an option for applications, but there is currently no
> utility method for it
> ([Text.escapeIllegalJcrChars|https://jackrabbit.apache.org/api/2.8/org/apache/jackrabbit/util/Text.html#escapeIllegalJcrChars(java.lang.String)]
> will not escape these spaces), nor is it documented for applications how to
> do so.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5028) Remove DocumentStore.update()
[ https://issues.apache.org/jira/browse/OAK-5028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Saar updated OAK-5028: Fix Version/s: 1.5.14 > Remove DocumentStore.update() > - > > Key: OAK-5028 > URL: https://issues.apache.org/jira/browse/OAK-5028 > Project: Jackrabbit Oak > Issue Type: Task > Components: core, documentmk, mongomk, rdbmk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Fix For: 1.6, 1.5.14 > > > OAK-3018 removed the single production usage of DocumentStore.update(). I > propose we remove the method to reduce maintenance. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4069) Use read concern majority when connected to a replica set
[
https://issues.apache.org/jira/browse/OAK-4069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Saar updated OAK-4069:
Fix Version/s: 1.5.14
> Use read concern majority when connected to a replica set
> -
>
> Key: OAK-4069
> URL: https://issues.apache.org/jira/browse/OAK-4069
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: mongomk
>Reporter: Tomek Rękawek
>Assignee: Marcel Reutegger
> Labels: resilience
> Fix For: 1.6, 1.5.14
>
>
> Mongo 3.2 introduces new query option: {{readConcern}}. It allows to read
> only these changes that have been already committed to the majority of
> secondary instances.
> It prevents stale reads - a situation in which a change has been committed on
> the primary (and read from it), but due to the network partition a new
> primary is elected and the change is rolled back.
> We should use this new option (together with {{w:majority}} implemented in
> OAK-3559) when running Oak on MongoDB replica set.
> References:
> * [Jepsen: MongoDB stale
> reads|https://aphyr.com/posts/322-jepsen-mongodb-stale-reads]
> * [MongoDB documentation: Read Concern
> in|https://docs.mongodb.org/manual/reference/read-concern/]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5036) switch o.a.j.oak.jcr.observation.filter version to 1.0.0 before oak 1.6 release
[ https://issues.apache.org/jira/browse/OAK-5036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Saar updated OAK-5036: Fix Version/s: 1.5.14 > switch o.a.j.oak.jcr.observation.filter version to 1.0.0 before oak 1.6 > release > --- > > Key: OAK-5036 > URL: https://issues.apache.org/jira/browse/OAK-5036 > Project: Jackrabbit Oak > Issue Type: Task > Components: jcr >Reporter: Stefan Egli >Assignee: Stefan Egli >Priority: Blocker > Fix For: 1.6, 1.5.14 > > > OAK-5013 introduces an extension mechanism to expose Oak specific observation > filtering features. > Currently the corresponding package is set to version 0.0.0 with the idea to > not dirty the version range unnecessarily before oak 1.6. But before > releasing oak 1.6 this should be set to 1.0.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4940) Consider collecting grand-parent changes in ChangeSet
[ https://issues.apache.org/jira/browse/OAK-4940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Saar updated OAK-4940: Fix Version/s: 1.6 > Consider collecting grand-parent changes in ChangeSet > - > > Key: OAK-4940 > URL: https://issues.apache.org/jira/browse/OAK-4940 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Affects Versions: 1.5.12 >Reporter: Stefan Egli >Assignee: Stefan Egli > Fix For: 1.6, 1.5.14 > > > At the moment the ChangeSet, which is populated by ChangeCollectorProvider (a > Validator) during a commit, collects changed property names, as well as node > name, node type and path of the parent (whereas _parent_ for a property > change is its node, while for a node change is actually its parent). > For improvements such as SLING-6163 it might be valuable to collect > grand-parent changes (node name, node type and perhaps path) too. We could > extend the ChangeSet with additional, explicit grand-parent sets (ie we > should not mix them with the parent changes as that would lessen filtering > rate) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3976) journal should support large(r) entries
[
https://issues.apache.org/jira/browse/OAK-3976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Saar updated OAK-3976:
Fix Version/s: 1.6
> journal should support large(r) entries
> ---
>
> Key: OAK-3976
> URL: https://issues.apache.org/jira/browse/OAK-3976
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: documentmk
>Affects Versions: 1.3.14
>Reporter: Stefan Egli
> Fix For: 1.6, 1.5.15
>
>
> Journal entries are created in the background write. Normally this happens
> every second. If for some reason there is a large delay between two
> background writes, the number of pending changes can also accumulate. Which
> can result in (arbitrary) large single journal entries (ie with large {{_c}}
> property).
> This can cause multiple problems down the road:
> * journal gc at this point loads 450 entries - and if some are large this can
> result in a very large memory consumption during gc (which can cause severe
> stability problems for the VM, if not OOM etc). This should be fixed with
> OAK-3001 (where we only get the id, thus do not care how big {{_c}} is)
> * before OAK-3001 is done (which is currently scheduled after 1.4) what we
> can do is reduce the delete batch size (OAK-3975)
> * background reads however also read the journal entries and even if
> OAK-3001/OAK-3975 are implemented the background read can still cause large
> memory consumption. So we need to improve this one way or another.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3976) journal should support large(r) entries
[
https://issues.apache.org/jira/browse/OAK-3976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Saar updated OAK-3976:
Fix Version/s: (was: 1.6)
1.5.15
> journal should support large(r) entries
> ---
>
> Key: OAK-3976
> URL: https://issues.apache.org/jira/browse/OAK-3976
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: documentmk
>Affects Versions: 1.3.14
>Reporter: Stefan Egli
> Fix For: 1.6, 1.5.15
>
>
> Journal entries are created in the background write. Normally this happens
> every second. If for some reason there is a large delay between two
> background writes, the number of pending changes can also accumulate. Which
> can result in (arbitrary) large single journal entries (ie with large {{_c}}
> property).
> This can cause multiple problems down the road:
> * journal gc at this point loads 450 entries - and if some are large this can
> result in a very large memory consumption during gc (which can cause severe
> stability problems for the VM, if not OOM etc). This should be fixed with
> OAK-3001 (where we only get the id, thus do not care how big {{_c}} is)
> * before OAK-3001 is done (which is currently scheduled after 1.4) what we
> can do is reduce the delete batch size (OAK-3975)
> * background reads however also read the journal entries and even if
> OAK-3001/OAK-3975 are implemented the background read can still cause large
> memory consumption. So we need to improve this one way or another.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4940) Consider collecting grand-parent changes in ChangeSet
[ https://issues.apache.org/jira/browse/OAK-4940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Saar updated OAK-4940: Fix Version/s: (was: 1.6) 1.5.14 > Consider collecting grand-parent changes in ChangeSet > - > > Key: OAK-4940 > URL: https://issues.apache.org/jira/browse/OAK-4940 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Affects Versions: 1.5.12 >Reporter: Stefan Egli >Assignee: Stefan Egli > Fix For: 1.5.14 > > > At the moment the ChangeSet, which is populated by ChangeCollectorProvider (a > Validator) during a commit, collects changed property names, as well as node > name, node type and path of the parent (whereas _parent_ for a property > change is its node, while for a node change is actually its parent). > For improvements such as SLING-6163 it might be valuable to collect > grand-parent changes (node name, node type and perhaps path) too. We could > extend the ChangeSet with additional, explicit grand-parent sets (ie we > should not mix them with the parent changes as that would lessen filtering > rate) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-1327) Cleanup NodeStore and MK implementations
[ https://issues.apache.org/jira/browse/OAK-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Saar updated OAK-1327: Fix Version/s: (was: 1.6) 1.8 > Cleanup NodeStore and MK implementations > > > Key: OAK-1327 > URL: https://issues.apache.org/jira/browse/OAK-1327 > Project: Jackrabbit Oak > Issue Type: Wish > Components: core, documentmk >Reporter: angela > Labels: modularization, technical_debt > Fix For: 1.8 > > Attachments: OAK-1327.patch > > > as discussed during the oak-call today, i would like to cleanup the code base > before we officially release OAK. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-1962) Fix and Improve Locking
[ https://issues.apache.org/jira/browse/OAK-1962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Saar updated OAK-1962: Fix Version/s: (was: 1.6) 1.8 > Fix and Improve Locking > --- > > Key: OAK-1962 > URL: https://issues.apache.org/jira/browse/OAK-1962 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, jcr >Affects Versions: 1.0 >Reporter: angela > Labels: technical_debt > Fix For: 1.8 > > > as discussed during our biweekly planning session, we are having the > following locking related use case in our product: > a page (which is an aggregation of nodes and properties) must be freezed > (prevented from being edited/modified/deleted) during the period of a > dedicated review (which in our case is triggered by a workflow) before the > page then is either published or reopened for further changes. > for this feature locking would be a perfect match but with the current > implementation in oak it's not possible to remove the lock token from a > given session and make sure it's no longer recognizes as lock owner; in > particular with the simple-locking feature which we introduced in order to > cope with the situation that in our product sessions are living just for the > time of a single request. > is was therefore thinking about ways to address this, keeping the > simple-locking requirement in mind while at the same time improving > compliance with the JCR specification. my suggestion as follows: > - use a dedicated hidden and write protected location the repository to store > the lock information independent of the protected properties defined by > mix:lockable which are just for information purpose (that would be the > replacement for the lock-related file we had in jackrabbit 2.x) > - format: simple lookup consisting of userId + associated lock tokens > - in case of simple locking LockManager#getLockTokens would make use of that > map even if the lock tokens have NOT been explicitly added to the Session > either upon LockManager#lock or LockManager#addLockToken > - in the default (non-simple case) LockManager#getLockTokens would work as > specified and the lookup would only be used for maintaining and enforcing the > lock related information) > - LockManager#removeLockToken removes the token from the lookup thus > effectively revoking the lock ownership from the given Session and thus > preventing it from performing further editing... even in the simple-locking > case > - LockManager#addLockToken results in a modification of the lookup table as > well depending on the API contract (i.e. verifying if the lock token would be > shared... i don't remember exactly if that's accepted by the specification) > - LockManager#isLockOwner no longer needs to perform a cheap hack comparing > the jcr:lockOwner property with the sessions userId but could really enforce > ownership based on the internal lock information stored in the repository in > which case getLockTokens would really reflect the ownership for open-scoped > locks; furthermore the 'jcr:lockOwner' information could be to what is > specified by the API consumer upon LockManager#lock as it is no longer used > for enforcing the locks. > in addition: > - we could generated proper lock tokens instead of just using the node id > and again keep those in a hidden (or otherwise protected) location in the > system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-5042) Improve caching of segments
[
https://issues.apache.org/jira/browse/OAK-5042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Saar updated OAK-5042:
Fix Version/s: (was: 1.5.14)
(was: 1.6)
1.8
> Improve caching of segments
> ---
>
> Key: OAK-5042
> URL: https://issues.apache.org/jira/browse/OAK-5042
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: performance
> Fix For: 1.8
>
> Attachments: OAK-5042.png
>
>
> Various aspects of how Segment Tar caches segments could possibly improved.
> The current cache is a result of replacing the former ad-hoc cache with a
> proper one in OAK-3055. While the former was prone to contention under
> concurrent load the current cache is too oblivious about reads: read accesses
> are always served through {{SegmentId.segment}} and never actually hit the
> cache. This results in frequently accessed segments not to be seen as such by
> the cache and potentially being prematurely evicted.
> Possibly approaches to address this problem include:
> * Reinstantiating the cache we had pre OAK-3055 but making in fully
> concurrent.
> * Convey the information about read accesses to the current cache.
> * In either of the above cases avoid bulk segments from being placed into the
> cache.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4732) (Slightly) prioritise reads over writes
[
https://issues.apache.org/jira/browse/OAK-4732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Saar updated OAK-4732:
Fix Version/s: (was: 1.6)
1.8
> (Slightly) prioritise reads over writes
>
>
> Key: OAK-4732
> URL: https://issues.apache.org/jira/browse/OAK-4732
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: Performance
> Fix For: 1.8
>
>
> When fetching the current root from the {{SegmentNodeStore}} an older
> revision will be returned when a commit is being processed concurrently. I
> think it would make sense to wait for a short time in this case increasing
> the chance of returning an up to date state. The idea is that this would
> lower the rebasing work that need to be done later on should the returned
> root be used for further modifications.
> An interesting value for the wait time is to use the median (or more general
> a percentile) of the commit time of the last say 1000 commits. This would
> mean that (for the median) we have a 50% chance of getting up to date date.
> For a 90% percentile we would have longer wait times but then a 90% chance of
> getting up to date date.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3919) Properly manage APIs / SPIs intended for public consumption
[
https://issues.apache.org/jira/browse/OAK-3919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Saar updated OAK-3919:
Fix Version/s: (was: 1.6)
1.8
> Properly manage APIs / SPIs intended for public consumption
> ---
>
> Key: OAK-3919
> URL: https://issues.apache.org/jira/browse/OAK-3919
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Michael Dürig
> Labels: modularization, technical_debt
> Fix For: 1.8
>
>
> This is a follow up to OAK-3842, which removed package export declarations
> for all packages that we either do not want to be used outside of Oak or that
> are not stable enough yet.
> This issue is to identify those APIs and SPIs of Oak that we actually *want*
> to export and to refactor those such we *can* export them.
> Candidates that are currently used from upstream projects I know of are:
> {code}
> org.apache.jackrabbit.oak.plugins.observation
> org.apache.jackrabbit.oak.spi.commit
> org.apache.jackrabbit.oak.spi.state
> org.apache.jackrabbit.oak.commons
> org.apache.jackrabbit.oak.plugins.index.lucene
> {code}
> I suggest to create subtask for those we want to go forward with.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4712) Publish S3DataStore stats in JMX MBean
[ https://issues.apache.org/jira/browse/OAK-4712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15462453#comment-15462453 ] Alexander Saar commented on OAK-4712: - bq. it occurred to me that it shouldn't be Oak's responsibility to figure out what the user making the request may have meant, if they were to provide e.g. "content/dam/pic.jpg". In my way of thinking, only the full path to the node containing the binary property makes sense at the Oak level fully agree with this. we should not try to add any magic but expect the full path to the nt:resource node holding the binary property and expect applications to pass this in depending on their content model requiements > Publish S3DataStore stats in JMX MBean > -- > > Key: OAK-4712 > URL: https://issues.apache.org/jira/browse/OAK-4712 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: blob >Reporter: Matt Ryan > Attachments: OAK-4712.2.diff, OAK-4712.3.diff > > > This feature is to publish statistics about the S3DataStore via a JMX MBean. > There are two statistics suggested: > * Indicate the number of files actively being synchronized from the local > cache into S3 > * Given a path to a local file, indicate whether synchronization of file into > S3 has completed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
