[jira] [Commented] (OAK-1962) Fix and Improve Locking
[ https://issues.apache.org/jira/browse/OAK-1962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16102724#comment-16102724 ] Julian Reschke commented on OAK-1962: - Dropped the "fixVersion = 1.8", because we do not plan to "fix" locking anymore. > Fix and Improve Locking > --- > > Key: OAK-1962 > URL: https://issues.apache.org/jira/browse/OAK-1962 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, jcr >Affects Versions: 1.0 >Reporter: angela > Labels: technical_debt > > as discussed during our biweekly planning session, we are having the > following locking related use case in our product: > a page (which is an aggregation of nodes and properties) must be freezed > (prevented from being edited/modified/deleted) during the period of a > dedicated review (which in our case is triggered by a workflow) before the > page then is either published or reopened for further changes. > for this feature locking would be a perfect match but with the current > implementation in oak it's not possible to remove the lock token from a > given session and make sure it's no longer recognizes as lock owner; in > particular with the simple-locking feature which we introduced in order to > cope with the situation that in our product sessions are living just for the > time of a single request. > is was therefore thinking about ways to address this, keeping the > simple-locking requirement in mind while at the same time improving > compliance with the JCR specification. my suggestion as follows: > - use a dedicated hidden and write protected location the repository to store > the lock information independent of the protected properties defined by > mix:lockable which are just for information purpose (that would be the > replacement for the lock-related file we had in jackrabbit 2.x) > - format: simple lookup consisting of userId + associated lock tokens > - in case of simple locking LockManager#getLockTokens would make use of that > map even if the lock tokens have NOT been explicitly added to the Session > either upon LockManager#lock or LockManager#addLockToken > - in the default (non-simple case) LockManager#getLockTokens would work as > specified and the lookup would only be used for maintaining and enforcing the > lock related information) > - LockManager#removeLockToken removes the token from the lookup thus > effectively revoking the lock ownership from the given Session and thus > preventing it from performing further editing... even in the simple-locking > case > - LockManager#addLockToken results in a modification of the lookup table as > well depending on the API contract (i.e. verifying if the lock token would be > shared... i don't remember exactly if that's accepted by the specification) > - LockManager#isLockOwner no longer needs to perform a cheap hack comparing > the jcr:lockOwner property with the sessions userId but could really enforce > ownership based on the internal lock information stored in the repository in > which case getLockTokens would really reflect the ownership for open-scoped > locks; furthermore the 'jcr:lockOwner' information could be to what is > specified by the API consumer upon LockManager#lock as it is no longer used > for enforcing the locks. > in addition: > - we could generated proper lock tokens instead of just using the node id > and again keep those in a hidden (or otherwise protected) location in the > system. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-4693) Impersonating users can't unlock nodes
[
https://issues.apache.org/jira/browse/OAK-4693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-4693:
Issue Type: Wish (was: Bug)
> Impersonating users can't unlock nodes
> --
>
> Key: OAK-4693
> URL: https://issues.apache.org/jira/browse/OAK-4693
> Project: Jackrabbit Oak
> Issue Type: Wish
> Components: jcr
>Affects Versions: 1.5.8
>Reporter: Zygmunt Wiercioch
>
> An impersonating user can lock a node, but can't unlock a node. Relaxed
> locking was introduced in: https://issues.apache.org/jira/browse/OAK-1329,
> but SessionImpl.impersonate() can't pass the attributes to the
> RepositoryImpl.login() method.
> {code}
> return getRepository().login(impCreds, sd.getWorkspaceName());
> {code}
> An attempt to unlock a node when impersonating will result in a failure
> since "oak.relaxed-locking" is not set.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-1962) Fix and Improve Locking
[ https://issues.apache.org/jira/browse/OAK-1962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-1962: Fix Version/s: (was: 1.8) > Fix and Improve Locking > --- > > Key: OAK-1962 > URL: https://issues.apache.org/jira/browse/OAK-1962 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, jcr >Affects Versions: 1.0 >Reporter: angela > Labels: technical_debt > > as discussed during our biweekly planning session, we are having the > following locking related use case in our product: > a page (which is an aggregation of nodes and properties) must be freezed > (prevented from being edited/modified/deleted) during the period of a > dedicated review (which in our case is triggered by a workflow) before the > page then is either published or reopened for further changes. > for this feature locking would be a perfect match but with the current > implementation in oak it's not possible to remove the lock token from a > given session and make sure it's no longer recognizes as lock owner; in > particular with the simple-locking feature which we introduced in order to > cope with the situation that in our product sessions are living just for the > time of a single request. > is was therefore thinking about ways to address this, keeping the > simple-locking requirement in mind while at the same time improving > compliance with the JCR specification. my suggestion as follows: > - use a dedicated hidden and write protected location the repository to store > the lock information independent of the protected properties defined by > mix:lockable which are just for information purpose (that would be the > replacement for the lock-related file we had in jackrabbit 2.x) > - format: simple lookup consisting of userId + associated lock tokens > - in case of simple locking LockManager#getLockTokens would make use of that > map even if the lock tokens have NOT been explicitly added to the Session > either upon LockManager#lock or LockManager#addLockToken > - in the default (non-simple case) LockManager#getLockTokens would work as > specified and the lookup would only be used for maintaining and enforcing the > lock related information) > - LockManager#removeLockToken removes the token from the lookup thus > effectively revoking the lock ownership from the given Session and thus > preventing it from performing further editing... even in the simple-locking > case > - LockManager#addLockToken results in a modification of the lookup table as > well depending on the API contract (i.e. verifying if the lock token would be > shared... i don't remember exactly if that's accepted by the specification) > - LockManager#isLockOwner no longer needs to perform a cheap hack comparing > the jcr:lockOwner property with the sessions userId but could really enforce > ownership based on the internal lock information stored in the repository in > which case getLockTokens would really reflect the ownership for open-scoped > locks; furthermore the 'jcr:lockOwner' information could be to what is > specified by the API consumer upon LockManager#lock as it is no longer used > for enforcing the locks. > in addition: > - we could generated proper lock tokens instead of just using the node id > and again keep those in a hidden (or otherwise protected) location in the > system. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-6496) Build Jackrabbit Oak #576 failed
[ https://issues.apache.org/jira/browse/OAK-6496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101939#comment-16101939 ] Hudson commented on OAK-6496: - Build is still failing. Failed run: [Jackrabbit Oak #582|https://builds.apache.org/job/Jackrabbit%20Oak/582/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/582/console] > Build Jackrabbit Oak #576 failed > > > Key: OAK-6496 > URL: https://issues.apache.org/jira/browse/OAK-6496 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson > > Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/ > The build Jackrabbit Oak #576 has failed. > First failed run: [Jackrabbit Oak > #576|https://builds.apache.org/job/Jackrabbit%20Oak/576/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/576/console] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6495) Fallback to classic diff when journal is broken
[ https://issues.apache.org/jira/browse/OAK-6495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-6495: -- Labels: candidate_oak_1_0 candidate_oak_1_2 (was: candidate_oak_1_0 candidate_oak_1_2 candidate_oak_1_4) Fix Version/s: 1.4.18 > Fallback to classic diff when journal is broken > --- > > Key: OAK-6495 > URL: https://issues.apache.org/jira/browse/OAK-6495 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Labels: candidate_oak_1_0, candidate_oak_1_2 > Fix For: 1.8, 1.7.5, 1.6.4, 1.4.18 > > > The DocumentNodeStore diff mechanism should fallback to the classic > implementation when the journal is broken. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (OAK-6495) Fallback to classic diff when journal is broken
[ https://issues.apache.org/jira/browse/OAK-6495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101641#comment-16101641 ] Marcel Reutegger edited comment on OAK-6495 at 7/26/17 3:28 PM: Merged into branches: - 1.6: http://svn.apache.org/r1803035 - 1.4: http://svn.apache.org/r1803063 was (Author: mreutegg): Merged into branches: - 1.6: http://svn.apache.org/r1803035 > Fallback to classic diff when journal is broken > --- > > Key: OAK-6495 > URL: https://issues.apache.org/jira/browse/OAK-6495 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4 > Fix For: 1.8, 1.7.5, 1.6.4 > > > The DocumentNodeStore diff mechanism should fallback to the classic > implementation when the journal is broken. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-5228) Incorrect minTimestamp in DocumentNodeStore.diffImpl()
[ https://issues.apache.org/jira/browse/OAK-5228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-5228: -- Labels: (was: candidate_oak_1_4) Fix Version/s: 1.4.18 Merged into 1.4 branch: http://svn.apache.org/r1803057 > Incorrect minTimestamp in DocumentNodeStore.diffImpl() > -- > > Key: OAK-5228 > URL: https://issues.apache.org/jira/browse/OAK-5228 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, documentmk >Affects Versions: 1.4.8, 1.5.6 >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Fix For: 1.5.15, 1.6.0, 1.4.18 > > > The minTimestamp is calculated incorrectly to decide whether the journal can > be used for the diff. The timestamp must be calculated from the root > revisions of the node states to compare and not the revisions they were last > modified. The last modified revision can potentially point very far into the > past and result in a fall back to a more expensive diffManyChildren(). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-5519) Skip problematic binaries instead of blocking indexing
[ https://issues.apache.org/jira/browse/OAK-5519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101666#comment-16101666 ] Thomas Mueller commented on OAK-5519: - [~catholicon] and [~chetanm] I think we should try the "Memory of bad file" solution, if that's simple. I assume we could write a test case first, that uses a "custom" Tika config as documented in http://jackrabbit.apache.org/oak/docs/query/lucene.html#Tika_Config, custom in that it does nothing except throw an exception / error / out of memory error every time. Then try if this runs into an endless loop. Then remember the file if it fails *three times* in a row. I think it would be better to wait three times, because the first time might be due to a non-repeatable problems (out of memory caused by another thread). > Skip problematic binaries instead of blocking indexing > -- > > Key: OAK-5519 > URL: https://issues.apache.org/jira/browse/OAK-5519 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: indexing >Reporter: Alexander Klimetschek > Labels: resilience > Fix For: 1.8 > > > If a text extraction is blocked (weird PDF) or a blob cannot be found in the > datastore or any other error upon indexing one item from the repository that > is outside the scope of the indexer, it currently halts the indexing (lane). > Thus one item (that maybe isn't important to the users at all) can block the > indexing of other, new content (that might be important to users), and it > always requires manual intervention (which is also not easy and requires oak > experts). > Instead, the item could be remembered in a known issue list, proper warnings > given, and indexing continue. Maintenance operations should be available to > come back to reindex these, or the indexer could automatically retry after > some time. This would allow normal user activity to go on without manual > intervention, and solving the problem (if it's isolated to some binaries) can > be deferred. > I think the line should probably be drawn for binary properties. Not sure if > other JCR property types could trigger a similar issue, and if a failure in > them might actually warrant a halt, as it could lead to an "incorrect" index, > if these properties are important. But maybe the line is simply a try & catch > around "full text extraction". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-5970) (Re-)Indexing: estimate progress / ETA
[ https://issues.apache.org/jira/browse/OAK-5970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101645#comment-16101645 ] Thomas Mueller commented on OAK-5970: - [~chetanm], with reindexing using oak-run, what is the current plan / state? I think JMX is not needed in this case. > (Re-)Indexing: estimate progress / ETA > -- > > Key: OAK-5970 > URL: https://issues.apache.org/jira/browse/OAK-5970 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: indexing >Reporter: Thomas Mueller >Assignee: Chetan Mehrotra > Fix For: 1.8 > > > Reindexing can take a long time, so it would be good if we can estimate where > we are at (for example in percent of the relevant number of nodes). It might > also be possible to estimate when indexing will be done, and the current path. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6495) Fallback to classic diff when journal is broken
[ https://issues.apache.org/jira/browse/OAK-6495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-6495: -- 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) Fix Version/s: 1.6.4 Merged into branches: - 1.6: http://svn.apache.org/r1803035 > Fallback to classic diff when journal is broken > --- > > Key: OAK-6495 > URL: https://issues.apache.org/jira/browse/OAK-6495 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4 > Fix For: 1.8, 1.7.5, 1.6.4 > > > The DocumentNodeStore diff mechanism should fallback to the classic > implementation when the journal is broken. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6462) Incorrect memory calculation for bundled node states
[ https://issues.apache.org/jira/browse/OAK-6462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-6462: -- Labels: (was: candidate_oak_1_6) Fix Version/s: 1.6.4 Merged into 1.6 branch: http://svn.apache.org/r1803042 > Incorrect memory calculation for bundled node states > > > Key: OAK-6462 > URL: https://issues.apache.org/jira/browse/OAK-6462 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, documentmk >Affects Versions: 1.6.0 >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Fix For: 1.8, 1.7.4, 1.6.4 > > > OAK-1312 introduced bundling of nodes into a document and enabled the feature > for nt:file nodes. A DocumentNodeState of type nt:file now has an incorrect > memory calculation because the node state references a BundlingContext which > also references the binary property reference. Such a node state is now much > heavier than before and can cause OOME. > This is a clone of OAK-5226, which was supposed to fix the described issue, > however it turns out the fix is not sufficient and memory calculation is > still incorrect for bundled nodes/properties. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-2808) Active deletion of 'deleted' Lucene index files from DataStore without relying on full scale Blob GC
[ https://issues.apache.org/jira/browse/OAK-2808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-2808: Labels: datastore doc-impacting performance (was: datastore performance) > Active deletion of 'deleted' Lucene index files from DataStore without > relying on full scale Blob GC > > > Key: OAK-2808 > URL: https://issues.apache.org/jira/browse/OAK-2808 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Chetan Mehrotra >Assignee: Vikas Saurabh > Labels: datastore, doc-impacting, performance > Fix For: 1.8, 1.7.1 > > Attachments: copyonread-stats.png, OAK-2808-1.patch > > > With storing of Lucene index files within DataStore our usage pattern > of DataStore has changed between JR2 and Oak. > With JR2 the writes were mostly application based i.e. if application > stores a pdf/image file then that would be stored in DataStore. JR2 by > default would not write stuff to DataStore. Further in deployment > where large number of binary content is present then systems tend to > share the DataStore to avoid duplication of storage. In such cases > running Blob GC is a non trivial task as it involves a manual step and > coordination across multiple deployments. Due to this systems tend to > delay frequency of GC > Now with Oak apart from application the Oak system itself *actively* > uses the DataStore to store the index files for Lucene and there the > churn might be much higher i.e. frequency of creation and deletion of > index file is lot higher. This would accelerate the rate of garbage > generation and thus put lot more pressure on the DataStore storage > requirements. > Discussion thread http://markmail.org/thread/iybd3eq2bh372zrl -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-2808) Active deletion of 'deleted' Lucene index files from DataStore without relying on full scale Blob GC
[ https://issues.apache.org/jira/browse/OAK-2808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101638#comment-16101638 ] Thomas Mueller commented on OAK-2808: - [~catholicon] About documentation: what should we add? Is there a way to configure and disable this feature? > Active deletion of 'deleted' Lucene index files from DataStore without > relying on full scale Blob GC > > > Key: OAK-2808 > URL: https://issues.apache.org/jira/browse/OAK-2808 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Chetan Mehrotra >Assignee: Vikas Saurabh > Labels: datastore, performance > Fix For: 1.8, 1.7.1 > > Attachments: copyonread-stats.png, OAK-2808-1.patch > > > With storing of Lucene index files within DataStore our usage pattern > of DataStore has changed between JR2 and Oak. > With JR2 the writes were mostly application based i.e. if application > stores a pdf/image file then that would be stored in DataStore. JR2 by > default would not write stuff to DataStore. Further in deployment > where large number of binary content is present then systems tend to > share the DataStore to avoid duplication of storage. In such cases > running Blob GC is a non trivial task as it involves a manual step and > coordination across multiple deployments. Due to this systems tend to > delay frequency of GC > Now with Oak apart from application the Oak system itself *actively* > uses the DataStore to store the index files for Lucene and there the > churn might be much higher i.e. frequency of creation and deletion of > index file is lot higher. This would accelerate the rate of garbage > generation and thus put lot more pressure on the DataStore storage > requirements. > Discussion thread http://markmail.org/thread/iybd3eq2bh372zrl -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (OAK-5904) Property index: log when reindexing is done
[
https://issues.apache.org/jira/browse/OAK-5904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller resolved OAK-5904.
-
Resolution: Fixed
Log output is now clearer:
{noformat}
26.07.2017 14:48:05.160 *INFO* [qtp369603291-1393]
org.apache.jackrabbit.oak.plugins.index.IndexUpdate Reindexing will be
performed for following indexes: [/oak:index/slingResourceType]
26.07.2017 14:48:05.250 *INFO* [qtp369603291-1393]
org.apache.jackrabbit.oak.plugins.index.IndexUpdate Reindexing Traversed #1
/jcr:system/jcr:versionStorage/a2/35 [Infinity nodes/s, Infinity nodes/hr]
26.07.2017 14:48:05.389 *INFO* [qtp369603291-1393]
org.apache.jackrabbit.oak.plugins.index.IndexUpdate Reindexing Traversed #8
...
26.07.2017 14:48:05.471 *INFO* [qtp369603291-1393]
org.apache.jackrabbit.oak.plugins.index.IndexUpdate Reindexing Traversed #9
...
26.07.2017 14:48:05.700 *INFO* [qtp369603291-1393]
org.apache.jackrabbit.oak.plugins.index.IndexUpdate
/oak:index/slingResourceType => Indexed 1 nodes in 540.0 ms ...
26.07.2017 14:48:06.189 *INFO* [qtp369603291-1393]
org.apache.jackrabbit.oak.plugins.index.IndexUpdate
/oak:index/slingResourceType => Indexed 2 nodes in 488.5 ms ...
26.07.2017 14:48:06.762 *INFO* [qtp369603291-1393]
org.apache.jackrabbit.oak.plugins.index.IndexUpdate
/oak:index/slingResourceType => Indexed 3 nodes in 573.1 ms ...
26.07.2017 14:48:07.050 *INFO* [qtp369603291-1393]
org.apache.jackrabbit.oak.plugins.index.IndexUpdate Indexing report
- /oak:index/slingResourceType*(36468)
26.07.2017 14:48:07.050 *INFO* [qtp369603291-1393]
org.apache.jackrabbit.oak.plugins.index.IndexUpdate Reindexing completed
{noformat}
> Property index: log when reindexing is done
> ---
>
> Key: OAK-5904
> URL: https://issues.apache.org/jira/browse/OAK-5904
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: property-index
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Critical
> Fix For: 1.8, 1.7.4
>
>
> Currently, when reindexing a synchronous index, there is no log message that
> shows the progress and the end of the reindexing phase.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-5904) Property index: log when reindexing is done
[ https://issues.apache.org/jira/browse/OAK-5904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-5904: Fix Version/s: 1.7.4 > Property index: log when reindexing is done > --- > > Key: OAK-5904 > URL: https://issues.apache.org/jira/browse/OAK-5904 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: property-index >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Critical > Fix For: 1.8, 1.7.4 > > > Currently, when reindexing a synchronous index, there is no log message that > shows the progress and the end of the reindexing phase. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (OAK-6486) NPE in CompositeNodeStore
[
https://issues.apache.org/jira/browse/OAK-6486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomek Rękawek resolved OAK-6486.
Resolution: Fixed
Fix Version/s: 1.7.5
> NPE in CompositeNodeStore
> -
>
> Key: OAK-6486
> URL: https://issues.apache.org/jira/browse/OAK-6486
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: composite
>Affects Versions: 1.7.4
>Reporter: Tomek Rękawek
>Assignee: Tomek Rękawek
> Fix For: 1.8, 1.7.5
>
>
> Following NPE can be found in logs when running the Composite Node Store:
> {noformat}
> 24.07.2017 20:53:47.297 *ERROR* [oak-lucene-0]
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProvider Uncaught
> exception in
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProvider@6580fe4c
> java.lang.NullPointerException: null
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:471)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState.compareAgainstBaseState(CompositeNodeState.java:187)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:52)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexTracker.diffAndUpdate(IndexTracker.java:142)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexTracker.update(IndexTracker.java:113)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProvider.contentChanged(LuceneIndexProvider.java:75)
> at
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:128)
> at
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:122)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Probably it's related to changes introduced in OAK-6425.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (OAK-5833) Intermediate commits during (re-)indexing of synchronous index
[ https://issues.apache.org/jira/browse/OAK-5833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller resolved OAK-5833. - Resolution: Won't Fix The current plan is to use asynchronous re-indexing instead. That means, no intermediate commits are needed. > Intermediate commits during (re-)indexing of synchronous index > -- > > Key: OAK-5833 > URL: https://issues.apache.org/jira/browse/OAK-5833 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.8 > > Attachments: NodeTraverser.java, SplitRepositoryEvenly.java > > > Like OAK-2556, we should also support easier reindexing for synchronous > indexes. See also this [discussion > thread|https://lists.apache.org/thread.html/3b30afce33d84e7c3a82cf49efc0c65bfc33db4b429d50df1e05fae7@%3Coak-dev.jackrabbit.apache.org%3E]. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6464) Public constructor for RandomStream
[ https://issues.apache.org/jira/browse/OAK-6464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-6464: -- Fix Version/s: 1.6.4 Merged into 1.6 branch: http://svn.apache.org/r1803037 > Public constructor for RandomStream > --- > > Key: OAK-6464 > URL: https://issues.apache.org/jira/browse/OAK-6464 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, documentmk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Trivial > Fix For: 1.8, 1.7.4, 1.6.4 > > > The public test utility class RandomStream has a package private constructor. > The constructor should be public to make it usable from tests in other > packages. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-6486) NPE in CompositeNodeStore
[
https://issues.apache.org/jira/browse/OAK-6486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101585#comment-16101585
]
Robert Munteanu commented on OAK-6486:
--
Ah, now it makes sense. Thanks!
> NPE in CompositeNodeStore
> -
>
> Key: OAK-6486
> URL: https://issues.apache.org/jira/browse/OAK-6486
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: composite
>Affects Versions: 1.7.4
>Reporter: Tomek Rękawek
>Assignee: Tomek Rękawek
> Fix For: 1.8
>
>
> Following NPE can be found in logs when running the Composite Node Store:
> {noformat}
> 24.07.2017 20:53:47.297 *ERROR* [oak-lucene-0]
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProvider Uncaught
> exception in
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProvider@6580fe4c
> java.lang.NullPointerException: null
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:471)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState.compareAgainstBaseState(CompositeNodeState.java:187)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:52)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexTracker.diffAndUpdate(IndexTracker.java:142)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexTracker.update(IndexTracker.java:113)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProvider.contentChanged(LuceneIndexProvider.java:75)
> at
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:128)
> at
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:122)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Probably it's related to changes introduced in OAK-6425.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6486) NPE in CompositeNodeStore
[
https://issues.apache.org/jira/browse/OAK-6486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101570#comment-16101570
]
Tomek Rękawek commented on OAK-6486:
The newly created lambda function catches the hash map (something like
Javascript closure).
Please notice that the memoize() isn't called for every invocation of the
Function {{f}}. It's called just once, to wrap the existing function with a new
one. After that each f.apply() goes through the lookup.computeIfAbsent wrapper.
The lookup map is implicitly bound to the new function.
> NPE in CompositeNodeStore
> -
>
> Key: OAK-6486
> URL: https://issues.apache.org/jira/browse/OAK-6486
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: composite
>Affects Versions: 1.7.4
>Reporter: Tomek Rękawek
>Assignee: Tomek Rękawek
> Fix For: 1.8
>
>
> Following NPE can be found in logs when running the Composite Node Store:
> {noformat}
> 24.07.2017 20:53:47.297 *ERROR* [oak-lucene-0]
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProvider Uncaught
> exception in
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProvider@6580fe4c
> java.lang.NullPointerException: null
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:471)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState.compareAgainstBaseState(CompositeNodeState.java:187)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:52)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexTracker.diffAndUpdate(IndexTracker.java:142)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexTracker.update(IndexTracker.java:113)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProvider.contentChanged(LuceneIndexProvider.java:75)
> at
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:128)
> at
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:122)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Probably it's related to changes introduced in OAK-6425.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6497) Support old Segment NodeStore setups for oak-run index tooling
[ https://issues.apache.org/jira/browse/OAK-6497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101422#comment-16101422 ] Chetan Mehrotra commented on OAK-6497: -- [~frm] [~mduerig] One possible approach I was think was to have a NodeStoreFixtureProvider support for old segment module by adding an explicit dependency to oak-segment 1.6.3. We can keep this for one release and then remove this support later. This would allow for example to use oak-run-1.7.5 for old setups with whatever features implemented by now > Support old Segment NodeStore setups for oak-run index tooling > -- > > Key: OAK-6497 > URL: https://issues.apache.org/jira/browse/OAK-6497 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: run >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: 1.8 > > > oak-run index command has been introduced in trunk and can be used in read > only mode against existing setups. This would work fine for all > DocumentNodeStore setups. However would not work SegmentNodeStore setups <= > Oak 1.4 > This task is meant to figure out possible approaches for enabling such a > support for oak-run builds from trunk -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-6496) Build Jackrabbit Oak #576 failed
[ https://issues.apache.org/jira/browse/OAK-6496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101419#comment-16101419 ] Hudson commented on OAK-6496: - Build is still failing. Failed run: [Jackrabbit Oak #581|https://builds.apache.org/job/Jackrabbit%20Oak/581/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/581/console] > Build Jackrabbit Oak #576 failed > > > Key: OAK-6496 > URL: https://issues.apache.org/jira/browse/OAK-6496 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson > > Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/ > The build Jackrabbit Oak #576 has failed. > First failed run: [Jackrabbit Oak > #576|https://builds.apache.org/job/Jackrabbit%20Oak/576/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/576/console] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-6486) NPE in CompositeNodeStore
[
https://issues.apache.org/jira/browse/OAK-6486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101416#comment-16101416
]
Tomek Rękawek commented on OAK-6486:
Remove the CopyOnReadIdentityMap in [r1803029|https://svn.apache.org/r1803029].
> NPE in CompositeNodeStore
> -
>
> Key: OAK-6486
> URL: https://issues.apache.org/jira/browse/OAK-6486
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: composite
>Affects Versions: 1.7.4
>Reporter: Tomek Rękawek
>Assignee: Tomek Rękawek
> Fix For: 1.8
>
>
> Following NPE can be found in logs when running the Composite Node Store:
> {noformat}
> 24.07.2017 20:53:47.297 *ERROR* [oak-lucene-0]
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProvider Uncaught
> exception in
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProvider@6580fe4c
> java.lang.NullPointerException: null
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:471)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState.compareAgainstBaseState(CompositeNodeState.java:187)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:52)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexTracker.diffAndUpdate(IndexTracker.java:142)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexTracker.update(IndexTracker.java:113)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProvider.contentChanged(LuceneIndexProvider.java:75)
> at
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:128)
> at
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:122)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Probably it's related to changes introduced in OAK-6425.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (OAK-6497) Support old Segment NodeStore setups for oak-run index tooling
[ https://issues.apache.org/jira/browse/OAK-6497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101422#comment-16101422 ] Chetan Mehrotra edited comment on OAK-6497 at 7/26/17 9:25 AM: --- [~frm] [~mduerig] One possible approach I was think was to have a NodeStoreFixtureProvider support for old segment module by adding an explicit dependency to oak-segment 1.6.3. We can keep this for one release and then remove this support later. This would allow for example to use oak-run-1.7.5 for old setups with whatever features implemented by now. Would come up with a patch to see if this is feasible was (Author: chetanm): [~frm] [~mduerig] One possible approach I was think was to have a NodeStoreFixtureProvider support for old segment module by adding an explicit dependency to oak-segment 1.6.3. We can keep this for one release and then remove this support later. This would allow for example to use oak-run-1.7.5 for old setups with whatever features implemented by now > Support old Segment NodeStore setups for oak-run index tooling > -- > > Key: OAK-6497 > URL: https://issues.apache.org/jira/browse/OAK-6497 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: run >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: 1.8 > > > oak-run index command has been introduced in trunk and can be used in read > only mode against existing setups. This would work fine for all > DocumentNodeStore setups. However would not work SegmentNodeStore setups <= > Oak 1.4 > This task is meant to figure out possible approaches for enabling such a > support for oak-run builds from trunk -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (OAK-6497) Support old Segment NodeStore setups for oak-run index tooling
Chetan Mehrotra created OAK-6497: Summary: Support old Segment NodeStore setups for oak-run index tooling Key: OAK-6497 URL: https://issues.apache.org/jira/browse/OAK-6497 Project: Jackrabbit Oak Issue Type: Improvement Components: run Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Fix For: 1.8 oak-run index command has been introduced in trunk and can be used in read only mode against existing setups. This would work fine for all DocumentNodeStore setups. However would not work SegmentNodeStore setups <= Oak 1.4 This task is meant to figure out possible approaches for enabling such a support for oak-run builds from trunk -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6495) Fallback to classic diff when journal is broken
[ https://issues.apache.org/jira/browse/OAK-6495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-6495: -- Labels: candidate_oak_1_0 candidate_oak_1_2 candidate_oak_1_4 candidate_oak_1_6 (was: ) > Fallback to classic diff when journal is broken > --- > > Key: OAK-6495 > URL: https://issues.apache.org/jira/browse/OAK-6495 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4, > candidate_oak_1_6 > Fix For: 1.8, 1.7.5 > > > The DocumentNodeStore diff mechanism should fallback to the classic > implementation when the journal is broken. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-6496) Build Jackrabbit Oak #576 failed
[
https://issues.apache.org/jira/browse/OAK-6496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101326#comment-16101326
]
Marcel Reutegger commented on OAK-6496:
---
Builds 579 and 580:
{noformat}
org.tmatesoft.svn.core.SVNException: svn: E175002: unknown host
svn: E175002: OPTIONS request failed on '/repos/asf/jackrabbit/oak/trunk'
[...]
Caused by: java.net.UnknownHostException: svn.apache.org: Temporary failure in
name resolution
{noformat}
> Build Jackrabbit Oak #576 failed
>
>
> Key: OAK-6496
> URL: https://issues.apache.org/jira/browse/OAK-6496
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #576 has failed.
> First failed run: [Jackrabbit Oak
> #576|https://builds.apache.org/job/Jackrabbit%20Oak/576/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/576/console]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6496) Build Jackrabbit Oak #576 failed
[ https://issues.apache.org/jira/browse/OAK-6496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101319#comment-16101319 ] Hudson commented on OAK-6496: - Build is still failing. Failed run: [Jackrabbit Oak #580|https://builds.apache.org/job/Jackrabbit%20Oak/580/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/580/console] > Build Jackrabbit Oak #576 failed > > > Key: OAK-6496 > URL: https://issues.apache.org/jira/browse/OAK-6496 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson > > Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/ > The build Jackrabbit Oak #576 has failed. > First failed run: [Jackrabbit Oak > #576|https://builds.apache.org/job/Jackrabbit%20Oak/576/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/576/console] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (OAK-6495) Fallback to classic diff when journal is broken
[ https://issues.apache.org/jira/browse/OAK-6495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-6495. --- Resolution: Fixed Fix Version/s: 1.7.5 Implemented in trunk: http://svn.apache.org/r1803026 > Fallback to classic diff when journal is broken > --- > > Key: OAK-6495 > URL: https://issues.apache.org/jira/browse/OAK-6495 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.8, 1.7.5 > > > The DocumentNodeStore diff mechanism should fallback to the classic > implementation when the journal is broken. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-6496) Build Jackrabbit Oak #576 failed
[ https://issues.apache.org/jira/browse/OAK-6496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101313#comment-16101313 ] Hudson commented on OAK-6496: - Build is still failing. Failed run: [Jackrabbit Oak #579|https://builds.apache.org/job/Jackrabbit%20Oak/579/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/579/console] > Build Jackrabbit Oak #576 failed > > > Key: OAK-6496 > URL: https://issues.apache.org/jira/browse/OAK-6496 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson > > Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/ > The build Jackrabbit Oak #576 has failed. > First failed run: [Jackrabbit Oak > #576|https://builds.apache.org/job/Jackrabbit%20Oak/576/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/576/console] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-5173) Path in uniqueness constraint violation exception is always the root
[
https://issues.apache.org/jira/browse/OAK-5173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-5173:
Fix Version/s: (was: 1.7.5)
> Path in uniqueness constraint violation exception is always the root
>
>
> Key: OAK-5173
> URL: https://issues.apache.org/jira/browse/OAK-5173
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, property-index
>Affects Versions: 1.4.10, 1.5.14
>Reporter: Alexander Klimetschek
>Assignee: Thomas Mueller
> Fix For: 1.8
>
>
> OAK-1997 added a (single) path to the uniqueness constraint exception message
> in the PropertyIndexEditor to point out where the duplicate came from, but it
> is always the root:
> {noformat}
> OakConstraint0030: Uniqueness constraint violated at path [/] for one of the
> property in [rep:externalId] having value xyz1234
> {noformat}
> That is because it [uses
> getPath()|https://github.com/apache/jackrabbit-oak/blob/3a88b23d51beae4798e9b29c4deaba81c81fb427/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/property/PropertyIndexEditor.java#L315-L318]
> of the index editor itself and the uniqueness check always [happens at the
> root
> level|https://github.com/apache/jackrabbit-oak/blob/3a88b23d51beae4798e9b29c4deaba81c81fb427/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/property/PropertyIndexEditor.java#L303]
> at the end.
> It probably has to read from the index to find out the 2 or more paths with
> the same property value (just printing one path is not enough information for
> duplicates).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-5173) Path in uniqueness constraint violation exception is always the root
[
https://issues.apache.org/jira/browse/OAK-5173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101250#comment-16101250
]
Thomas Mueller commented on OAK-5173:
-
Yes, I will try to fix this (and if the fix is easy, maybe backport it). But I
can't say whether this will go in 1.7.5 yet.
> Path in uniqueness constraint violation exception is always the root
>
>
> Key: OAK-5173
> URL: https://issues.apache.org/jira/browse/OAK-5173
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, property-index
>Affects Versions: 1.4.10, 1.5.14
>Reporter: Alexander Klimetschek
>Assignee: Thomas Mueller
> Fix For: 1.8, 1.7.5
>
>
> OAK-1997 added a (single) path to the uniqueness constraint exception message
> in the PropertyIndexEditor to point out where the duplicate came from, but it
> is always the root:
> {noformat}
> OakConstraint0030: Uniqueness constraint violated at path [/] for one of the
> property in [rep:externalId] having value xyz1234
> {noformat}
> That is because it [uses
> getPath()|https://github.com/apache/jackrabbit-oak/blob/3a88b23d51beae4798e9b29c4deaba81c81fb427/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/property/PropertyIndexEditor.java#L315-L318]
> of the index editor itself and the uniqueness check always [happens at the
> root
> level|https://github.com/apache/jackrabbit-oak/blob/3a88b23d51beae4798e9b29c4deaba81c81fb427/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/property/PropertyIndexEditor.java#L303]
> at the end.
> It probably has to read from the index to find out the 2 or more paths with
> the same property value (just printing one path is not enough information for
> duplicates).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-5173) Path in uniqueness constraint violation exception is always the root
[
https://issues.apache.org/jira/browse/OAK-5173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-5173:
Priority: Major (was: Minor)
> Path in uniqueness constraint violation exception is always the root
>
>
> Key: OAK-5173
> URL: https://issues.apache.org/jira/browse/OAK-5173
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, property-index
>Affects Versions: 1.4.10, 1.5.14
>Reporter: Alexander Klimetschek
>Assignee: Thomas Mueller
> Fix For: 1.8, 1.7.5
>
>
> OAK-1997 added a (single) path to the uniqueness constraint exception message
> in the PropertyIndexEditor to point out where the duplicate came from, but it
> is always the root:
> {noformat}
> OakConstraint0030: Uniqueness constraint violated at path [/] for one of the
> property in [rep:externalId] having value xyz1234
> {noformat}
> That is because it [uses
> getPath()|https://github.com/apache/jackrabbit-oak/blob/3a88b23d51beae4798e9b29c4deaba81c81fb427/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/property/PropertyIndexEditor.java#L315-L318]
> of the index editor itself and the uniqueness check always [happens at the
> root
> level|https://github.com/apache/jackrabbit-oak/blob/3a88b23d51beae4798e9b29c4deaba81c81fb427/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/property/PropertyIndexEditor.java#L303]
> at the end.
> It probably has to read from the index to find out the 2 or more paths with
> the same property value (just printing one path is not enough information for
> duplicates).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (OAK-5173) Path in uniqueness constraint violation exception is always the root
[
https://issues.apache.org/jira/browse/OAK-5173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller reassigned OAK-5173:
---
Assignee: Thomas Mueller
> Path in uniqueness constraint violation exception is always the root
>
>
> Key: OAK-5173
> URL: https://issues.apache.org/jira/browse/OAK-5173
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, property-index
>Affects Versions: 1.4.10, 1.5.14
>Reporter: Alexander Klimetschek
>Assignee: Thomas Mueller
>Priority: Minor
> Fix For: 1.8, 1.7.5
>
>
> OAK-1997 added a (single) path to the uniqueness constraint exception message
> in the PropertyIndexEditor to point out where the duplicate came from, but it
> is always the root:
> {noformat}
> OakConstraint0030: Uniqueness constraint violated at path [/] for one of the
> property in [rep:externalId] having value xyz1234
> {noformat}
> That is because it [uses
> getPath()|https://github.com/apache/jackrabbit-oak/blob/3a88b23d51beae4798e9b29c4deaba81c81fb427/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/property/PropertyIndexEditor.java#L315-L318]
> of the index editor itself and the uniqueness check always [happens at the
> root
> level|https://github.com/apache/jackrabbit-oak/blob/3a88b23d51beae4798e9b29c4deaba81c81fb427/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/property/PropertyIndexEditor.java#L303]
> at the end.
> It probably has to read from the index to find out the 2 or more paths with
> the same property value (just printing one path is not enough information for
> duplicates).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-5173) Path in uniqueness constraint violation exception is always the root
[
https://issues.apache.org/jira/browse/OAK-5173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101235#comment-16101235
]
Chetan Mehrotra commented on OAK-5173:
--
[~tmueller] This error message has confused people few times. Can you have a
look at proposed approach by [~alexander.klimetschek]
> Path in uniqueness constraint violation exception is always the root
>
>
> Key: OAK-5173
> URL: https://issues.apache.org/jira/browse/OAK-5173
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, property-index
>Affects Versions: 1.4.10, 1.5.14
>Reporter: Alexander Klimetschek
>Priority: Minor
> Fix For: 1.8, 1.7.5
>
>
> OAK-1997 added a (single) path to the uniqueness constraint exception message
> in the PropertyIndexEditor to point out where the duplicate came from, but it
> is always the root:
> {noformat}
> OakConstraint0030: Uniqueness constraint violated at path [/] for one of the
> property in [rep:externalId] having value xyz1234
> {noformat}
> That is because it [uses
> getPath()|https://github.com/apache/jackrabbit-oak/blob/3a88b23d51beae4798e9b29c4deaba81c81fb427/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/property/PropertyIndexEditor.java#L315-L318]
> of the index editor itself and the uniqueness check always [happens at the
> root
> level|https://github.com/apache/jackrabbit-oak/blob/3a88b23d51beae4798e9b29c4deaba81c81fb427/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/property/PropertyIndexEditor.java#L303]
> at the end.
> It probably has to read from the index to find out the 2 or more paths with
> the same property value (just printing one path is not enough information for
> duplicates).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-5173) Path in uniqueness constraint violation exception is always the root
[
https://issues.apache.org/jira/browse/OAK-5173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-5173:
-
Fix Version/s: 1.7.5
> Path in uniqueness constraint violation exception is always the root
>
>
> Key: OAK-5173
> URL: https://issues.apache.org/jira/browse/OAK-5173
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, property-index
>Affects Versions: 1.4.10, 1.5.14
>Reporter: Alexander Klimetschek
>Priority: Minor
> Fix For: 1.8, 1.7.5
>
>
> OAK-1997 added a (single) path to the uniqueness constraint exception message
> in the PropertyIndexEditor to point out where the duplicate came from, but it
> is always the root:
> {noformat}
> OakConstraint0030: Uniqueness constraint violated at path [/] for one of the
> property in [rep:externalId] having value xyz1234
> {noformat}
> That is because it [uses
> getPath()|https://github.com/apache/jackrabbit-oak/blob/3a88b23d51beae4798e9b29c4deaba81c81fb427/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/property/PropertyIndexEditor.java#L315-L318]
> of the index editor itself and the uniqueness check always [happens at the
> root
> level|https://github.com/apache/jackrabbit-oak/blob/3a88b23d51beae4798e9b29c4deaba81c81fb427/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/property/PropertyIndexEditor.java#L303]
> at the end.
> It probably has to read from the index to find out the 2 or more paths with
> the same property value (just printing one path is not enough information for
> duplicates).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6486) NPE in CompositeNodeStore
[
https://issues.apache.org/jira/browse/OAK-6486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101218#comment-16101218
]
Tomek Rękawek commented on OAK-6486:
It seems that the NPE is caused by the CopyOnReadIdentityMap, which isn't
thread safe and sometimes returns null even if the value is in the original
map. It was introduced to provide a lazy and cacheable way to read children
from the composite node states. Maybe we shouldn't hide this laziness behind a
map in the CompositeNodeState/Builder and make the {{nodeStates}} field a
function, which can be memoized if needed.
> NPE in CompositeNodeStore
> -
>
> Key: OAK-6486
> URL: https://issues.apache.org/jira/browse/OAK-6486
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: composite
>Affects Versions: 1.7.4
>Reporter: Tomek Rękawek
>Assignee: Tomek Rękawek
> Fix For: 1.8
>
>
> Following NPE can be found in logs when running the Composite Node Store:
> {noformat}
> 24.07.2017 20:53:47.297 *ERROR* [oak-lucene-0]
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProvider Uncaught
> exception in
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProvider@6580fe4c
> java.lang.NullPointerException: null
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:471)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState.compareAgainstBaseState(CompositeNodeState.java:187)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:52)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexTracker.diffAndUpdate(IndexTracker.java:142)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexTracker.update(IndexTracker.java:113)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProvider.contentChanged(LuceneIndexProvider.java:75)
> at
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:128)
> at
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:122)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Probably it's related to changes introduced in OAK-6425.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
