[jira] [Commented] (OAK-5742) more logging when ChangeProcessor.stopAndWait fails
[
https://issues.apache.org/jira/browse/OAK-5742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15877634#comment-15877634
]
Marcel Reutegger commented on OAK-5742:
---
Looks useful and low risk. +1
> more logging when ChangeProcessor.stopAndWait fails
> ---
>
> Key: OAK-5742
> URL: https://issues.apache.org/jira/browse/OAK-5742
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Affects Versions: 1.6.0
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Labels: candidate_oak_1_6
> Fix For: 1.7.0, 1.8
>
>
> When ChangeProcessor.stopAndWait fails (returns false) the
> [ObservationManager issues a
> log.warn|https://github.com/apache/jackrabbit-oak/blob/be59ea9a098279fd243f83ff0ecbcb8fa71249db/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/observation/ObservationManagerImpl.java#L457]
> resulting in something like this:
> {noformat}
> 20.02.2017 16:40:05.773 *WARN* [FelixStartLevel]
> org.apache.jackrabbit.oak.jcr.observation.ObservationManagerImpl Timed out
> waiting for change processor to stop after 1000 milliseconds. Falling back to
> asynchronous stop on ChangeProcessor [listenerId=56,
> tracker=//*[1b]@org.apache.sling.jcr.resource.internal.JcrResourceListener,
> contentSession=session-1181,
> eventCount=org.apache.jackrabbit.oak.plugins.metric.CompositeStats@3da35e6e,
> eventDuration=org.apache.jackrabbit.oak.plugins.metric.CompositeStats@308ca75f,
> commitRateLimiter=null, running=false]
> {noformat}
> Unfortunately - in case of the Sling JcrResourceListener - you can't know
> which actual {{ResourceChangeListener}} is hiding behind it.
> The above log.warn should be improved to also show the {{getToString()}} of
> the listener which provides more details including the actual
> ResourceChangeListener.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-5751) RDBDocumentStore: properly handle null values for boolean properties
[ https://issues.apache.org/jira/browse/OAK-5751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-5751: Issue Type: Technical task (was: Bug) Parent: OAK-1266 > RDBDocumentStore: properly handle null values for boolean properties > > > Key: OAK-5751 > URL: https://issues.apache.org/jira/browse/OAK-5751 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.8 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (OAK-5751) RDBDocumentStore: properly handle null values for boolean properties
Julian Reschke created OAK-5751: --- Summary: RDBDocumentStore: properly handle null values for boolean properties Key: OAK-5751 URL: https://issues.apache.org/jira/browse/OAK-5751 Project: Jackrabbit Oak Issue Type: Bug Components: rdbmk Reporter: Julian Reschke Assignee: Julian Reschke Priority: Minor Fix For: 1.8 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-5741) DocumentStore UpdateOp: support removal of properties
[ https://issues.apache.org/jira/browse/OAK-5741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15877628#comment-15877628 ] Julian Reschke commented on OAK-5741: - [~mreutegg] - maybe you can have a look, while I'll revise the RDB store code that's related to nullability. > DocumentStore UpdateOp: support removal of properties > - > > Key: OAK-5741 > URL: https://issues.apache.org/jira/browse/OAK-5741 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: documentmk >Reporter: Julian Reschke >Assignee: Julian Reschke > Attachments: OAK-5741.diff > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-5731) Build failure: Backing channel '......' is disconnected
[ https://issues.apache.org/jira/browse/OAK-5731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15877559#comment-15877559 ] Hudson commented on OAK-5731: - Previously failing build now is OK. Passed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.7 (latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting #1444|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting/1444/] [console log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting/1444/console] > Build failure: Backing channel '..' is disconnected > --- > > Key: OAK-5731 > URL: https://issues.apache.org/jira/browse/OAK-5731 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Affects Versions: 1.4.13, 1.6.0, 1.7.0 >Reporter: Hudson > Labels: CI, ubuntu, windows > > Jenkins CI failure: > https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/ > The build Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.7 > (latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting #1437 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.7 (latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting > #1437|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting/1437/] > [console > log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting/1437/console] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-5750) Build Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.7 (latest),nsfixtures=SEGMENT_TAR,profile=unittesting #1441 failed
[ https://issues.apache.org/jira/browse/OAK-5750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15877518#comment-15877518 ] Hudson commented on OAK-5750: - Previously failing build now is OK. Passed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.7 (latest),nsfixtures=SEGMENT_TAR,profile=unittesting #1443|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=SEGMENT_TAR,profile=unittesting/1443/] [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/1443/console] > Build Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.7 > (latest),nsfixtures=SEGMENT_TAR,profile=unittesting #1441 failed > > > Key: OAK-5750 > URL: https://issues.apache.org/jira/browse/OAK-5750 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson > > 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] [Commented] (OAK-5731) Build failure: Backing channel '......' is disconnected
[ https://issues.apache.org/jira/browse/OAK-5731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15877507#comment-15877507 ] Hudson commented on OAK-5731: - Previously failing build now is OK. Passed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.7 (latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting #1443|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting/1443/] [console log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting/1443/console] > Build failure: Backing channel '..' is disconnected > --- > > Key: OAK-5731 > URL: https://issues.apache.org/jira/browse/OAK-5731 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Affects Versions: 1.4.13, 1.6.0, 1.7.0 >Reporter: Hudson > Labels: CI, ubuntu, windows > > Jenkins CI failure: > https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/ > The build Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.7 > (latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting #1437 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.7 (latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting > #1437|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting/1437/] > [console > log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting/1437/console] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-5750) Build Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.7 (latest),nsfixtures=SEGMENT_TAR,profile=unittesting #1441 failed
[ https://issues.apache.org/jira/browse/OAK-5750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15877496#comment-15877496 ] Hudson commented on OAK-5750: - Previously failing build now is OK. Passed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.7 (latest),nsfixtures=SEGMENT_TAR,profile=unittesting #1442|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=SEGMENT_TAR,profile=unittesting/1442/] [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/1442/console] > Build Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.7 > (latest),nsfixtures=SEGMENT_TAR,profile=unittesting #1441 failed > > > Key: OAK-5750 > URL: https://issues.apache.org/jira/browse/OAK-5750 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson > > 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] [Commented] (OAK-5731) Build failure: Backing channel '......' is disconnected
[ https://issues.apache.org/jira/browse/OAK-5731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15877468#comment-15877468 ] Hudson commented on OAK-5731: - Previously failing build now is OK. Passed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.7 (latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting #1442|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting/1442/] [console log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting/1442/console] > Build failure: Backing channel '..' is disconnected > --- > > Key: OAK-5731 > URL: https://issues.apache.org/jira/browse/OAK-5731 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Affects Versions: 1.4.13, 1.6.0, 1.7.0 >Reporter: Hudson > Labels: CI, ubuntu, windows > > Jenkins CI failure: > https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/ > The build Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.7 > (latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting #1437 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.7 (latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting > #1437|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting/1437/] > [console > log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting/1437/console] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-5731) Build failure: Backing channel '......' is disconnected
[ https://issues.apache.org/jira/browse/OAK-5731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-5731: --- Summary: Build failure: Backing channel '..' is disconnected (was: Build failure: Backing channel 'ubuntu-us1' is disconnected) > Build failure: Backing channel '..' is disconnected > --- > > Key: OAK-5731 > URL: https://issues.apache.org/jira/browse/OAK-5731 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Affects Versions: 1.4.13, 1.6.0, 1.7.0 >Reporter: Hudson > Labels: CI, ubuntu, windows > > Jenkins CI failure: > https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/ > The build Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.7 > (latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting #1437 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.7 (latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting > #1437|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting/1437/] > [console > log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting/1437/console] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (OAK-5750) Build Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.7 (latest),nsfixtures=SEGMENT_TAR,profile=unittesting #1441 failed
Hudson created OAK-5750: --- Summary: Build Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.7 (latest),nsfixtures=SEGMENT_TAR,profile=unittesting #1441 failed Key: OAK-5750 URL: https://issues.apache.org/jira/browse/OAK-5750 Project: Jackrabbit Oak Issue Type: Bug Components: continuous integration Reporter: Hudson 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] [Resolved] (OAK-5745) Build Oak-Win/Windows slaves=Windows,jdk=JDK 1.7 (unlimited security) 64-bit Windows only,nsfixtures=SEGMENT_MK,profile=unittesting #468 failed
[ https://issues.apache.org/jira/browse/OAK-5745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain resolved OAK-5745. Resolution: Duplicate > Build Oak-Win/Windows slaves=Windows,jdk=JDK 1.7 (unlimited security) 64-bit > Windows only,nsfixtures=SEGMENT_MK,profile=unittesting #468 failed > --- > > Key: OAK-5745 > URL: https://issues.apache.org/jira/browse/OAK-5745 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson > > 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=SEGMENT_MK,profile=unittesting #468 has failed. > First failed run: [Oak-Win/Windows slaves=Windows,jdk=JDK 1.7 (unlimited > security) 64-bit Windows only,nsfixtures=SEGMENT_MK,profile=unittesting > #468|https://builds.apache.org/job/Oak-Win/Windows%20slaves=Windows,jdk=JDK%201.7%20(unlimited%20security)%2064-bit%20Windows%20only,nsfixtures=SEGMENT_MK,profile=unittesting/468/] > [console > log|https://builds.apache.org/job/Oak-Win/Windows%20slaves=Windows,jdk=JDK%201.7%20(unlimited%20security)%2064-bit%20Windows%20only,nsfixtures=SEGMENT_MK,profile=unittesting/468/console] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (OAK-5749) Build Oak-Win/Windows slaves=Windows,jdk=JDK 1.7 (unlimited security) 64-bit Windows only,nsfixtures=DOCUMENT_RDB,profile=unittesting #468 failed
[ https://issues.apache.org/jira/browse/OAK-5749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain resolved OAK-5749. Resolution: Duplicate > Build Oak-Win/Windows slaves=Windows,jdk=JDK 1.7 (unlimited security) 64-bit > Windows only,nsfixtures=DOCUMENT_RDB,profile=unittesting #468 failed > - > > Key: OAK-5749 > URL: https://issues.apache.org/jira/browse/OAK-5749 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson > > 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_RDB,profile=unittesting #468 has > failed. > First failed run: [Oak-Win/Windows slaves=Windows,jdk=JDK 1.7 (unlimited > security) 64-bit Windows only,nsfixtures=DOCUMENT_RDB,profile=unittesting > #468|https://builds.apache.org/job/Oak-Win/Windows%20slaves=Windows,jdk=JDK%201.7%20(unlimited%20security)%2064-bit%20Windows%20only,nsfixtures=DOCUMENT_RDB,profile=unittesting/468/] > [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_RDB,profile=unittesting/468/console] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (OAK-5747) Build Oak-Win/Windows slaves=Windows,jdk=JDK 1.8 (unlimited security) 64-bit Windows only,nsfixtures=SEGMENT_TAR,profile=unittesting #468 failed
[ https://issues.apache.org/jira/browse/OAK-5747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain resolved OAK-5747. Resolution: Duplicate > Build Oak-Win/Windows slaves=Windows,jdk=JDK 1.8 (unlimited security) 64-bit > Windows only,nsfixtures=SEGMENT_TAR,profile=unittesting #468 failed > > > Key: OAK-5747 > URL: https://issues.apache.org/jira/browse/OAK-5747 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson > > 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 #468 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 > #468|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/468/] > [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/468/console] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (OAK-5748) Build Oak-Win/Windows slaves=Windows,jdk=JDK 1.7 (unlimited security) 64-bit Windows only,nsfixtures=SEGMENT_MK,profile=integrationTesting #468 failed
[ https://issues.apache.org/jira/browse/OAK-5748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain resolved OAK-5748. Resolution: Duplicate > Build Oak-Win/Windows slaves=Windows,jdk=JDK 1.7 (unlimited security) 64-bit > Windows only,nsfixtures=SEGMENT_MK,profile=integrationTesting #468 failed > -- > > Key: OAK-5748 > URL: https://issues.apache.org/jira/browse/OAK-5748 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson > > 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=SEGMENT_MK,profile=integrationTesting #468 has > failed. > First failed run: [Oak-Win/Windows slaves=Windows,jdk=JDK 1.7 (unlimited > security) 64-bit Windows > only,nsfixtures=SEGMENT_MK,profile=integrationTesting > #468|https://builds.apache.org/job/Oak-Win/Windows%20slaves=Windows,jdk=JDK%201.7%20(unlimited%20security)%2064-bit%20Windows%20only,nsfixtures=SEGMENT_MK,profile=integrationTesting/468/] > [console > log|https://builds.apache.org/job/Oak-Win/Windows%20slaves=Windows,jdk=JDK%201.7%20(unlimited%20security)%2064-bit%20Windows%20only,nsfixtures=SEGMENT_MK,profile=integrationTesting/468/console] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-5731) Build failure: Backing channel 'ubuntu-us1' is disconnected
[ https://issues.apache.org/jira/browse/OAK-5731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-5731: --- Affects Version/s: 1.4.13 > Build failure: Backing channel 'ubuntu-us1' is disconnected > --- > > Key: OAK-5731 > URL: https://issues.apache.org/jira/browse/OAK-5731 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Affects Versions: 1.4.13, 1.6.0, 1.7.0 >Reporter: Hudson > Labels: CI, ubuntu, windows > > Jenkins CI failure: > https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/ > The build Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.7 > (latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting #1437 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.7 (latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting > #1437|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting/1437/] > [console > log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting/1437/console] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-5731) Build failure: Backing channel 'ubuntu-us1' is disconnected
[ https://issues.apache.org/jira/browse/OAK-5731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-5731: --- Labels: CI ubuntu windows (was: CI) > Build failure: Backing channel 'ubuntu-us1' is disconnected > --- > > Key: OAK-5731 > URL: https://issues.apache.org/jira/browse/OAK-5731 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Affects Versions: 1.4.13, 1.6.0, 1.7.0 >Reporter: Hudson > Labels: CI, ubuntu, windows > > Jenkins CI failure: > https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/ > The build Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.7 > (latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting #1437 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.7 (latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting > #1437|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting/1437/] > [console > log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting/1437/console] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-5731) Build failure: Backing channel 'ubuntu-us1' is disconnected
[ https://issues.apache.org/jira/browse/OAK-5731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15877435#comment-15877435 ] Hudson commented on OAK-5731: - Previously failing build now is OK. Passed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.7 (latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting #1441|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting/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=integrationTesting/1441/console] > Build failure: Backing channel 'ubuntu-us1' is disconnected > --- > > Key: OAK-5731 > URL: https://issues.apache.org/jira/browse/OAK-5731 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Affects Versions: 1.6.0, 1.7.0 >Reporter: Hudson > Labels: CI > > Jenkins CI failure: > https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/ > The build Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.7 > (latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting #1437 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.7 (latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting > #1437|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting/1437/] > [console > log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=SEGMENT_TAR,profile=integrationTesting/1437/console] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (OAK-5749) Build Oak-Win/Windows slaves=Windows,jdk=JDK 1.7 (unlimited security) 64-bit Windows only,nsfixtures=DOCUMENT_RDB,profile=unittesting #468 failed
Hudson created OAK-5749: --- Summary: Build Oak-Win/Windows slaves=Windows,jdk=JDK 1.7 (unlimited security) 64-bit Windows only,nsfixtures=DOCUMENT_RDB,profile=unittesting #468 failed Key: OAK-5749 URL: https://issues.apache.org/jira/browse/OAK-5749 Project: Jackrabbit Oak Issue Type: Bug Components: continuous integration Reporter: Hudson 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_RDB,profile=unittesting #468 has failed. First failed run: [Oak-Win/Windows slaves=Windows,jdk=JDK 1.7 (unlimited security) 64-bit Windows only,nsfixtures=DOCUMENT_RDB,profile=unittesting #468|https://builds.apache.org/job/Oak-Win/Windows%20slaves=Windows,jdk=JDK%201.7%20(unlimited%20security)%2064-bit%20Windows%20only,nsfixtures=DOCUMENT_RDB,profile=unittesting/468/] [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_RDB,profile=unittesting/468/console] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (OAK-5748) Build Oak-Win/Windows slaves=Windows,jdk=JDK 1.7 (unlimited security) 64-bit Windows only,nsfixtures=SEGMENT_MK,profile=integrationTesting #468 failed
Hudson created OAK-5748: --- Summary: Build Oak-Win/Windows slaves=Windows,jdk=JDK 1.7 (unlimited security) 64-bit Windows only,nsfixtures=SEGMENT_MK,profile=integrationTesting #468 failed Key: OAK-5748 URL: https://issues.apache.org/jira/browse/OAK-5748 Project: Jackrabbit Oak Issue Type: Bug Components: continuous integration Reporter: Hudson 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=SEGMENT_MK,profile=integrationTesting #468 has failed. First failed run: [Oak-Win/Windows slaves=Windows,jdk=JDK 1.7 (unlimited security) 64-bit Windows only,nsfixtures=SEGMENT_MK,profile=integrationTesting #468|https://builds.apache.org/job/Oak-Win/Windows%20slaves=Windows,jdk=JDK%201.7%20(unlimited%20security)%2064-bit%20Windows%20only,nsfixtures=SEGMENT_MK,profile=integrationTesting/468/] [console log|https://builds.apache.org/job/Oak-Win/Windows%20slaves=Windows,jdk=JDK%201.7%20(unlimited%20security)%2064-bit%20Windows%20only,nsfixtures=SEGMENT_MK,profile=integrationTesting/468/console] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (OAK-5747) Build Oak-Win/Windows slaves=Windows,jdk=JDK 1.8 (unlimited security) 64-bit Windows only,nsfixtures=SEGMENT_TAR,profile=unittesting #468 failed
Hudson created OAK-5747: --- Summary: Build Oak-Win/Windows slaves=Windows,jdk=JDK 1.8 (unlimited security) 64-bit Windows only,nsfixtures=SEGMENT_TAR,profile=unittesting #468 failed Key: OAK-5747 URL: https://issues.apache.org/jira/browse/OAK-5747 Project: Jackrabbit Oak Issue Type: Bug Components: continuous integration Reporter: Hudson 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 #468 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 #468|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/468/] [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/468/console] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (OAK-5746) Build Oak-Win/Windows slaves=Windows,jdk=JDK 1.7 (unlimited security) 64-bit Windows only,nsfixtures=DOCUMENT_NS,profile=integrationTesting #468 failed
Hudson created OAK-5746: --- Summary: Build Oak-Win/Windows slaves=Windows,jdk=JDK 1.7 (unlimited security) 64-bit Windows only,nsfixtures=DOCUMENT_NS,profile=integrationTesting #468 failed Key: OAK-5746 URL: https://issues.apache.org/jira/browse/OAK-5746 Project: Jackrabbit Oak Issue Type: Bug Components: continuous integration Reporter: Hudson 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=integrationTesting #468 has failed. First failed run: [Oak-Win/Windows slaves=Windows,jdk=JDK 1.7 (unlimited security) 64-bit Windows only,nsfixtures=DOCUMENT_NS,profile=integrationTesting #468|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=integrationTesting/468/] [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=integrationTesting/468/console] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (OAK-5745) Build Oak-Win/Windows slaves=Windows,jdk=JDK 1.7 (unlimited security) 64-bit Windows only,nsfixtures=SEGMENT_MK,profile=unittesting #468 failed
Hudson created OAK-5745: --- Summary: Build Oak-Win/Windows slaves=Windows,jdk=JDK 1.7 (unlimited security) 64-bit Windows only,nsfixtures=SEGMENT_MK,profile=unittesting #468 failed Key: OAK-5745 URL: https://issues.apache.org/jira/browse/OAK-5745 Project: Jackrabbit Oak Issue Type: Bug Components: continuous integration Reporter: Hudson 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=SEGMENT_MK,profile=unittesting #468 has failed. First failed run: [Oak-Win/Windows slaves=Windows,jdk=JDK 1.7 (unlimited security) 64-bit Windows only,nsfixtures=SEGMENT_MK,profile=unittesting #468|https://builds.apache.org/job/Oak-Win/Windows%20slaves=Windows,jdk=JDK%201.7%20(unlimited%20security)%2064-bit%20Windows%20only,nsfixtures=SEGMENT_MK,profile=unittesting/468/] [console log|https://builds.apache.org/job/Oak-Win/Windows%20slaves=Windows,jdk=JDK%201.7%20(unlimited%20security)%2064-bit%20Windows%20only,nsfixtures=SEGMENT_MK,profile=unittesting/468/console] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (OAK-5744) [Oak Lucene] Exact match restrictions in Groups return no results
David Gonzalez created OAK-5744:
---
Summary: [Oak Lucene] Exact match restrictions in Groups return no
results
Key: OAK-5744
URL: https://issues.apache.org/jira/browse/OAK-5744
Project: Jackrabbit Oak
Issue Type: Bug
Components: lucene
Affects Versions: 1.6.0
Reporter: David Gonzalez
I am testing on: org.apache.jackrabbit.oak-lucene1.6.0.R1783091
Performing the query:
{noformat}
(cat OR dog)
{noformat}
Returns results.
{noformat}
"cat" OR "dog"
{noformat}
Also returns results.
{noformat}
("cat" OR "dog")
{noformat}
Returns no results. My expectation is all 3 lucene full-text queries should
return the same result set. Substitute multi-phrase terms for 'cat' and 'dog'
and the results are of a similar effect.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (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:comment-tabpanel=15876817#comment-15876817 ] Hudson commented on OAK-5736: - Previously failing build now is OK. Passed run: [Oak-Win/Windows slaves=Windows,jdk=JDK 1.8 (unlimited security) 64-bit Windows only,nsfixtures=SEGMENT_TAR,profile=unittesting #467|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/467/] [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/467/console] > 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 >Affects Versions: 1.6.0 >Reporter: Hudson > 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] [Comment Edited] (OAK-5740) deliver overflow change even without new commit
[
https://issues.apache.org/jira/browse/OAK-5740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15876460#comment-15876460
]
Vikas Saurabh edited comment on OAK-5740 at 2/21/17 6:45 PM:
-
[~egli],
{quote}
bq. may be some util class/method (exposed?? in case some external observer
want it!) would be ok.
what would such a util method do and how would it be used?
{quote}
I was mainly thinking of test scenario. So, I'd have been happy with something
like (ignore syntax and compilation errors :):
{code}
class ConsumingListenerWrapper implements EventListener {
private final EventListener delegate;
private final Session changePusher;
private long addNodeCounter;
private long observedNodeCounter;
private ConsumingListenerWrapper(Session changePusher, EventListener
delegate) {..}
static wrap (Session cp, EventListener el) {return new
ConsumingListenerWrapper(cp, el);}
onEvent(EventList events) {
delegate.onEvent(events);
while(events.hasNext()) {
/*
increment observed nodes
*/
Event e = events.nextEvent();
if (addNodeCount - observedNodeCount < OBS_Q_LENGTH &&
doItOneInThreeTime) {Node n =
changePusher.createNode("/var/");changePusher.save();n.remove();changePusher.save();}
}
}
Node addNode(String path) {
addNodeCounter++;
return changePusher.addNode(path);
}
}
{code}
Of course, that's similar to what I did while fixing the test of observation
warn logger test - we could probably do something else entirely.
bq. I'm not proposing that it's realistic that this issue happens, but I don't
think it's only relevant in a test neither.
Ack. I personally don't feel comfortable changing this part of logic - but,
yes, if this is fixed, that's perfectly fine with me.
was (Author: catholicon):
[~egli],
{quote}
bq. may be some util class/method (exposed?? in case some external observer
want it!) would be ok.
what would such a util method do and how would it be used?
{quote}
I was mainly thinking of test scenario. So, I'd have been happy with something
like (ignore syntax and compilation errors :):
{code}
class ConsumingListenerWrapper implements EventListener {
private final EventListener delegate;
private final Session changePusher;
private ConsumingListenerWrapper(Session changePusher, EventListener
delegate) {..}
static wrap (Session cp, EventListener el) {return new
ConsumingListenerWrapper(cp, el);}
onEvent(EventList events) {
delegate.onEvent(events);
while(events.hasNext()) {
Event e = events.nextEvent();
if (lastEventProcessesWas1SecondAgo) {Node n =
changePusher.createNode("/var/");changePusher.save();n.remove();changePusher.save();}
}
}
}
{code}
bq. I'm not proposing that it's realistic that this issue happens, but I don't
think it's only relevant in a test neither.
Ack. I personally don't feel comfortable changing this part of logic - but,
yes, if this is fixed, that's perfectly fine with me.
> 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
>Priority: Minor
> Attachments: OAK-5740.testcase.patch, OAK-5740.testcase.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.3.15#6346)
[jira] [Commented] (OAK-5740) deliver overflow change even without new commit
[
https://issues.apache.org/jira/browse/OAK-5740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15876460#comment-15876460
]
Vikas Saurabh commented on OAK-5740:
[~egli],
{quote}
bq. may be some util class/method (exposed?? in case some external observer
want it!) would be ok.
what would such a util method do and how would it be used?
{quote}
I was mainly thinking of test scenario. So, I'd have been happy with something
like (ignore syntax and compilation errors :):
{code}
class ConsumingListenerWrapper implements EventListener {
private final EventListener delegate;
private final Session changePusher;
private ConsumingListenerWrapper(Session changePusher, EventListener
delegate) {..}
static wrap (Session cp, EventListener el) {return new
ConsumingListenerWrapper(cp, el);}
onEvent(EventList events) {
delegate.onEvent(events);
while(events.hasNext()) {
Event e = events.nextEvent();
if (lastEventProcessesWas1SecondAgo) {Node n =
changePusher.createNode("/var/");changePusher.save();n.remove();changePusher.save();}
}
}
}
{code}
bq. I'm not proposing that it's realistic that this issue happens, but I don't
think it's only relevant in a test neither.
Ack. I personally don't feel comfortable changing this part of logic - but,
yes, if this is fixed, that's perfectly fine with me.
> 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
>Priority: Minor
> Attachments: OAK-5740.testcase.patch, OAK-5740.testcase.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.3.15#6346)
[jira] [Resolved] (OAK-5689) AbstractSecurityTest: enforce test-failure for traversal queries
[ https://issues.apache.org/jira/browse/OAK-5689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-5689. - Resolution: Fixed Fix Version/s: 1.7.0 all tests with FIXME as mention above no longer cause a traversal -> adjusting test cases (Committed revision 1783917) > AbstractSecurityTest: enforce test-failure for traversal queries > > > Key: OAK-5689 > URL: https://issues.apache.org/jira/browse/OAK-5689 > Project: Jackrabbit Oak > Issue Type: Test > Components: core >Reporter: angela >Assignee: angela > Fix For: 1.7.0, 1.8 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (OAK-5743) UserQueryManager: omits nt-name when searching for properties without path deliminator
[
https://issues.apache.org/jira/browse/OAK-5743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved OAK-5743.
-
Resolution: Fixed
Committed revision 1783916.
> UserQueryManager: omits nt-name when searching for properties without path
> deliminator
> --
>
> Key: OAK-5743
> URL: https://issues.apache.org/jira/browse/OAK-5743
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: angela
>Assignee: angela
> Fix For: 1.7.0, 1.8
>
>
> The query generated for {{UserManager.findAuthorizables(String relPath,
> String value, int searchType)}} and {{UserManager.findAuthorizables(String
> relPath, String value)}} doesn't include the node type name in the query
> statement if the {{relPath}} param doesn't include a path deliminator.
> While the contract mandates that a simple {{propertyName}} will result in a
> query that search the whole subtree defined by a given authorizable (i.e.
> including properties defined at child nodes) this causes a traversal query
> even for properties like {{rep:principalName}} or {{rep:authorizableId}},
> which are considered reserved and are covered with a dedicated index.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-5689) AbstractSecurityTest: enforce test-failure for traversal queries
[ https://issues.apache.org/jira/browse/OAK-5689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15876316#comment-15876316 ] angela commented on OAK-5689: - see OAK-5743 for the corresponding issue. > AbstractSecurityTest: enforce test-failure for traversal queries > > > Key: OAK-5689 > URL: https://issues.apache.org/jira/browse/OAK-5689 > Project: Jackrabbit Oak > Issue Type: Test > Components: core >Reporter: angela >Assignee: angela > Fix For: 1.8 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (OAK-5743) UserQueryManager: omits nt-name when searching for properties without path deliminator
angela created OAK-5743:
---
Summary: UserQueryManager: omits nt-name when searching for
properties without path deliminator
Key: OAK-5743
URL: https://issues.apache.org/jira/browse/OAK-5743
Project: Jackrabbit Oak
Issue Type: Improvement
Components: core
Reporter: angela
Assignee: angela
Fix For: 1.7.0, 1.8
The query generated for {{UserManager.findAuthorizables(String relPath, String
value, int searchType)}} and {{UserManager.findAuthorizables(String relPath,
String value)}} doesn't include the node type name in the query statement if
the {{relPath}} param doesn't include a path deliminator.
While the contract mandates that a simple {{propertyName}} will result in a
query that search the whole subtree defined by a given authorizable (i.e.
including properties defined at child nodes) this causes a traversal query even
for properties like {{rep:principalName}} or {{rep:authorizableId}}, which are
considered reserved and are covered with a dedicated index.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (OAK-5742) more logging when ChangeProcessor.stopAndWait fails
[
https://issues.apache.org/jira/browse/OAK-5742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli resolved OAK-5742.
--
Resolution: Fixed
> more logging when ChangeProcessor.stopAndWait fails
> ---
>
> Key: OAK-5742
> URL: https://issues.apache.org/jira/browse/OAK-5742
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Affects Versions: 1.6.0
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Labels: candidate_oak_1_6
> Fix For: 1.7.0, 1.8
>
>
> When ChangeProcessor.stopAndWait fails (returns false) the
> [ObservationManager issues a
> log.warn|https://github.com/apache/jackrabbit-oak/blob/be59ea9a098279fd243f83ff0ecbcb8fa71249db/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/observation/ObservationManagerImpl.java#L457]
> resulting in something like this:
> {noformat}
> 20.02.2017 16:40:05.773 *WARN* [FelixStartLevel]
> org.apache.jackrabbit.oak.jcr.observation.ObservationManagerImpl Timed out
> waiting for change processor to stop after 1000 milliseconds. Falling back to
> asynchronous stop on ChangeProcessor [listenerId=56,
> tracker=//*[1b]@org.apache.sling.jcr.resource.internal.JcrResourceListener,
> contentSession=session-1181,
> eventCount=org.apache.jackrabbit.oak.plugins.metric.CompositeStats@3da35e6e,
> eventDuration=org.apache.jackrabbit.oak.plugins.metric.CompositeStats@308ca75f,
> commitRateLimiter=null, running=false]
> {noformat}
> Unfortunately - in case of the Sling JcrResourceListener - you can't know
> which actual {{ResourceChangeListener}} is hiding behind it.
> The above log.warn should be improved to also show the {{getToString()}} of
> the listener which provides more details including the actual
> ResourceChangeListener.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-5742) more logging when ChangeProcessor.stopAndWait fails
[
https://issues.apache.org/jira/browse/OAK-5742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15876294#comment-15876294
]
Stefan Egli commented on OAK-5742:
--
I'd like to backport this to the 1.6-branch, [~chetanm], [~mreutegg], opinions?
> more logging when ChangeProcessor.stopAndWait fails
> ---
>
> Key: OAK-5742
> URL: https://issues.apache.org/jira/browse/OAK-5742
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Affects Versions: 1.6.0
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Labels: candidate_oak_1_6
> Fix For: 1.7.0, 1.8
>
>
> When ChangeProcessor.stopAndWait fails (returns false) the
> [ObservationManager issues a
> log.warn|https://github.com/apache/jackrabbit-oak/blob/be59ea9a098279fd243f83ff0ecbcb8fa71249db/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/observation/ObservationManagerImpl.java#L457]
> resulting in something like this:
> {noformat}
> 20.02.2017 16:40:05.773 *WARN* [FelixStartLevel]
> org.apache.jackrabbit.oak.jcr.observation.ObservationManagerImpl Timed out
> waiting for change processor to stop after 1000 milliseconds. Falling back to
> asynchronous stop on ChangeProcessor [listenerId=56,
> tracker=//*[1b]@org.apache.sling.jcr.resource.internal.JcrResourceListener,
> contentSession=session-1181,
> eventCount=org.apache.jackrabbit.oak.plugins.metric.CompositeStats@3da35e6e,
> eventDuration=org.apache.jackrabbit.oak.plugins.metric.CompositeStats@308ca75f,
> commitRateLimiter=null, running=false]
> {noformat}
> Unfortunately - in case of the Sling JcrResourceListener - you can't know
> which actual {{ResourceChangeListener}} is hiding behind it.
> The above log.warn should be improved to also show the {{getToString()}} of
> the listener which provides more details including the actual
> ResourceChangeListener.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-5742) more logging when ChangeProcessor.stopAndWait fails
[
https://issues.apache.org/jira/browse/OAK-5742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated OAK-5742:
-
Labels: candidate_oak_1_6 (was: )
> more logging when ChangeProcessor.stopAndWait fails
> ---
>
> Key: OAK-5742
> URL: https://issues.apache.org/jira/browse/OAK-5742
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Affects Versions: 1.6.0
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Labels: candidate_oak_1_6
> Fix For: 1.7.0, 1.8
>
>
> When ChangeProcessor.stopAndWait fails (returns false) the
> [ObservationManager issues a
> log.warn|https://github.com/apache/jackrabbit-oak/blob/be59ea9a098279fd243f83ff0ecbcb8fa71249db/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/observation/ObservationManagerImpl.java#L457]
> resulting in something like this:
> {noformat}
> 20.02.2017 16:40:05.773 *WARN* [FelixStartLevel]
> org.apache.jackrabbit.oak.jcr.observation.ObservationManagerImpl Timed out
> waiting for change processor to stop after 1000 milliseconds. Falling back to
> asynchronous stop on ChangeProcessor [listenerId=56,
> tracker=//*[1b]@org.apache.sling.jcr.resource.internal.JcrResourceListener,
> contentSession=session-1181,
> eventCount=org.apache.jackrabbit.oak.plugins.metric.CompositeStats@3da35e6e,
> eventDuration=org.apache.jackrabbit.oak.plugins.metric.CompositeStats@308ca75f,
> commitRateLimiter=null, running=false]
> {noformat}
> Unfortunately - in case of the Sling JcrResourceListener - you can't know
> which actual {{ResourceChangeListener}} is hiding behind it.
> The above log.warn should be improved to also show the {{getToString()}} of
> the listener which provides more details including the actual
> ResourceChangeListener.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-5742) more logging when ChangeProcessor.stopAndWait fails
[
https://issues.apache.org/jira/browse/OAK-5742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15876291#comment-15876291
]
Stefan Egli commented on OAK-5742:
--
* added to trunk in [rev
1783910|http://svn.apache.org/viewvc?rev=1783910=rev]
> more logging when ChangeProcessor.stopAndWait fails
> ---
>
> Key: OAK-5742
> URL: https://issues.apache.org/jira/browse/OAK-5742
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Affects Versions: 1.6.0
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: 1.7.0, 1.8
>
>
> When ChangeProcessor.stopAndWait fails (returns false) the
> [ObservationManager issues a
> log.warn|https://github.com/apache/jackrabbit-oak/blob/be59ea9a098279fd243f83ff0ecbcb8fa71249db/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/observation/ObservationManagerImpl.java#L457]
> resulting in something like this:
> {noformat}
> 20.02.2017 16:40:05.773 *WARN* [FelixStartLevel]
> org.apache.jackrabbit.oak.jcr.observation.ObservationManagerImpl Timed out
> waiting for change processor to stop after 1000 milliseconds. Falling back to
> asynchronous stop on ChangeProcessor [listenerId=56,
> tracker=//*[1b]@org.apache.sling.jcr.resource.internal.JcrResourceListener,
> contentSession=session-1181,
> eventCount=org.apache.jackrabbit.oak.plugins.metric.CompositeStats@3da35e6e,
> eventDuration=org.apache.jackrabbit.oak.plugins.metric.CompositeStats@308ca75f,
> commitRateLimiter=null, running=false]
> {noformat}
> Unfortunately - in case of the Sling JcrResourceListener - you can't know
> which actual {{ResourceChangeListener}} is hiding behind it.
> The above log.warn should be improved to also show the {{getToString()}} of
> the listener which provides more details including the actual
> ResourceChangeListener.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (OAK-5742) more logging when ChangeProcessor.stopAndWait fails
Stefan Egli created OAK-5742:
Summary: more logging when ChangeProcessor.stopAndWait fails
Key: OAK-5742
URL: https://issues.apache.org/jira/browse/OAK-5742
Project: Jackrabbit Oak
Issue Type: Improvement
Components: jcr
Affects Versions: 1.6.0
Reporter: Stefan Egli
Assignee: Stefan Egli
Fix For: 1.7.0, 1.8
When ChangeProcessor.stopAndWait fails (returns false) the [ObservationManager
issues a
log.warn|https://github.com/apache/jackrabbit-oak/blob/be59ea9a098279fd243f83ff0ecbcb8fa71249db/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/observation/ObservationManagerImpl.java#L457]
resulting in something like this:
{noformat}
20.02.2017 16:40:05.773 *WARN* [FelixStartLevel]
org.apache.jackrabbit.oak.jcr.observation.ObservationManagerImpl Timed out
waiting for change processor to stop after 1000 milliseconds. Falling back to
asynchronous stop on ChangeProcessor [listenerId=56,
tracker=//*[1b]@org.apache.sling.jcr.resource.internal.JcrResourceListener,
contentSession=session-1181,
eventCount=org.apache.jackrabbit.oak.plugins.metric.CompositeStats@3da35e6e,
eventDuration=org.apache.jackrabbit.oak.plugins.metric.CompositeStats@308ca75f,
commitRateLimiter=null, running=false]
{noformat}
Unfortunately - in case of the Sling JcrResourceListener - you can't know which
actual {{ResourceChangeListener}} is hiding behind it.
The above log.warn should be improved to also show the {{getToString()}} of the
listener which provides more details including the actual
ResourceChangeListener.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-5600) Test coverage for CheckCommand
[
https://issues.apache.org/jira/browse/OAK-5600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-5600:
-
Attachment: OAK-5600-03.patch
I attached a new patch dealing with the inconsistent repository case. Besides
the valid revision written in the beginning, another invalid revision is
written on top. This way, the consistency check eventually finds a good
revision in the repository. The test is currently ignored because I discovered
a bug introduced by OAK-5556.
To better explain the bug I'll describe the content of the revisions:
* Valid Revision
Adds child nodes {{a}}, {{b}}, {{c}}, {{d}}, {{e}}, {{f}} with various
properties (blobs included)
* Invalid Revision
Adds child node {{z}} with some blob properties and then corrupts the {{NODE}}
record holding {{z}}.
Now when the consistency check is run, it correctly detects that the second
revision is broken, *marks the path {{/z}} as corrupt* and then continues
checking the first valid revision. Because of a check introduced for OAK-5556
[1], which tries to validate the user provided absolute paths before checking
them, the checker tries to check {{/z}} in the first revision, where of course
it can't find it. Therefore the check incorrectly fails for this revision,
although it shouldn't have to.
I was thinking about how this could be solved better. The easiest thing to do
would be to remove the check and always check the root node when a path is not
found (as done pre-OAK-5620). But then, what is the right way of handling the
case of a user who wants to check a partial path (like {{/z}}) which is corrupt
in the current revision and absent in the next one? Listing the last good
revision implies that that is a consistent revision which also contains the
path, or simply the last consistent revision?
[~mduerig], [~frm] WDYT?
If you think the patch looks good, I was thinking to commit it as is (test
ignored) and to open a new issue for the bug discovered. The test will be
enabled after solving that one.
[1]
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/file/tooling/ConsistencyChecker.java#L328
> Test coverage for CheckCommand
> --
>
> Key: OAK-5600
> URL: https://issues.apache.org/jira/browse/OAK-5600
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: run, segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
> Labels: tooling
> Fix For: 1.7.0, 1.8
>
> Attachments: OAK-5600-02.patch, OAK-5600-03.patch, OAK-5600.patch
>
>
> We should add tests for {{o.a.j.o.r.CheckCommand}} in order to validate
> recent changes introduced by adding/removing options and their arguments (see
> OAK-5275, OAK-5276, OAK-5277, OAK-5595). There is also a new feature
> introduced by OAK-5556 (filter paths) and a refactoring in OAK-5620 which
> must be thoroughly tested in order to avoid regressions.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-4888) Warn or fail queries above a configurable cost value
[ https://issues.apache.org/jira/browse/OAK-4888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15876164#comment-15876164 ] Thomas Mueller commented on OAK-4888: - Documentation in revision 1783902. > Warn or fail queries above a configurable cost value > > > Key: OAK-4888 > URL: https://issues.apache.org/jira/browse/OAK-4888 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Alexander Klimetschek >Assignee: Thomas Mueller > Labels: docs-impacting > Fix For: 1.5.13, 1.6.0 > > > *Problem:* It's easy to run into performance problems with queries that are > not backed by an index or miss the right one. Developers writing these > queries typically do not have the real large production data, and thus don't > see that a query would scale badly, and would not see any traversal warnings, > as these only happen with a large number of results. > *Proposal:* Oak's query engine already calculates a cost estimate to make a > decision which index to use, or even if there is any at all. This cost > estimate could be used to find out if a query is not supported by an index or > with one that is not suitable enough (e.g. ordering by property that is not > indexed) > If a query is above a certain cost value, a big warning could be put out or > even the query could be made to fail (maybe a per query option, that you > might want to have to "fail" by default to ensure people are not overlooking > the problem). The cost limit should be configurable, as it might depend on > the hardware power. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-5704) VersionGC: reset _deletedOnce for documents that have been resurrected
[ https://issues.apache.org/jira/browse/OAK-5704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-5704: Attachment: OAK-5704-2.diff Revised patch, minus the change for OAK-5741; also updating the Javadoc for DELETED_ONCE. > VersionGC: reset _deletedOnce for documents that have been resurrected > -- > > Key: OAK-5704 > URL: https://issues.apache.org/jira/browse/OAK-5704 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Attachments: OAK-5704-2.diff, OAK-5704.diff > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-5704) VersionGC: reset _deletedOnce for documents that have been resurrected
[ https://issues.apache.org/jira/browse/OAK-5704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-5704: Attachment: (was: OAK-5704.diff) > VersionGC: reset _deletedOnce for documents that have been resurrected > -- > > Key: OAK-5704 > URL: https://issues.apache.org/jira/browse/OAK-5704 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Attachments: OAK-5704.diff > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-5704) VersionGC: reset _deletedOnce for documents that have been resurrected
[ https://issues.apache.org/jira/browse/OAK-5704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-5704: Attachment: OAK-5704.diff Revised patch, minus the change for OAK-5741. > VersionGC: reset _deletedOnce for documents that have been resurrected > -- > > Key: OAK-5704 > URL: https://issues.apache.org/jira/browse/OAK-5704 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Attachments: OAK-5704.diff, OAK-5704.diff > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (OAK-5741) DocumentStore UpdateOp: support removal of properties
Julian Reschke created OAK-5741: --- Summary: DocumentStore UpdateOp: support removal of properties Key: OAK-5741 URL: https://issues.apache.org/jira/browse/OAK-5741 Project: Jackrabbit Oak Issue Type: New Feature Components: documentmk Reporter: Julian Reschke Assignee: Julian Reschke -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-5689) AbstractSecurityTest: enforce test-failure for traversal queries
[
https://issues.apache.org/jira/browse/OAK-5689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15876057#comment-15876057
]
angela commented on OAK-5689:
-
[~tmueller], thanks for your analysis... unfortunately the proposed change
doesn't work because the {{UserQueryManager}} is also use to find arbitrary
properties located in the subtrees below users/groups, which would not be
defined by the {{rep:Authorizable}} primary type.
Nevertheless: for the queries mentioned above the node type should in fact be
property set so, most likely there is a another bug hidden somewhere in the
query code... let me take another look.
> AbstractSecurityTest: enforce test-failure for traversal queries
>
>
> Key: OAK-5689
> URL: https://issues.apache.org/jira/browse/OAK-5689
> Project: Jackrabbit Oak
> Issue Type: Test
> Components: core
>Reporter: angela
>Assignee: angela
> Fix For: 1.8
>
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-5437) Add a persistence-dependent namespace when running CLI commands
[
https://issues.apache.org/jira/browse/OAK-5437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15876055#comment-15876055
]
Davide Giannella commented on OAK-5437:
---
thanks for the clarifications. I see that while it's a nice thing on which I
agree, it doesn't really relate to reducing the size of oak-run as we would
eventually ship a über jar. It's orthogonal to the "slimming of oak run" epic.
> Add a persistence-dependent namespace when running CLI commands
> ---
>
> Key: OAK-5437
> URL: https://issues.apache.org/jira/browse/OAK-5437
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: run
>Reporter: Francesco Mari
>Assignee: Francesco Mari
> Labels: tooling
> Fix For: 1.8
>
>
> Commands in oak-run currently live in a flat namespace. If a command is
> specific to only one implementation, it will leave along other
> implementation-specific commands without any means of distinguishing what
> belongs where.
> I would like to add a layer of indirection to the oak-run command line
> interface, so to parse commands in the following fashion:
> {noformat}
> oak-run segment debug /path/to/folder
> oak-run mongo debug mongodb://host:12345
> oak-run rdb debug jdbc:oracle:oci8:scott/tiger@myhost
> {noformat}
> In this scenario, oak-run would become a simple entry point that would
> delegate to implementation-specific command line utilities based on the first
> argument. In the previous example, {{segment}}, {{mongo}} and {{rdb}} would
> delegate to three different implementation specific CLI utilities. Each of
> these CLI utilities will understand the {{debug}} command and will collect
> command-line parameters as it sees fit.
> If the code for a command is so generic that can be reused from different
> commands, it can be parameterised and reused from different
> implementation-specific commands.
> The benefit of this approach is that we can start moving commands closer to
> the implementations. This approach would benefit oak-run as well, which is
> overloaded with many commands from many different implementations.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (OAK-310) Custom name checking rules
[ https://issues.apache.org/jira/browse/OAK-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-310. Resolution: Later > Custom name checking rules > -- > > Key: OAK-310 > URL: https://issues.apache.org/jira/browse/OAK-310 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: core >Reporter: Jukka Zitting >Priority: Minor > > Instead of hardcoding all the JCR name rules into the NameValidator plugin we > already have, it would be nice to have an extension point for the exact rules > against which names are checked. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-5689) AbstractSecurityTest: enforce test-failure for traversal queries
[
https://issues.apache.org/jira/browse/OAK-5689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15876038#comment-15876038
]
Thomas Mueller commented on OAK-5689:
-
Proposed patch for discussion (excluding test changes):
{noformat}
---
src/main/java/org/apache/jackrabbit/oak/security/user/query/UserQueryManager.java
(revision 1783886)
+++
src/main/java/org/apache/jackrabbit/oak/security/user/query/UserQueryManager.java
(working copy)
@@ -215,7 +215,7 @@
} else if (ntName != null) {
stmt.append("element(*,").append(ntName).append(')');
} else {
-stmt.append("element(*)");
+stmt.append("element(*, rep:Authorizable)");
}
if (value == null) {
{noformat}
> AbstractSecurityTest: enforce test-failure for traversal queries
>
>
> Key: OAK-5689
> URL: https://issues.apache.org/jira/browse/OAK-5689
> Project: Jackrabbit Oak
> Issue Type: Test
> Components: core
>Reporter: angela
>Assignee: angela
> Fix For: 1.8
>
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (OAK-5689) AbstractSecurityTest: enforce test-failure for traversal queries
[
https://issues.apache.org/jira/browse/OAK-5689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15876013#comment-15876013
]
Thomas Mueller edited comment on OAK-5689 at 2/21/17 2:15 PM:
--
All tests from the above list fail for the same reason. The query is actually
{{/jcr:root/rep:security/rep:authorizables//element(\*)[@rep:principalName]}}.
was (Author: tmueller):
All tests from the above list fail for the same reason. The query is actually
{{/jcr:root/rep:security/rep:authorizables//element(*)[@rep:principalName]}}.
> AbstractSecurityTest: enforce test-failure for traversal queries
>
>
> Key: OAK-5689
> URL: https://issues.apache.org/jira/browse/OAK-5689
> Project: Jackrabbit Oak
> Issue Type: Test
> Components: core
>Reporter: angela
>Assignee: angela
> Fix For: 1.8
>
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-5612) Test failure: org.apache.jackrabbit.oak.run.osgi.DocumentNodeStoreConfigTest.testRDBDocumentStoreRestart
[ https://issues.apache.org/jira/browse/OAK-5612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15876024#comment-15876024 ] Julian Reschke commented on OAK-5612: - Doubled the time we wait from 500ms to 1000ms in r1783891. > Test failure: > org.apache.jackrabbit.oak.run.osgi.DocumentNodeStoreConfigTest.testRDBDocumentStoreRestart > > > Key: OAK-5612 > URL: https://issues.apache.org/jira/browse/OAK-5612 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration, pojosr >Affects Versions: 1.0.37, 1.2.23, 1.4.13, 1.6.0 >Reporter: Hudson >Assignee: Julian Reschke > Labels: test-failure, windows > Attachments: console_output.txt, 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.8 > (latest),nsfixtures=SEGMENT_MK,profile=unittesting #1412 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.8 (latest),nsfixtures=SEGMENT_MK,profile=unittesting > #1412|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=SEGMENT_MK,profile=unittesting/1412/] > [console > log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=SEGMENT_MK,profile=unittesting/1412/console] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-5496) Creating service user and setting ACLs immediately for this user fails
[
https://issues.apache.org/jira/browse/OAK-5496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-5496:
Component/s: (was: security)
> Creating service user and setting ACLs immediately for this user fails
> --
>
> Key: OAK-5496
> URL: https://issues.apache.org/jira/browse/OAK-5496
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.5.17
>Reporter: Oliver Lietz
>
> -This error happens only with Mongo, not with Tar.- Both Mongo and Tar are
> affected.
> {noformat}
> [...]
> 2017-01-20T11:20:09,185 | DEBUG | Apache Sling Repository Startup Thread |
> PropertyIndex| 58 - org.apache.jackrabbit.oak-core -
> 1.5.17 | property cost for principalName is 2.0
> 2017-01-20T11:20:09,185 | DEBUG | Apache Sling Repository Startup Thread |
> QueryEngineImpl | 58 - org.apache.jackrabbit.oak-core -
> 1.5.17 | No alternatives found. Query: select
> [rep:Authorizable].[rep:principalName] as
> [rep:Authorizable.rep:principalName], [rep:Authorizable].[rep:authorizableId]
> as [rep:Authorizable.rep:authorizableId], [rep:Authorizable].[jcr:uuid] as
> [rep:Authorizable.jcr:uuid], [rep:Authorizable].[jcr:primaryType] as
> [rep:Authorizable.jcr:primaryType], [rep:Authorizable].[jcr:created] as
> [rep:Authorizable.jcr:created], [rep:Authorizable].[jcr:createdBy] as
> [rep:Authorizable.jcr:createdBy] from [rep:Authorizable] as
> [rep:Authorizable] where [rep:Authorizable].[rep:principalName] =
> $principalName
> 2017-01-20T11:20:09,186 | DEBUG | Apache Sling Repository Startup Thread |
> UserManagerImpl | 58 - org.apache.jackrabbit.oak-core -
> 1.5.17 | System user created: sling-i18n
> 2017-01-20T11:20:09,186 | INFO | Apache Sling Repository Startup Thread |
> AclVisitor | 101 - org.apache.sling.jcr.repoinit -
> 1.1.2 | Adding ACL 'allow' entry '[jcr:read]' for [sling-i18n] on [/]
> 2017-01-20T11:20:09,187 | DEBUG | Apache Sling Repository Startup Thread |
> PropertyIndex| 58 - org.apache.jackrabbit.oak-core -
> 1.5.17 | property cost for principalName is 2.0
> 2017-01-20T11:20:09,187 | DEBUG | Apache Sling Repository Startup Thread |
> QueryEngineImpl | 58 - org.apache.jackrabbit.oak-core -
> 1.5.17 | No alternatives found. Query: select
> [rep:Authorizable].[rep:principalName] as
> [rep:Authorizable.rep:principalName], [rep:Authorizable].[rep:authorizableId]
> as [rep:Authorizable.rep:authorizableId], [rep:Authorizable].[jcr:uuid] as
> [rep:Authorizable.jcr:uuid], [rep:Authorizable].[jcr:primaryType] as
> [rep:Authorizable.jcr:primaryType], [rep:Authorizable].[jcr:created] as
> [rep:Authorizable.jcr:created], [rep:Authorizable].[jcr:createdBy] as
> [rep:Authorizable.jcr:createdBy] from [rep:Authorizable] as
> [rep:Authorizable] where [rep:Authorizable].[rep:principalName] =
> $principalName
> 2017-01-20T11:20:09,187 | DEBUG | Apache Sling Repository Startup Thread |
> PropertyIndex| 58 - org.apache.jackrabbit.oak-core -
> 1.5.17 | property cost for principalName is 2.0
> 2017-01-20T11:20:09,188 | DEBUG | Apache Sling Repository Startup Thread |
> QueryEngineImpl | 58 - org.apache.jackrabbit.oak-core -
> 1.5.17 | No alternatives found. Query: select
> [rep:Authorizable].[rep:principalName] as
> [rep:Authorizable.rep:principalName], [rep:Authorizable].[rep:authorizableId]
> as [rep:Authorizable.rep:authorizableId], [rep:Authorizable].[jcr:uuid] as
> [rep:Authorizable.jcr:uuid], [rep:Authorizable].[jcr:primaryType] as
> [rep:Authorizable.jcr:primaryType], [rep:Authorizable].[jcr:created] as
> [rep:Authorizable.jcr:created], [rep:Authorizable].[jcr:createdBy] as
> [rep:Authorizable.jcr:createdBy] from [rep:Authorizable] as
> [rep:Authorizable] where [rep:Authorizable].[rep:principalName] =
> $principalName
> 2017-01-20T11:20:09,188 | DEBUG | Apache Sling Repository Startup Thread |
> PropertyIndex| 58 - org.apache.jackrabbit.oak-core -
> 1.5.17 | property cost for principalName is 2.0
> 2017-01-20T11:20:09,188 | DEBUG | Apache Sling Repository Startup Thread |
> QueryEngineImpl | 58 - org.apache.jackrabbit.oak-core -
> 1.5.17 | No alternatives found. Query: select
> [rep:Authorizable].[rep:principalName] as
> [rep:Authorizable.rep:principalName], [rep:Authorizable].[rep:authorizableId]
> as [rep:Authorizable.rep:authorizableId], [rep:Authorizable].[jcr:uuid] as
> [rep:Authorizable.jcr:uuid], [rep:Authorizable].[jcr:primaryType] as
> [rep:Authorizable.jcr:primaryType], [rep:Authorizable].[jcr:created] as
> [rep:Authorizable.jcr:created], [rep:Authorizable].[jcr:createdBy] as
> [rep:Authorizable.jcr:createdBy] from [rep:Authorizable] as
>
[jira] [Resolved] (OAK-5496) Creating service user and setting ACLs immediately for this user fails
[
https://issues.apache.org/jira/browse/OAK-5496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved OAK-5496.
-
Resolution: Cannot Reproduce
[~olli], I think the problem is located in the way Sling sets up the access
control. If you want to setup permissions for a {{Principal}} associated with a
new {{User}} you should call {{User.getPrincipal}} after having created the
user. This is the only reliable way to _know_ the principal name associated
with a given user without relying on implementation details.
Note: If you are using the {{PrincipalManager}} API to retrieve a principal by
name you have to make sure it is "known" to the principal manager
implementation. The default implementation uses a query and thus will only
"know" a new principal upon index update, which requires changes to be
persisted.
Could it be that Sling repo-init uses some utility classes to create access
control entries that only take a String? Could it be that the repo-init code
mixes authorizableId with principal name?
> Creating service user and setting ACLs immediately for this user fails
> --
>
> Key: OAK-5496
> URL: https://issues.apache.org/jira/browse/OAK-5496
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, security
>Affects Versions: 1.5.17
>Reporter: Oliver Lietz
>
> -This error happens only with Mongo, not with Tar.- Both Mongo and Tar are
> affected.
> {noformat}
> [...]
> 2017-01-20T11:20:09,185 | DEBUG | Apache Sling Repository Startup Thread |
> PropertyIndex| 58 - org.apache.jackrabbit.oak-core -
> 1.5.17 | property cost for principalName is 2.0
> 2017-01-20T11:20:09,185 | DEBUG | Apache Sling Repository Startup Thread |
> QueryEngineImpl | 58 - org.apache.jackrabbit.oak-core -
> 1.5.17 | No alternatives found. Query: select
> [rep:Authorizable].[rep:principalName] as
> [rep:Authorizable.rep:principalName], [rep:Authorizable].[rep:authorizableId]
> as [rep:Authorizable.rep:authorizableId], [rep:Authorizable].[jcr:uuid] as
> [rep:Authorizable.jcr:uuid], [rep:Authorizable].[jcr:primaryType] as
> [rep:Authorizable.jcr:primaryType], [rep:Authorizable].[jcr:created] as
> [rep:Authorizable.jcr:created], [rep:Authorizable].[jcr:createdBy] as
> [rep:Authorizable.jcr:createdBy] from [rep:Authorizable] as
> [rep:Authorizable] where [rep:Authorizable].[rep:principalName] =
> $principalName
> 2017-01-20T11:20:09,186 | DEBUG | Apache Sling Repository Startup Thread |
> UserManagerImpl | 58 - org.apache.jackrabbit.oak-core -
> 1.5.17 | System user created: sling-i18n
> 2017-01-20T11:20:09,186 | INFO | Apache Sling Repository Startup Thread |
> AclVisitor | 101 - org.apache.sling.jcr.repoinit -
> 1.1.2 | Adding ACL 'allow' entry '[jcr:read]' for [sling-i18n] on [/]
> 2017-01-20T11:20:09,187 | DEBUG | Apache Sling Repository Startup Thread |
> PropertyIndex| 58 - org.apache.jackrabbit.oak-core -
> 1.5.17 | property cost for principalName is 2.0
> 2017-01-20T11:20:09,187 | DEBUG | Apache Sling Repository Startup Thread |
> QueryEngineImpl | 58 - org.apache.jackrabbit.oak-core -
> 1.5.17 | No alternatives found. Query: select
> [rep:Authorizable].[rep:principalName] as
> [rep:Authorizable.rep:principalName], [rep:Authorizable].[rep:authorizableId]
> as [rep:Authorizable.rep:authorizableId], [rep:Authorizable].[jcr:uuid] as
> [rep:Authorizable.jcr:uuid], [rep:Authorizable].[jcr:primaryType] as
> [rep:Authorizable.jcr:primaryType], [rep:Authorizable].[jcr:created] as
> [rep:Authorizable.jcr:created], [rep:Authorizable].[jcr:createdBy] as
> [rep:Authorizable.jcr:createdBy] from [rep:Authorizable] as
> [rep:Authorizable] where [rep:Authorizable].[rep:principalName] =
> $principalName
> 2017-01-20T11:20:09,187 | DEBUG | Apache Sling Repository Startup Thread |
> PropertyIndex| 58 - org.apache.jackrabbit.oak-core -
> 1.5.17 | property cost for principalName is 2.0
> 2017-01-20T11:20:09,188 | DEBUG | Apache Sling Repository Startup Thread |
> QueryEngineImpl | 58 - org.apache.jackrabbit.oak-core -
> 1.5.17 | No alternatives found. Query: select
> [rep:Authorizable].[rep:principalName] as
> [rep:Authorizable.rep:principalName], [rep:Authorizable].[rep:authorizableId]
> as [rep:Authorizable.rep:authorizableId], [rep:Authorizable].[jcr:uuid] as
> [rep:Authorizable.jcr:uuid], [rep:Authorizable].[jcr:primaryType] as
> [rep:Authorizable.jcr:primaryType], [rep:Authorizable].[jcr:created] as
> [rep:Authorizable.jcr:created], [rep:Authorizable].[jcr:createdBy] as
> [rep:Authorizable.jcr:createdBy] from [rep:Authorizable] as
> [rep:Authorizable] where [rep:Authorizable].[rep:principalName] =
> $principalName
>
[jira] [Commented] (OAK-5689) AbstractSecurityTest: enforce test-failure for traversal queries
[
https://issues.apache.org/jira/browse/OAK-5689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15876013#comment-15876013
]
Thomas Mueller commented on OAK-5689:
-
All tests from the above list fail for the same reason. The query is actually
{{/jcr:root/rep:security/rep:authorizables//element(*)[@rep:principalName]}}.
> AbstractSecurityTest: enforce test-failure for traversal queries
>
>
> Key: OAK-5689
> URL: https://issues.apache.org/jira/browse/OAK-5689
> Project: Jackrabbit Oak
> Issue Type: Test
> Components: core
>Reporter: angela
>Assignee: angela
> Fix For: 1.8
>
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-5689) AbstractSecurityTest: enforce test-failure for traversal queries
[
https://issues.apache.org/jira/browse/OAK-5689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15876006#comment-15876006
]
Thomas Mueller commented on OAK-5689:
-
For PrincipalProviderImplTest, the query is:
{noformat}
select [jcr:path], [jcr:score], * from [nt:base] as a
where [rep:principalName] is not null
and isdescendantnode(a, '/rep:security/rep:authorizables')
{noformat}
There is an index /oak:index/principalName on rep:principalName. But it is for
rep:Authorizable and not nt:base. Should the query use "from
\[rep:Authorizable\]"?
> AbstractSecurityTest: enforce test-failure for traversal queries
>
>
> Key: OAK-5689
> URL: https://issues.apache.org/jira/browse/OAK-5689
> Project: Jackrabbit Oak
> Issue Type: Test
> Components: core
>Reporter: angela
>Assignee: angela
> Fix For: 1.8
>
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-3498) DN can't be used as the group name in the external auth handler
[
https://issues.apache.org/jira/browse/OAK-3498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-3498:
Component/s: (was: auth-external)
auth-ldap
> DN can't be used as the group name in the external auth handler
> ---
>
> Key: OAK-3498
> URL: https://issues.apache.org/jira/browse/OAK-3498
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-ldap
>Affects Versions: 1.0.22, 1.2.7, 1.3.7
>Reporter: Tomek Rękawek
>Assignee: Tomek Rękawek
>Priority: Minor
> Fix For: 1.7.0
>
> Attachments: OAK-3498-1.0.patch, OAK-3498-trunk.patch
>
>
> One of the users wants to migrate his repository from Jackrabbit 2 to Oak. He
> uses LDAP for authentication. The LDAP synchronization in Jackrabbit 2 is
> configured in such manner, that both principal id and authorizable name is
> set to the DN (eg. {{CN=my-group,OU=abc,...}}).
> After migration to Oak LDAP users can't login. The reason is that during the
> login, the {{DefaultSyncContext}} tries to synchronize all groups memberships
> and create missing groups. By default it uses CN as the group name and tries
> to find it. It fails, because the migrated group has a name created with its
> DN. It assumes that the group doesn't exist and then wants to create it -
> which fails as well, because group with the given principal name already
> exists. As a result, the whole login process fails.
> The LDAP attribute to be used as the group name can be configured. However,
> the DN is not an attribute, so setting {{group.nameAttribute="dn"}} in
> {{LdapProviderConfig}} results in a {{NullPointerException}}.
> I think one thing can be improved here:
> 1. It should be possible to use DN as the {{group.nameAttribute}}.
> 2. -{{DefaultSyncContext}} should try to find a group using its principal
> name rather than group id.-
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-5740) deliver overflow change even without new commit
[ https://issues.apache.org/jira/browse/OAK-5740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15875975#comment-15875975 ] Vikas Saurabh commented on OAK-5740: The test case looks ok to me to show the point of the issue. That said, I'm still of the opinion that if this is observed only special case (e.g. controlled test case), then may be some util class/method (exposed?? in case some external observer want it!) would be ok. Of course, with the documented behavior. bq. the observation queue is configured to be very large I think the actual reason is that there are always commits that happen - update of ":async" node for example... may be even topology (although I don't know if that's true even in single-node-tar-setups too). > 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 >Priority: Minor > Attachments: OAK-5740.testcase.patch, OAK-5740.testcase.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.3.15#6346)
[jira] [Commented] (OAK-3134) Identify functionality offered by oak-run
[ https://issues.apache.org/jira/browse/OAK-3134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15875959#comment-15875959 ] angela commented on OAK-3134: - [~edivad], if we start looking at ways to move the benchmarks out of oak-run I would rather opt for an approach as mentioned by [~frm] on the mailing list. IMHO the benchmarks should live with the code they are intended to benchmark and not in a separate module. this would also solve the question wrt different branches/versions of the benchmarks. just moving them to a new _oak-benchmark_ module without addressing the underlying issue doesn't make sense to me... > Identify functionality offered by oak-run > - > > Key: OAK-3134 > URL: https://issues.apache.org/jira/browse/OAK-3134 > Project: Jackrabbit Oak > Issue Type: Task > Components: run >Reporter: Davide Giannella >Assignee: Davide Giannella > > oak-run reached the size of 50MB+ and offers indeed various functionalities > that could be moved to their own module. > This ticket is about to identify what oak-run currently offers and what/if > could be split. > ML thread: http://markmail.org/thread/w34bphrk57l7pkaz > || Functionality || Package || Module || > | Backup | | oak-operations| > | Check | | oak-operations| > | Checkpoints | | oak-operations| > | Compact | | oak-operations| > | Debug | | oak-operations| > | Explore | |oak-development | > | Groovy console | org.apache.jackrabbit.oak.console, > /oak-run/src/main/groovy/org/apache/jackrabbit/oak/console | oak-operations| > | Primary | | oak-development| > | Recovery | | oak-operations| > | Repair | | oak-operations| > | Restore | | oak-operations| > | Server | | oak-development| > | Standby | | oak-development| > | Upgrade | | oak-upgrade| > | micro-benchmark | org.apache.jackrabbit.oak.benchmark |oak-development | > | scalability benchmark | org.apache.jackrabbit.oak.scalability | > oak-development| > | DataStoreCacheUpgrade | | oak-operations | > | DataStoreCheck | | oak-operations | > | Garbage | | oak-operations | > | tarmkdiff | | oak-operations | > | tarmkrecovery | | oak-operations | > | graph | | oak-development | > | history | | oak-operations | > | index | | oak-operations | > | persistentcache | | oak-operations | > | resetclusterid | | oak-operations | > | threaddump | | oak-development | > | tika | | oak-operations | > Modules left after the actions: > **oak-development** > Used to group and execute all the tools used during development. > _deployed to maven:_ No. > **oak-operations** > Used to group and execute all the tools used normally in production > environment for tasks like maintenance & C. > _deployed to maven:_ Yes. > **oak-run** > Will group what's left after the split. > _deployed to maven:_ No. > **oak-upgrade** > Will group tools for upgrading/migrating from one repo/version to another > _deployed to maven:_ yes. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-5738) Potential NPE in LargeLdapProviderTest
[
https://issues.apache.org/jira/browse/OAK-5738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-5738:
Labels: (was: candidate_oak_1_0)
> Potential NPE in LargeLdapProviderTest
> --
>
> Key: OAK-5738
> URL: https://issues.apache.org/jira/browse/OAK-5738
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-ldap
>Affects Versions: 1.6.0
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
> Fix For: 1.2.24, 1.4.14, 1.7.0, 1.8, 1.6.1
>
> Attachments: OAK-5738.diff
>
>
> If test preparation fails, test teardown will fail with NPE:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.LargeLdapProviderTest.after(LargeLdapProviderTest.java:98)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (OAK-5738) Potential NPE in LargeLdapProviderTest
[
https://issues.apache.org/jira/browse/OAK-5738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15875693#comment-15875693
]
Julian Reschke edited comment on OAK-5738 at 2/21/17 12:52 PM:
---
trunk: [r1783855|http://svn.apache.org/r1783855]
1.6: [r1783864|http://svn.apache.org/r1783864]
1.4: [r1783871|http://svn.apache.org/r1783871]
1.2: [r1783885|http://svn.apache.org/r1783885]
was (Author: reschke):
trunk: [r1783855|http://svn.apache.org/r1783855]
1.6: [r1783864|http://svn.apache.org/r1783864]
1.4: [r1783871|http://svn.apache.org/r1783871]
> Potential NPE in LargeLdapProviderTest
> --
>
> Key: OAK-5738
> URL: https://issues.apache.org/jira/browse/OAK-5738
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-ldap
>Affects Versions: 1.6.0
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
> Labels: candidate_oak_1_0
> Fix For: 1.2.24, 1.4.14, 1.7.0, 1.8, 1.6.1
>
> Attachments: OAK-5738.diff
>
>
> If test preparation fails, test teardown will fail with NPE:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.LargeLdapProviderTest.after(LargeLdapProviderTest.java:98)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-5738) Potential NPE in LargeLdapProviderTest
[
https://issues.apache.org/jira/browse/OAK-5738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-5738:
Labels: candidate_oak_1_0 (was: candidate_oak_1_0 candidate_oak_1_2
candidate_oak_1_4)
> Potential NPE in LargeLdapProviderTest
> --
>
> Key: OAK-5738
> URL: https://issues.apache.org/jira/browse/OAK-5738
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-ldap
>Affects Versions: 1.6.0
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
> Labels: candidate_oak_1_0
> Fix For: 1.2.24, 1.4.14, 1.7.0, 1.8, 1.6.1
>
> Attachments: OAK-5738.diff
>
>
> If test preparation fails, test teardown will fail with NPE:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.LargeLdapProviderTest.after(LargeLdapProviderTest.java:98)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-5738) Potential NPE in LargeLdapProviderTest
[
https://issues.apache.org/jira/browse/OAK-5738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-5738:
Fix Version/s: 1.2.24
> Potential NPE in LargeLdapProviderTest
> --
>
> Key: OAK-5738
> URL: https://issues.apache.org/jira/browse/OAK-5738
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-ldap
>Affects Versions: 1.6.0
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
> Labels: candidate_oak_1_0
> Fix For: 1.2.24, 1.4.14, 1.7.0, 1.8, 1.6.1
>
> Attachments: OAK-5738.diff
>
>
> If test preparation fails, test teardown will fail with NPE:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.LargeLdapProviderTest.after(LargeLdapProviderTest.java:98)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-3134) Identify functionality offered by oak-run
[ https://issues.apache.org/jira/browse/OAK-3134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15875924#comment-15875924 ] Thomas Mueller commented on OAK-3134: - > Deploying 50MB+ at time can be challenging I see. > Most probably by simply creating a benchmark module where we put in all the > benchmarks and scalability could achieve most of the main goal around size. > ... So we could start by moving in this direction if everyone agrees. Of > course benchmark won't be deployed... +1 > If we go for oak-benchmarks; how are we going to deal with backports? I wonder if somebody _needs_ branch versions of oak-run.jar. I assume it's not needed usually, so maybe we can [disable the jar file from being built|http://stackoverflow.com/questions/12809559/remove-jar-created-by-default-in-maven] for branches, or only generated with a specific profile? > Identify functionality offered by oak-run > - > > Key: OAK-3134 > URL: https://issues.apache.org/jira/browse/OAK-3134 > Project: Jackrabbit Oak > Issue Type: Task > Components: run >Reporter: Davide Giannella >Assignee: Davide Giannella > > oak-run reached the size of 50MB+ and offers indeed various functionalities > that could be moved to their own module. > This ticket is about to identify what oak-run currently offers and what/if > could be split. > ML thread: http://markmail.org/thread/w34bphrk57l7pkaz > || Functionality || Package || Module || > | Backup | | oak-operations| > | Check | | oak-operations| > | Checkpoints | | oak-operations| > | Compact | | oak-operations| > | Debug | | oak-operations| > | Explore | |oak-development | > | Groovy console | org.apache.jackrabbit.oak.console, > /oak-run/src/main/groovy/org/apache/jackrabbit/oak/console | oak-operations| > | Primary | | oak-development| > | Recovery | | oak-operations| > | Repair | | oak-operations| > | Restore | | oak-operations| > | Server | | oak-development| > | Standby | | oak-development| > | Upgrade | | oak-upgrade| > | micro-benchmark | org.apache.jackrabbit.oak.benchmark |oak-development | > | scalability benchmark | org.apache.jackrabbit.oak.scalability | > oak-development| > | DataStoreCacheUpgrade | | oak-operations | > | DataStoreCheck | | oak-operations | > | Garbage | | oak-operations | > | tarmkdiff | | oak-operations | > | tarmkrecovery | | oak-operations | > | graph | | oak-development | > | history | | oak-operations | > | index | | oak-operations | > | persistentcache | | oak-operations | > | resetclusterid | | oak-operations | > | threaddump | | oak-development | > | tika | | oak-operations | > Modules left after the actions: > **oak-development** > Used to group and execute all the tools used during development. > _deployed to maven:_ No. > **oak-operations** > Used to group and execute all the tools used normally in production > environment for tasks like maintenance & C. > _deployed to maven:_ Yes. > **oak-run** > Will group what's left after the split. > _deployed to maven:_ No. > **oak-upgrade** > Will group tools for upgrading/migrating from one repo/version to another > _deployed to maven:_ yes. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (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:comment-tabpanel=15875922#comment-15875922
]
Tobias Bocanegra commented on OAK-5229:
---
but isn't this a backward incompatible change? especially, all the applications
that remove versioning and/or access control by removing the mixin would fail.
I think the risk of braking many application by changing this is behavior is
huge.
> 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
>Assignee: Alex Parvulescu
>Priority: Critical
> Fix For: 1.8, 1.6.1
>
> Attachments: OAK-5229.patch, OAK-5229-tests.patch, OAK-5229-v2.patch,
> OAK-5229-v3.patch, OAK-5229-v4.patch, OAK-5229-v5.patch
>
>
> 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.15#6346)
[jira] [Commented] (OAK-5704) VersionGC: reset _deletedOnce for documents that have been resurrected
[
https://issues.apache.org/jira/browse/OAK-5704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15875920#comment-15875920
]
Julian Reschke commented on OAK-5704:
-
bq. The patch adds the current document id to the info message logged in
collectDeletedDocuments(). I'm not sure how useful this is. The documents can
be in arbitrary order and might give a false sense of progress.
Ah. It was supposed to give a sense of progress; I assumed that the query
indeed returns the documents sorted by {{_id}} - it does in RDB, and also
everywhere else in the document store API.
bq. In resetDeletedOnce(), I would rather log "Proceeding to reset ...".
Ack.
bq. The UpdateOp sets the _deletedOnce flag to false. I would prefer a new
remove() method on UpdateOp. At least with MongoDB there is a sparse index on
_deletedOnce and we are only interested in documents that have this field set
to true. Documents with a _deletedOnce set to false would bloat the index. With
MongoDB 3.2 we could work around this with a partial index, but I think it
would be cleaner to remove the field.
Ack.
bq. The UpdateOp also updates the _modified field. This field is related to
revisioned entries on the document. I think it would be better to leave the
value as is, because there is no actual modification on the node related to
this update.
Yes, I wasn't sure about whether we should update _modified.
> VersionGC: reset _deletedOnce for documents that have been resurrected
> --
>
> Key: OAK-5704
> URL: https://issues.apache.org/jira/browse/OAK-5704
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: documentmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Attachments: OAK-5704.diff
>
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (OAK-4780) VersionGarbageCollector should be able to run incrementally
[
https://issues.apache.org/jira/browse/OAK-4780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15875870#comment-15875870
]
Julian Reschke edited comment on OAK-4780 at 2/21/17 12:46 PM:
---
Here's an approach that might be simpler but in the end achieves the same goal:
- set a limit for the collection phase, both for elapsed time and # of documents
- when limit reached, sort the collected IDs by modified date, and compute a
new upper limit so that half of the documents become out of range; throw these
entries away
- continue the collection with the smaller time window (this just needs an
internal API that allows to specify the _id to start with and assumes that the
query returns documents sorted by {{_id}})
- compute new limit for elapsed time (half of the original?)
Eventually, we should have a set of documents that we *can* garbage collect.
Finally, if maintenance window still open, just rerun the GC again.
was (Author: reschke):
Here's an approach that might be simpler but in the end achieves the same goal:
- set a limit for the collection phase, both for elapsed time and # of documents
- when limit reached, sort the collected IDs by modified date, and compute a
new upper limit so that half of the documents become out of range; throw these
entries away
- continue the collection with the smaller time window (this just needs an
internal API that allows to specify the _id to start with)
- compute new limit for elapsed time (half of the original?)
Eventually, we should have a set of documents that we *can* garbage collect.
Finally, if maintenance window still open, just rerun the GC again.
> VersionGarbageCollector should be able to run incrementally
> ---
>
> Key: OAK-4780
> URL: https://issues.apache.org/jira/browse/OAK-4780
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: core, documentmk
>Reporter: Julian Reschke
> Attachments: leafnodes.diff, leafnodes-v2.diff, leafnodes-v3.diff
>
>
> Right now, the documentmk's version garbage collection runs in several phases.
> It first collects the paths of candidate nodes, and only once this has been
> successfully finished, starts actually deleting nodes.
> This can be a problem when the regularly scheduled garbage collection is
> interrupted during the path collection phase, maybe due to other maintenance
> tasks. On the next run, the number of paths to be collected will be even
> bigger, thus making it even more likely to fail.
> We should think about a change in the logic that would allow the GC to run in
> chunks; maybe by partitioning the path space by top level directory.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-4780) VersionGarbageCollector should be able to run incrementally
[ https://issues.apache.org/jira/browse/OAK-4780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15875914#comment-15875914 ] Julian Reschke commented on OAK-4780: - bq. Julian Reschke any estimation how long that "eventually" will take on a never cleaned up 140TB cluster? And what would the GC do when this strategy does not lead to success during a maintenance interval? Too many variables in that question. bq. Measurements from large clusters showed that the collect phase of a GC can take as long as 4 hours - only processing changes from the last day. How would this work? Let's say there are 10 million node candidates daily. How would you configure the limit to operate in this environment? The proposal is about cases where the VGC hasn't been run regularly. If it *does* run regularly but still can't keep up, we have a different problem, right? bq. How would the same setting work in a cluster never cleaned up (worst case, I know)? There seem to be two choices: restrict ourselves to a maintenance window, which may mean that we'll never recover. Or allow to run beyond the maintenance window. (FWIW, we currently do not have a defined window, just an interval and the hope that one run has finished before the next is supposed to start) > VersionGarbageCollector should be able to run incrementally > --- > > Key: OAK-4780 > URL: https://issues.apache.org/jira/browse/OAK-4780 > Project: Jackrabbit Oak > Issue Type: Task > Components: core, documentmk >Reporter: Julian Reschke > Attachments: leafnodes.diff, leafnodes-v2.diff, leafnodes-v3.diff > > > Right now, the documentmk's version garbage collection runs in several phases. > It first collects the paths of candidate nodes, and only once this has been > successfully finished, starts actually deleting nodes. > This can be a problem when the regularly scheduled garbage collection is > interrupted during the path collection phase, maybe due to other maintenance > tasks. On the next run, the number of paths to be collected will be even > bigger, thus making it even more likely to fail. > We should think about a change in the logic that would allow the GC to run in > chunks; maybe by partitioning the path space by top level directory. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (OAK-4780) VersionGarbageCollector should be able to run incrementally
[ https://issues.apache.org/jira/browse/OAK-4780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15875870#comment-15875870 ] Julian Reschke edited comment on OAK-4780 at 2/21/17 12:32 PM: --- Here's an approach that might be simpler but in the end achieves the same goal: - set a limit for the collection phase, both for elapsed time and # of documents - when limit reached, sort the collected IDs by modified date, and compute a new upper limit so that half of the documents become out of range; throw these entries away - continue the collection with the smaller time window (this just needs an internal API that allows to specify the _id to start with) - compute new limit for elapsed time (half of the original?) Eventually, we should have a set of documents that we *can* garbage collect. Finally, if maintenance window still open, just rerun the GC again. was (Author: reschke): Here's an approach that might be simpler but in the end achieves the same goal: - set a limit for the collection phase, both for elapsed time and # of documents - when limit reached, sort the collected IDs by modified date, and compute a new upper limit so that half of the documents become out of range; throw these entries as well - continue the collection with the smaller time window (this just needs an internal API that allows to specify the _id to start with) - compute new limit for elapsed time (half of the original?) Eventually, we should have a set of documents that we *can* garbage collect. Finally, if maintenance window still open, just rerun the GC again. > VersionGarbageCollector should be able to run incrementally > --- > > Key: OAK-4780 > URL: https://issues.apache.org/jira/browse/OAK-4780 > Project: Jackrabbit Oak > Issue Type: Task > Components: core, documentmk >Reporter: Julian Reschke > Attachments: leafnodes.diff, leafnodes-v2.diff, leafnodes-v3.diff > > > Right now, the documentmk's version garbage collection runs in several phases. > It first collects the paths of candidate nodes, and only once this has been > successfully finished, starts actually deleting nodes. > This can be a problem when the regularly scheduled garbage collection is > interrupted during the path collection phase, maybe due to other maintenance > tasks. On the next run, the number of paths to be collected will be even > bigger, thus making it even more likely to fail. > We should think about a change in the logic that would allow the GC to run in > chunks; maybe by partitioning the path space by top level directory. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-5704) VersionGC: reset _deletedOnce for documents that have been resurrected
[ https://issues.apache.org/jira/browse/OAK-5704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15875908#comment-15875908 ] Marcel Reutegger commented on OAK-5704: --- I like the idea of resetting the deletedOnce flag. A couple of comments about the patch: - The patch adds the current document id to the info message logged in collectDeletedDocuments(). I'm not sure how useful this is. The documents can be in arbitrary order and might give a false sense of progress. - In resetDeletedOnce(), I would rather log "Proceeding to reset ...". - The UpdateOp sets the _deletedOnce flag to false. I would prefer a new remove() method on UpdateOp. At least with MongoDB there is a sparse index on _deletedOnce and we are only interested in documents that have this field set to true. Documents with a _deletedOnce set to false would bloat the index. With MongoDB 3.2 we could work around this with a partial index, but I think it would be cleaner to remove the field. - The UpdateOp also updates the _modified field. This field is related to revisioned entries on the document. I think it would be better to leave the value as is, because there is no actual modification on the node related to this update. > VersionGC: reset _deletedOnce for documents that have been resurrected > -- > > Key: OAK-5704 > URL: https://issues.apache.org/jira/browse/OAK-5704 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Attachments: OAK-5704.diff > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-4780) VersionGarbageCollector should be able to run incrementally
[ https://issues.apache.org/jira/browse/OAK-4780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15875897#comment-15875897 ] Stefan Eissing commented on OAK-4780: - [~reschke] any estimation how long that "eventually" will take on a never cleaned up 140TB cluster? And what would the GC do when this strategy does not lead to success during a maintenance interval? Measurements from large clusters showed that the collect phase of a GC can take as long as 4 hours - only processing changes from the last day. How would this work? Let's say there are 10 million node candidates daily. How would you configure the limit to operate in this environment? How would the same setting work in a cluster never cleaned up (worst case, I know)? > VersionGarbageCollector should be able to run incrementally > --- > > Key: OAK-4780 > URL: https://issues.apache.org/jira/browse/OAK-4780 > Project: Jackrabbit Oak > Issue Type: Task > Components: core, documentmk >Reporter: Julian Reschke > Attachments: leafnodes.diff, leafnodes-v2.diff, leafnodes-v3.diff > > > Right now, the documentmk's version garbage collection runs in several phases. > It first collects the paths of candidate nodes, and only once this has been > successfully finished, starts actually deleting nodes. > This can be a problem when the regularly scheduled garbage collection is > interrupted during the path collection phase, maybe due to other maintenance > tasks. On the next run, the number of paths to be collected will be even > bigger, thus making it even more likely to fail. > We should think about a change in the logic that would allow the GC to run in > chunks; maybe by partitioning the path space by top level directory. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-5612) Test failure: org.apache.jackrabbit.oak.run.osgi.DocumentNodeStoreConfigTest.testRDBDocumentStoreRestart
[ https://issues.apache.org/jira/browse/OAK-5612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-5612: Affects Version/s: 1.0.37 1.2.23 1.6.0 > Test failure: > org.apache.jackrabbit.oak.run.osgi.DocumentNodeStoreConfigTest.testRDBDocumentStoreRestart > > > Key: OAK-5612 > URL: https://issues.apache.org/jira/browse/OAK-5612 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration, pojosr >Affects Versions: 1.0.37, 1.2.23, 1.4.13, 1.6.0 >Reporter: Hudson >Assignee: Julian Reschke > Labels: test-failure, windows > Attachments: console_output.txt, 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.8 > (latest),nsfixtures=SEGMENT_MK,profile=unittesting #1412 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.8 (latest),nsfixtures=SEGMENT_MK,profile=unittesting > #1412|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=SEGMENT_MK,profile=unittesting/1412/] > [console > log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=SEGMENT_MK,profile=unittesting/1412/console] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-5612) Test failure: org.apache.jackrabbit.oak.run.osgi.DocumentNodeStoreConfigTest.testRDBDocumentStoreRestart
[ https://issues.apache.org/jira/browse/OAK-5612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15875889#comment-15875889 ] Julian Reschke commented on OAK-5612: - might be timing related > Test failure: > org.apache.jackrabbit.oak.run.osgi.DocumentNodeStoreConfigTest.testRDBDocumentStoreRestart > > > Key: OAK-5612 > URL: https://issues.apache.org/jira/browse/OAK-5612 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration, pojosr >Affects Versions: 1.4.13 >Reporter: Hudson >Assignee: Julian Reschke > Labels: test-failure, windows > Attachments: console_output.txt, 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.8 > (latest),nsfixtures=SEGMENT_MK,profile=unittesting #1412 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.8 (latest),nsfixtures=SEGMENT_MK,profile=unittesting > #1412|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=SEGMENT_MK,profile=unittesting/1412/] > [console > log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=SEGMENT_MK,profile=unittesting/1412/console] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (OAK-5612) Test failure: org.apache.jackrabbit.oak.run.osgi.DocumentNodeStoreConfigTest.testRDBDocumentStoreRestart
[ https://issues.apache.org/jira/browse/OAK-5612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke reassigned OAK-5612: --- Assignee: Julian Reschke > Test failure: > org.apache.jackrabbit.oak.run.osgi.DocumentNodeStoreConfigTest.testRDBDocumentStoreRestart > > > Key: OAK-5612 > URL: https://issues.apache.org/jira/browse/OAK-5612 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration, pojosr >Affects Versions: 1.4.13 >Reporter: Hudson >Assignee: Julian Reschke > Labels: test-failure, windows > Attachments: console_output.txt, 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.8 > (latest),nsfixtures=SEGMENT_MK,profile=unittesting #1412 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.8 (latest),nsfixtures=SEGMENT_MK,profile=unittesting > #1412|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=SEGMENT_MK,profile=unittesting/1412/] > [console > log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=SEGMENT_MK,profile=unittesting/1412/console] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-4780) VersionGarbageCollector should be able to run incrementally
[ https://issues.apache.org/jira/browse/OAK-4780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15875870#comment-15875870 ] Julian Reschke commented on OAK-4780: - Here's an approach that might be simpler but in the end achieves the same goal: - set a limit for the collection phase, both for elapsed time and # of documents - when limit reached, sort the collected IDs by modified date, and compute a new upper limit so that half of the documents become out of range; throw these entries as well - continue the collection with the smaller time window (this just needs an internal API that allows to specify the _id to start with) - compute new limit for elapsed time (half of the original?) Eventually, we should have a set of documents that we *can* garbage collect. Finally, if maintenance window still open, just rerun the GC again. > VersionGarbageCollector should be able to run incrementally > --- > > Key: OAK-4780 > URL: https://issues.apache.org/jira/browse/OAK-4780 > Project: Jackrabbit Oak > Issue Type: Task > Components: core, documentmk >Reporter: Julian Reschke > Attachments: leafnodes.diff, leafnodes-v2.diff, leafnodes-v3.diff > > > Right now, the documentmk's version garbage collection runs in several phases. > It first collects the paths of candidate nodes, and only once this has been > successfully finished, starts actually deleting nodes. > This can be a problem when the regularly scheduled garbage collection is > interrupted during the path collection phase, maybe due to other maintenance > tasks. On the next run, the number of paths to be collected will be even > bigger, thus making it even more likely to fail. > We should think about a change in the logic that would allow the GC to run in > chunks; maybe by partitioning the path space by top level directory. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (OAK-5738) Potential NPE in LargeLdapProviderTest
[
https://issues.apache.org/jira/browse/OAK-5738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15875693#comment-15875693
]
Julian Reschke edited comment on OAK-5738 at 2/21/17 11:55 AM:
---
trunk: [r1783855|http://svn.apache.org/r1783855]
1.6: [r1783864|http://svn.apache.org/r1783864]
1.4: [r1783871|http://svn.apache.org/r1783871]
was (Author: reschke):
trunk: [r1783855|http://svn.apache.org/r1783855]
1.6: [r1783864|http://svn.apache.org/r1783864]
> Potential NPE in LargeLdapProviderTest
> --
>
> Key: OAK-5738
> URL: https://issues.apache.org/jira/browse/OAK-5738
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-ldap
>Affects Versions: 1.6.0
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
> Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4
> Fix For: 1.4.14, 1.7.0, 1.8, 1.6.1
>
> Attachments: OAK-5738.diff
>
>
> If test preparation fails, test teardown will fail with NPE:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.LargeLdapProviderTest.after(LargeLdapProviderTest.java:98)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-5738) Potential NPE in LargeLdapProviderTest
[
https://issues.apache.org/jira/browse/OAK-5738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-5738:
Fix Version/s: 1.4.14
> Potential NPE in LargeLdapProviderTest
> --
>
> Key: OAK-5738
> URL: https://issues.apache.org/jira/browse/OAK-5738
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-ldap
>Affects Versions: 1.6.0
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
> Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4
> Fix For: 1.4.14, 1.7.0, 1.8, 1.6.1
>
> Attachments: OAK-5738.diff
>
>
> If test preparation fails, test teardown will fail with NPE:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.LargeLdapProviderTest.after(LargeLdapProviderTest.java:98)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (OAK-5740) deliver overflow change even without new commit
[ https://issues.apache.org/jira/browse/OAK-5740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15875820#comment-15875820 ] Stefan Egli edited comment on OAK-5740 at 2/21/17 11:24 AM: Attaching [^OAK-5740.testcase.patch] (2nd version is the one which actually fails) which contains a suggested test case. [~catholicon], wdyt? was (Author: egli): Attaching [^OAK-5740.testcase.patch] which contains a suggested test case. [~catholicon], wdyt? > 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 >Priority: Minor > Attachments: OAK-5740.testcase.patch, OAK-5740.testcase.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.3.15#6346)
[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.testcase.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 >Priority: Minor > Attachments: OAK-5740.testcase.patch, OAK-5740.testcase.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.3.15#6346)
[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.testcase.patch Attaching [^OAK-5740.testcase.patch] which contains a suggested test case. [~catholicon], wdyt? > 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 >Priority: Minor > Attachments: OAK-5740.testcase.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.3.15#6346)
[jira] [Created] (OAK-5740) deliver overflow change even without new commit
Stefan Egli created OAK-5740: Summary: 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 Priority: Minor 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.3.15#6346)
[jira] [Comment Edited] (OAK-5738) Potential NPE in LargeLdapProviderTest
[
https://issues.apache.org/jira/browse/OAK-5738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15875693#comment-15875693
]
Julian Reschke edited comment on OAK-5738 at 2/21/17 10:52 AM:
---
trunk: [r1783855|http://svn.apache.org/r1783855]
1.6: [r1783864|http://svn.apache.org/r1783864]
was (Author: reschke):
trunk: [r1783855|http://svn.apache.org/r1783855]
> Potential NPE in LargeLdapProviderTest
> --
>
> Key: OAK-5738
> URL: https://issues.apache.org/jira/browse/OAK-5738
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-ldap
>Affects Versions: 1.6.0
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
> Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4
> Fix For: 1.7.0, 1.8, 1.6.1
>
> Attachments: OAK-5738.diff
>
>
> If test preparation fails, test teardown will fail with NPE:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.LargeLdapProviderTest.after(LargeLdapProviderTest.java:98)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-5738) Potential NPE in LargeLdapProviderTest
[
https://issues.apache.org/jira/browse/OAK-5738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-5738:
Labels: candidate_oak_1_0 candidate_oak_1_2 candidate_oak_1_4 (was:
candidate_oak_1_0 candidate_oak_1_2 candidate_oak_1_4 candidate_oak_1_6)
> Potential NPE in LargeLdapProviderTest
> --
>
> Key: OAK-5738
> URL: https://issues.apache.org/jira/browse/OAK-5738
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-ldap
>Affects Versions: 1.6.0
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
> Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4
> Fix For: 1.7.0, 1.8, 1.6.1
>
> Attachments: OAK-5738.diff
>
>
> If test preparation fails, test teardown will fail with NPE:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.LargeLdapProviderTest.after(LargeLdapProviderTest.java:98)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-5738) Potential NPE in LargeLdapProviderTest
[
https://issues.apache.org/jira/browse/OAK-5738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-5738:
Fix Version/s: 1.6.1
> Potential NPE in LargeLdapProviderTest
> --
>
> Key: OAK-5738
> URL: https://issues.apache.org/jira/browse/OAK-5738
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-ldap
>Affects Versions: 1.6.0
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
> Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4
> Fix For: 1.7.0, 1.8, 1.6.1
>
> Attachments: OAK-5738.diff
>
>
> If test preparation fails, test teardown will fail with NPE:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.LargeLdapProviderTest.after(LargeLdapProviderTest.java:98)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-5738) Potential NPE in LargeLdapProviderTest
[
https://issues.apache.org/jira/browse/OAK-5738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-5738:
Labels: candidate_oak_1_0 candidate_oak_1_2 candidate_oak_1_4
candidate_oak_1_6 (was: )
> Potential NPE in LargeLdapProviderTest
> --
>
> Key: OAK-5738
> URL: https://issues.apache.org/jira/browse/OAK-5738
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-ldap
>Affects Versions: 1.6.0
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
> Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4,
> candidate_oak_1_6
> Fix For: 1.7.0, 1.8
>
> Attachments: OAK-5738.diff
>
>
> If test preparation fails, test teardown will fail with NPE:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.LargeLdapProviderTest.after(LargeLdapProviderTest.java:98)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (OAK-5738) Potential NPE in LargeLdapProviderTest
[
https://issues.apache.org/jira/browse/OAK-5738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke resolved OAK-5738.
-
Resolution: Fixed
Fix Version/s: 1.8
1.7.0
trunk: [r1783855|http://svn.apache.org/r1783855]
> Potential NPE in LargeLdapProviderTest
> --
>
> Key: OAK-5738
> URL: https://issues.apache.org/jira/browse/OAK-5738
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-ldap
>Affects Versions: 1.6.0
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
> Fix For: 1.7.0, 1.8
>
> Attachments: OAK-5738.diff
>
>
> If test preparation fails, test teardown will fail with NPE:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.LargeLdapProviderTest.after(LargeLdapProviderTest.java:98)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-5739) Misleading traversal warning for spellcheck queries without index
[
https://issues.apache.org/jira/browse/OAK-5739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-5739:
Component/s: query
> Misleading traversal warning for spellcheck queries without index
> -
>
> Key: OAK-5739
> URL: https://issues.apache.org/jira/browse/OAK-5739
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
> Fix For: 1.8
>
>
> In OAK-4313 we avoid traversal for native queries, but we see in some cases
> traversal warnings as follows:
> {noformat}
> org.apache.jackrabbit.oak.query.QueryImpl query plan
> [nt:base] as [a] /* traverse "" where (spellcheck([a], 'NothingToFind'))
> and (issamenode([a], [/])) */
> org.apache.jackrabbit.oak.query.QueryImpl Traversal query (query without
> index):
> select [jcr:path], [jcr:score], [rep:spellcheck()] from [nt:base] as a where
> spellcheck('NothingToFind')
> and issamenode(a, '/')
> /* xpath: /jcr:root
> [rep:spellcheck('NothingToFind')]/(rep:spellcheck()) */;
> consider creating an index
> {noformat}
> This warning is misleading. If no index is available, then either the query
> should fail, or the warning should say that the query result is not correct
> because traversal is used.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-5739) Misleading traversal warning for spellcheck queries without index
[
https://issues.apache.org/jira/browse/OAK-5739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-5739:
Fix Version/s: 1.8
> Misleading traversal warning for spellcheck queries without index
> -
>
> Key: OAK-5739
> URL: https://issues.apache.org/jira/browse/OAK-5739
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
> Fix For: 1.8
>
>
> In OAK-4313 we avoid traversal for native queries, but we see in some cases
> traversal warnings as follows:
> {noformat}
> org.apache.jackrabbit.oak.query.QueryImpl query plan
> [nt:base] as [a] /* traverse "" where (spellcheck([a], 'NothingToFind'))
> and (issamenode([a], [/])) */
> org.apache.jackrabbit.oak.query.QueryImpl Traversal query (query without
> index):
> select [jcr:path], [jcr:score], [rep:spellcheck()] from [nt:base] as a where
> spellcheck('NothingToFind')
> and issamenode(a, '/')
> /* xpath: /jcr:root
> [rep:spellcheck('NothingToFind')]/(rep:spellcheck()) */;
> consider creating an index
> {noformat}
> This warning is misleading. If no index is available, then either the query
> should fail, or the warning should say that the query result is not correct
> because traversal is used.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-5738) Potential NPE in LargeLdapProviderTest
[
https://issues.apache.org/jira/browse/OAK-5738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-5738:
Attachment: OAK-5738.diff
> Potential NPE in LargeLdapProviderTest
> --
>
> Key: OAK-5738
> URL: https://issues.apache.org/jira/browse/OAK-5738
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-ldap
>Affects Versions: 1.6.0
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
> Attachments: OAK-5738.diff
>
>
> If test preparation fails, test teardown will fail with NPE:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.LargeLdapProviderTest.after(LargeLdapProviderTest.java:98)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (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:comment-tabpanel=15875581#comment-15875581
]
Alex Parvulescu commented on OAK-5229:
--
bq. Especially the reference properties of mix:Versionable should be removed,
since they might now point to a node in the version store that no longer exists.
To clarify here, if you don't take care of manually removing the extra
properties, the commit would _fail_ because of the existing references (see the
{{MixinTest}} tests in the patch). At no point would you have broken links, so
the repo remains consistent from this pov.
> 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
>Assignee: Alex Parvulescu
>Priority: Critical
> Fix For: 1.8, 1.6.1
>
> Attachments: OAK-5229.patch, OAK-5229-tests.patch, OAK-5229-v2.patch,
> OAK-5229-v3.patch, OAK-5229-v4.patch, OAK-5229-v5.patch
>
>
> 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.15#6346)
