[jira] [Commented] (OAK-7941) Test failure: IndexCopierTest.directoryContentMismatch_COR
[
https://issues.apache.org/jira/browse/OAK-7941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16712930#comment-16712930
]
Hudson commented on OAK-7941:
-
Previously failing build now is OK.
Passed run: [Jackrabbit Oak
#1841|https://builds.apache.org/job/Jackrabbit%20Oak/1841/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/1841/console]
> Test failure: IndexCopierTest.directoryContentMismatch_COR
> --
>
> Key: OAK-7941
> URL: https://issues.apache.org/jira/browse/OAK-7941
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration, lucene
>Reporter: Hudson
>Priority: Major
> Fix For: 1.10
>
>
> No description is provided
> The build Jackrabbit Oak #1830 has failed.
> First failed run: [Jackrabbit Oak
> #1830|https://builds.apache.org/job/Jackrabbit%20Oak/1830/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/1830/console]
> {noformat}
> [ERROR] Tests run: 24, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 0.832 s <<< FAILURE! - in
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopierTest
> [ERROR]
> directoryContentMismatch_COR(org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopierTest)
> Time elapsed: 0.08 s <<< FAILURE!
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopierTest.readAndAssert(IndexCopierTest.java:1119)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopierTest.directoryContentMismatch_COR(IndexCopierTest.java:1081)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-7906) StackOverFlowError SessionStatsTest.testInitStackTraceEnabledAfterOpeningManySessions with jdk-12
[
https://issues.apache.org/jira/browse/OAK-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16712835#comment-16712835
]
Alex Deparvu commented on OAK-7906:
---
sample failure on travis jdk12 build 23 on Ubuntu 14.04.5 LTS [0]
{noformat}
openjdk version "12-ea" 2019-03-19
OpenJDK Runtime Environment (build 12-ea+23)
OpenJDK 64-Bit Server VM (build 12-ea+23, mixed mode, sharing)
{noformat}
[0] https://travis-ci.org/stillalex/jackrabbit-oak/jobs/458708056
> StackOverFlowError
> SessionStatsTest.testInitStackTraceEnabledAfterOpeningManySessions with jdk-12
> -
>
> Key: OAK-7906
> URL: https://issues.apache.org/jira/browse/OAK-7906
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.9.11
>Reporter: Julian Reschke
>Priority: Major
> Labels: Java12
>
> Happens with version 20 (2018/11/15).
> It appears that the StackOverflowError happens when obtaining many sessions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (OAK-7935) RDB*Store: createOrUpdate may fail on stale cache when document was removed on different instance
[ https://issues.apache.org/jira/browse/OAK-7935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707573#comment-16707573 ] Julian Reschke edited comment on OAK-7935 at 12/7/18 11:59 AM: --- trunk: [r1848073|http://svn.apache.org/r1848073] (just the test which passes on trunk) 1.8: [r1848096|http://svn.apache.org/r1848096] 1.6: [r1848127|http://svn.apache.org/r1848127] 1.4: [r1848154|http://svn.apache.org/r1848154] 1.2: [r1848390|http://svn.apache.org/r1848390] 1.0: [r1848391|http://svn.apache.org/r1848391] was (Author: reschke): trunk: [r1848073|http://svn.apache.org/r1848073] (just the test which passes on trunk) 1.8: [r1848096|http://svn.apache.org/r1848096] 1.6: [r1848127|http://svn.apache.org/r1848127] 1.4: [r1848154|http://svn.apache.org/r1848154] 1.2: [r1848390|http://svn.apache.org/r1848390] > RDB*Store: createOrUpdate may fail on stale cache when document was removed > on different instance > - > > Key: OAK-7935 > URL: https://issues.apache.org/jira/browse/OAK-7935 > Project: Jackrabbit Oak > Issue Type: Bug > Components: rdbmk >Affects Versions: 1.4.23, 1.6.15, 1.8.9 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Critical > Fix For: 1.10, 1.0.43, 1.2.31, 1.4.24, 1.8.10, 1.6.16, 1.9.13 > > > When executing `createOrUpdate()` on a node that is cached but has been > removed from the database (by a different instance), the operation will fail, > and continue to do so until the cache entry gets evicted or the cache gets > manually cleared. > The exception message somewhat misleadingly says "update of ... failed, race > condition?" > The problem has been fixed already in OAK-7725, but that change is rather big > and non-trivial to backport. > As a simpler fix for the maintenance branches we should invalidate the cache > when the update fails, so that the system at least recovers and a retry will > work. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7935) RDB*Store: createOrUpdate may fail on stale cache when document was removed on different instance
[ https://issues.apache.org/jira/browse/OAK-7935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-7935: Labels: (was: candidate_oak_1_0) > RDB*Store: createOrUpdate may fail on stale cache when document was removed > on different instance > - > > Key: OAK-7935 > URL: https://issues.apache.org/jira/browse/OAK-7935 > Project: Jackrabbit Oak > Issue Type: Bug > Components: rdbmk >Affects Versions: 1.4.23, 1.6.15, 1.8.9 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Critical > Fix For: 1.10, 1.0.43, 1.2.31, 1.4.24, 1.8.10, 1.6.16, 1.9.13 > > > When executing `createOrUpdate()` on a node that is cached but has been > removed from the database (by a different instance), the operation will fail, > and continue to do so until the cache entry gets evicted or the cache gets > manually cleared. > The exception message somewhat misleadingly says "update of ... failed, race > condition?" > The problem has been fixed already in OAK-7725, but that change is rather big > and non-trivial to backport. > As a simpler fix for the maintenance branches we should invalidate the cache > when the update fails, so that the system at least recovers and a retry will > work. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7935) RDB*Store: createOrUpdate may fail on stale cache when document was removed on different instance
[ https://issues.apache.org/jira/browse/OAK-7935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-7935: Fix Version/s: 1.0.43 > RDB*Store: createOrUpdate may fail on stale cache when document was removed > on different instance > - > > Key: OAK-7935 > URL: https://issues.apache.org/jira/browse/OAK-7935 > Project: Jackrabbit Oak > Issue Type: Bug > Components: rdbmk >Affects Versions: 1.4.23, 1.6.15, 1.8.9 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Critical > Fix For: 1.10, 1.0.43, 1.2.31, 1.4.24, 1.8.10, 1.6.16, 1.9.13 > > > When executing `createOrUpdate()` on a node that is cached but has been > removed from the database (by a different instance), the operation will fail, > and continue to do so until the cache entry gets evicted or the cache gets > manually cleared. > The exception message somewhat misleadingly says "update of ... failed, race > condition?" > The problem has been fixed already in OAK-7725, but that change is rather big > and non-trivial to backport. > As a simpler fix for the maintenance branches we should invalidate the cache > when the update fails, so that the system at least recovers and a retry will > work. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (OAK-7935) RDB*Store: createOrUpdate may fail on stale cache when document was removed on different instance
[ https://issues.apache.org/jira/browse/OAK-7935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707573#comment-16707573 ] Julian Reschke edited comment on OAK-7935 at 12/7/18 10:58 AM: --- trunk: [r1848073|http://svn.apache.org/r1848073] (just the test which passes on trunk) 1.8: [r1848096|http://svn.apache.org/r1848096] 1.6: [r1848127|http://svn.apache.org/r1848127] 1.4: [r1848154|http://svn.apache.org/r1848154] 1.2: [r1848390|http://svn.apache.org/r1848390] was (Author: reschke): trunk: [r1848073|http://svn.apache.org/r1848073] (just the test which passes on trunk) 1.8: [r1848096|http://svn.apache.org/r1848096] 1.6: [r1848127|http://svn.apache.org/r1848127] 1.4: [r1848154|http://svn.apache.org/r1848154] > RDB*Store: createOrUpdate may fail on stale cache when document was removed > on different instance > - > > Key: OAK-7935 > URL: https://issues.apache.org/jira/browse/OAK-7935 > Project: Jackrabbit Oak > Issue Type: Bug > Components: rdbmk >Affects Versions: 1.4.23, 1.6.15, 1.8.9 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Critical > Labels: candidate_oak_1_0 > Fix For: 1.10, 1.2.31, 1.4.24, 1.8.10, 1.6.16, 1.9.13 > > > When executing `createOrUpdate()` on a node that is cached but has been > removed from the database (by a different instance), the operation will fail, > and continue to do so until the cache entry gets evicted or the cache gets > manually cleared. > The exception message somewhat misleadingly says "update of ... failed, race > condition?" > The problem has been fixed already in OAK-7725, but that change is rather big > and non-trivial to backport. > As a simpler fix for the maintenance branches we should invalidate the cache > when the update fails, so that the system at least recovers and a retry will > work. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7935) RDB*Store: createOrUpdate may fail on stale cache when document was removed on different instance
[ https://issues.apache.org/jira/browse/OAK-7935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-7935: Labels: candidate_oak_1_0 (was: candidate_oak_1_2) > RDB*Store: createOrUpdate may fail on stale cache when document was removed > on different instance > - > > Key: OAK-7935 > URL: https://issues.apache.org/jira/browse/OAK-7935 > Project: Jackrabbit Oak > Issue Type: Bug > Components: rdbmk >Affects Versions: 1.4.23, 1.6.15, 1.8.9 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Critical > Labels: candidate_oak_1_0 > Fix For: 1.10, 1.2.31, 1.4.24, 1.8.10, 1.6.16, 1.9.13 > > > When executing `createOrUpdate()` on a node that is cached but has been > removed from the database (by a different instance), the operation will fail, > and continue to do so until the cache entry gets evicted or the cache gets > manually cleared. > The exception message somewhat misleadingly says "update of ... failed, race > condition?" > The problem has been fixed already in OAK-7725, but that change is rather big > and non-trivial to backport. > As a simpler fix for the maintenance branches we should invalidate the cache > when the update fails, so that the system at least recovers and a retry will > work. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7935) RDB*Store: createOrUpdate may fail on stale cache when document was removed on different instance
[ https://issues.apache.org/jira/browse/OAK-7935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-7935: Fix Version/s: 1.2.31 > RDB*Store: createOrUpdate may fail on stale cache when document was removed > on different instance > - > > Key: OAK-7935 > URL: https://issues.apache.org/jira/browse/OAK-7935 > Project: Jackrabbit Oak > Issue Type: Bug > Components: rdbmk >Affects Versions: 1.4.23, 1.6.15, 1.8.9 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Critical > Labels: candidate_oak_1_2 > Fix For: 1.10, 1.2.31, 1.4.24, 1.8.10, 1.6.16, 1.9.13 > > > When executing `createOrUpdate()` on a node that is cached but has been > removed from the database (by a different instance), the operation will fail, > and continue to do so until the cache entry gets evicted or the cache gets > manually cleared. > The exception message somewhat misleadingly says "update of ... failed, race > condition?" > The problem has been fixed already in OAK-7725, but that change is rather big > and non-trivial to backport. > As a simpler fix for the maintenance branches we should invalidate the cache > when the update fails, so that the system at least recovers and a retry will > work. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7941) Test failure: IndexCopierTest.directoryContentMismatch_COR
[
https://issues.apache.org/jira/browse/OAK-7941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16712622#comment-16712622
]
Hudson commented on OAK-7941:
-
Previously failing build now is OK.
Passed run: [Jackrabbit Oak
#1840|https://builds.apache.org/job/Jackrabbit%20Oak/1840/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/1840/console]
> Test failure: IndexCopierTest.directoryContentMismatch_COR
> --
>
> Key: OAK-7941
> URL: https://issues.apache.org/jira/browse/OAK-7941
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration, lucene
>Reporter: Hudson
>Priority: Major
> Fix For: 1.10
>
>
> No description is provided
> The build Jackrabbit Oak #1830 has failed.
> First failed run: [Jackrabbit Oak
> #1830|https://builds.apache.org/job/Jackrabbit%20Oak/1830/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/1830/console]
> {noformat}
> [ERROR] Tests run: 24, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 0.832 s <<< FAILURE! - in
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopierTest
> [ERROR]
> directoryContentMismatch_COR(org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopierTest)
> Time elapsed: 0.08 s <<< FAILURE!
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopierTest.readAndAssert(IndexCopierTest.java:1119)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopierTest.directoryContentMismatch_COR(IndexCopierTest.java:1081)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-7947) Lazy loading of Lucene index files startup
[ https://issues.apache.org/jira/browse/OAK-7947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16712595#comment-16712595 ] Chetan Mehrotra commented on OAK-7947: -- [~tmueller] One reason for doing eager loading was to avoid contention in queries hitting at very start. To make is lazy what we can do is store the data points required for index planning in index data node itself in repository. So stuff like numDocs and field count etc can recorded in repo upon index close. Then at least for index planning phase we need not open the IndexWriter at all > Lazy loading of Lucene index files startup > -- > > Key: OAK-7947 > URL: https://issues.apache.org/jira/browse/OAK-7947 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene, query >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Major > Attachments: OAK-7947.patch > > > Right now, all Lucene index binaries are loaded on startup (I think when the > first query is run, to do cost calculation). This is a performance problem if > the index files are large, and need to be downloaded from the data store. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
