[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=16712434#comment-16712434 ] Julian Reschke commented on OAK-7906: - See https://bugs.openjdk.java.net/browse/JDK-8214583 > 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] [Created] (OAK-7949) Support IN clause for jcr:path sent down to index (if supported)
Vikas Saurabh created OAK-7949:
--
Summary: Support IN clause for jcr:path sent down to index (if
supported)
Key: OAK-7949
URL: https://issues.apache.org/jira/browse/OAK-7949
Project: Jackrabbit Oak
Issue Type: Improvement
Components: lucene
Reporter: Vikas Saurabh
Assignee: Vikas Saurabh
There are times where we would want to run a query with some constraints (maybe
fulltext) and that the result set is a subset of a set of paths.
To elaborate in terms of queries:
{noformat}
/jcr:root//*[(jcr:path='/parent1/par2/a' or jcr:path='/parent1/par3/b') and
jcr:contains(., 'foo')]
{noformat}
OR
{noformat}
SELECT * FROM [nt:base] WHERE ([jcr:path] = '/parent1/par2/a' OR [jcr:path] =
'/parent1/par3/b') AND CONTAINS(*, 'foo')
{noformat}
OR
{noformat}
SELECT * FROM [nt:base] WHERE [jcr:path] IN ('/parent1/par2/a',
'/parent1/par3/b') AND CONTAINS(*, 'foo')
{noformat}
Currently, single path constraints using {{jcr:path}} (as above) or
{{ISSAMENODE}} constraints get planned by lucene index planner and are
translated well as a constraint on {{:path}} for lucene query. But, multiple
paths don't get the same behavior.
In absence of this issue the output of index could be much larger only to be
filtered out at query engine level.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (OAK-7630) Suggest directory update doesn't close AnalyzingInfixSuggester after building
[
https://issues.apache.org/jira/browse/OAK-7630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711974#comment-16711974
]
Vikas Saurabh edited comment on OAK-7630 at 12/6/18 9:20 PM:
-
Backported on 1.6 at [r1848352|https://svn.apache.org/1848352].
Backported on 1.4 at r1848361|https://svn.apache.org/r1848361].
was (Author: catholicon):
Backport on 1.6 at [r1848352|https://svn.apache.org/1848352].
> Suggest directory update doesn't close AnalyzingInfixSuggester after building
> -
>
> Key: OAK-7630
> URL: https://issues.apache.org/jira/browse/OAK-7630
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.8.0
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
> Fix For: 1.10, 1.9.6, 1.8.6, 1.4.24, 1.6.16
>
>
> {{SuggestHelper#updateSuggester}} updates suggester by doing a {{build()}} on
> a newly created instance of {{AnalyzingInfixSuggester}}. But it never closes
> the suggester instance, which, in turn, leads to un-closed reader. With FS
> based directory (when copy-on-write is enabled), this leads to leaking file
> handles. FSDirectory does get closed on GC though.
> The issue was reported by [~mreutegg]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-6895) Suggest directory lookup (query) isn't closed
[
https://issues.apache.org/jira/browse/OAK-6895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-6895:
---
Fix Version/s: 1.4.24
> Suggest directory lookup (query) isn't closed
> -
>
> Key: OAK-6895
> URL: https://issues.apache.org/jira/browse/OAK-6895
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
> Fix For: 1.7.11, 1.8.0, 1.4.24, 1.6.16
>
>
> After OAK-6775, it was observed that we are leaking file handles pointing to
> suggestion directory files.
> This is because {{DefaultIndexReader}} doesn't close suggest directory on
> close.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-6972) DefaultIndexReader closes suggest directory multiple times
[
https://issues.apache.org/jira/browse/OAK-6972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-6972:
---
Fix Version/s: 1.4.24
> DefaultIndexReader closes suggest directory multiple times
> --
>
> Key: OAK-6972
> URL: https://issues.apache.org/jira/browse/OAK-6972
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.7.11
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.7.12, 1.8.0, 1.4.24, 1.6.16
>
>
> With OAK-6895 DefaultIndexReader now closes CopyOnReadDirectory used for
> suggestor multiple times. This leads to exception later
> {noformat}
> 21.11.2017 13:53:52.750 *WARN* [oak-lucene-2162]
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProviderService
> Error occurred in asynchronous processing
> org.apache.lucene.store.AlreadyClosedException: this Directory is closed
> at
> org.apache.lucene.store.BaseDirectory.ensureOpen(BaseDirectory.java:66)
> at
> org.apache.lucene.store.FSDirectory.getDirectory(FSDirectory.java:338)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.LocalIndexFile.getFSDir(LocalIndexFile.java:125)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.LocalIndexFile.(LocalIndexFile.java:43)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopier.deleteFile(IndexCopier.java:276)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnReadDirectory.removeDeletedFiles(CopyOnReadDirectory.java:315)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnReadDirectory.access$300(CopyOnReadDirectory.java:51)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnReadDirectory$2.run(CopyOnReadDirectory.java:278)
> 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:745)
> {noformat}
> As a fix
> # Avoid closing the directory multiple times in DefaultIndexReader
> # Make CopyOnReadDirectory resilient to multiple close calls
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (OAK-6895) Suggest directory lookup (query) isn't closed
[
https://issues.apache.org/jira/browse/OAK-6895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711980#comment-16711980
]
Vikas Saurabh edited comment on OAK-6895 at 12/6/18 9:22 PM:
-
Backported on 1.6 at [r1848357|https://svn.apache.org/r1848357].
Backported on 1.4 at [r1848364|https://svn.apache.org/r1848364].
was (Author: catholicon):
Backported on 1.6 at [r1848357|https://svn.apache.org/r1848357].
> Suggest directory lookup (query) isn't closed
> -
>
> Key: OAK-6895
> URL: https://issues.apache.org/jira/browse/OAK-6895
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
> Fix For: 1.7.11, 1.8.0, 1.4.24, 1.6.16
>
>
> After OAK-6775, it was observed that we are leaking file handles pointing to
> suggestion directory files.
> This is because {{DefaultIndexReader}} doesn't close suggest directory on
> close.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (OAK-6972) DefaultIndexReader closes suggest directory multiple times
[
https://issues.apache.org/jira/browse/OAK-6972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711979#comment-16711979
]
Vikas Saurabh edited comment on OAK-6972 at 12/6/18 9:22 PM:
-
Backported on 1.6 at [r1848357|https://svn.apache.org/r1848357].
Backported on 1.4 at [r1848364|https://svn.apache.org/r1848364].
was (Author: catholicon):
Backported on 1.6 at [r1848357|https://svn.apache.org/r1848357].
> DefaultIndexReader closes suggest directory multiple times
> --
>
> Key: OAK-6972
> URL: https://issues.apache.org/jira/browse/OAK-6972
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.7.11
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.7.12, 1.8.0, 1.4.24, 1.6.16
>
>
> With OAK-6895 DefaultIndexReader now closes CopyOnReadDirectory used for
> suggestor multiple times. This leads to exception later
> {noformat}
> 21.11.2017 13:53:52.750 *WARN* [oak-lucene-2162]
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProviderService
> Error occurred in asynchronous processing
> org.apache.lucene.store.AlreadyClosedException: this Directory is closed
> at
> org.apache.lucene.store.BaseDirectory.ensureOpen(BaseDirectory.java:66)
> at
> org.apache.lucene.store.FSDirectory.getDirectory(FSDirectory.java:338)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.LocalIndexFile.getFSDir(LocalIndexFile.java:125)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.LocalIndexFile.(LocalIndexFile.java:43)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopier.deleteFile(IndexCopier.java:276)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnReadDirectory.removeDeletedFiles(CopyOnReadDirectory.java:315)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnReadDirectory.access$300(CopyOnReadDirectory.java:51)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnReadDirectory$2.run(CopyOnReadDirectory.java:278)
> 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:745)
> {noformat}
> As a fix
> # Avoid closing the directory multiple times in DefaultIndexReader
> # Make CopyOnReadDirectory resilient to multiple close calls
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (OAK-7630) Suggest directory update doesn't close AnalyzingInfixSuggester after building
[
https://issues.apache.org/jira/browse/OAK-7630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711974#comment-16711974
]
Vikas Saurabh edited comment on OAK-7630 at 12/6/18 9:21 PM:
-
Backported on 1.6 at [r1848352|https://svn.apache.org/r1848352].
Backported on 1.4 at [r1848361|https://svn.apache.org/r1848361].
was (Author: catholicon):
Backported on 1.6 at [r1848352|https://svn.apache.org/1848352].
Backported on 1.4 at r1848361|https://svn.apache.org/r1848361].
> Suggest directory update doesn't close AnalyzingInfixSuggester after building
> -
>
> Key: OAK-7630
> URL: https://issues.apache.org/jira/browse/OAK-7630
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.8.0
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
> Fix For: 1.10, 1.9.6, 1.8.6, 1.4.24, 1.6.16
>
>
> {{SuggestHelper#updateSuggester}} updates suggester by doing a {{build()}} on
> a newly created instance of {{AnalyzingInfixSuggester}}. But it never closes
> the suggester instance, which, in turn, leads to un-closed reader. With FS
> based directory (when copy-on-write is enabled), this leads to leaking file
> handles. FSDirectory does get closed on GC though.
> The issue was reported by [~mreutegg]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7630) Suggest directory update doesn't close AnalyzingInfixSuggester after building
[
https://issues.apache.org/jira/browse/OAK-7630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-7630:
---
Fix Version/s: 1.4.24
> Suggest directory update doesn't close AnalyzingInfixSuggester after building
> -
>
> Key: OAK-7630
> URL: https://issues.apache.org/jira/browse/OAK-7630
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.8.0
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
> Fix For: 1.10, 1.9.6, 1.8.6, 1.4.24, 1.6.16
>
>
> {{SuggestHelper#updateSuggester}} updates suggester by doing a {{build()}} on
> a newly created instance of {{AnalyzingInfixSuggester}}. But it never closes
> the suggester instance, which, in turn, leads to un-closed reader. With FS
> based directory (when copy-on-write is enabled), this leads to leaking file
> handles. FSDirectory does get closed on GC though.
> The issue was reported by [~mreutegg]
--
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=16712035#comment-16712035
]
Hudson commented on OAK-7941:
-
Previously failing build now is OK.
Passed run: [Jackrabbit Oak
#1839|https://builds.apache.org/job/Jackrabbit%20Oak/1839/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/1839/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-6895) Suggest directory lookup (query) isn't closed
[
https://issues.apache.org/jira/browse/OAK-6895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711980#comment-16711980
]
Vikas Saurabh commented on OAK-6895:
Backported on 1.6 at [r1848357|https://svn.apache.org/r1848357].
> Suggest directory lookup (query) isn't closed
> -
>
> Key: OAK-6895
> URL: https://issues.apache.org/jira/browse/OAK-6895
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
> Fix For: 1.7.11, 1.8.0, 1.6.16
>
>
> After OAK-6775, it was observed that we are leaking file handles pointing to
> suggestion directory files.
> This is because {{DefaultIndexReader}} doesn't close suggest directory on
> close.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-6972) DefaultIndexReader closes suggest directory multiple times
[
https://issues.apache.org/jira/browse/OAK-6972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711979#comment-16711979
]
Vikas Saurabh commented on OAK-6972:
Backported on 1.6 at [r1848357|https://svn.apache.org/r1848357].
> DefaultIndexReader closes suggest directory multiple times
> --
>
> Key: OAK-6972
> URL: https://issues.apache.org/jira/browse/OAK-6972
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.7.11
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.7.12, 1.8.0, 1.6.16
>
>
> With OAK-6895 DefaultIndexReader now closes CopyOnReadDirectory used for
> suggestor multiple times. This leads to exception later
> {noformat}
> 21.11.2017 13:53:52.750 *WARN* [oak-lucene-2162]
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProviderService
> Error occurred in asynchronous processing
> org.apache.lucene.store.AlreadyClosedException: this Directory is closed
> at
> org.apache.lucene.store.BaseDirectory.ensureOpen(BaseDirectory.java:66)
> at
> org.apache.lucene.store.FSDirectory.getDirectory(FSDirectory.java:338)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.LocalIndexFile.getFSDir(LocalIndexFile.java:125)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.LocalIndexFile.(LocalIndexFile.java:43)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopier.deleteFile(IndexCopier.java:276)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnReadDirectory.removeDeletedFiles(CopyOnReadDirectory.java:315)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnReadDirectory.access$300(CopyOnReadDirectory.java:51)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnReadDirectory$2.run(CopyOnReadDirectory.java:278)
> 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:745)
> {noformat}
> As a fix
> # Avoid closing the directory multiple times in DefaultIndexReader
> # Make CopyOnReadDirectory resilient to multiple close calls
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-6895) Suggest directory lookup (query) isn't closed
[
https://issues.apache.org/jira/browse/OAK-6895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-6895:
---
Fix Version/s: 1.6.16
> Suggest directory lookup (query) isn't closed
> -
>
> Key: OAK-6895
> URL: https://issues.apache.org/jira/browse/OAK-6895
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
> Fix For: 1.7.11, 1.8.0, 1.6.16
>
>
> After OAK-6775, it was observed that we are leaking file handles pointing to
> suggestion directory files.
> This is because {{DefaultIndexReader}} doesn't close suggest directory on
> close.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-6972) DefaultIndexReader closes suggest directory multiple times
[
https://issues.apache.org/jira/browse/OAK-6972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-6972:
---
Fix Version/s: 1.6.16
> DefaultIndexReader closes suggest directory multiple times
> --
>
> Key: OAK-6972
> URL: https://issues.apache.org/jira/browse/OAK-6972
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.7.11
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.7.12, 1.8.0, 1.6.16
>
>
> With OAK-6895 DefaultIndexReader now closes CopyOnReadDirectory used for
> suggestor multiple times. This leads to exception later
> {noformat}
> 21.11.2017 13:53:52.750 *WARN* [oak-lucene-2162]
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProviderService
> Error occurred in asynchronous processing
> org.apache.lucene.store.AlreadyClosedException: this Directory is closed
> at
> org.apache.lucene.store.BaseDirectory.ensureOpen(BaseDirectory.java:66)
> at
> org.apache.lucene.store.FSDirectory.getDirectory(FSDirectory.java:338)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.LocalIndexFile.getFSDir(LocalIndexFile.java:125)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.LocalIndexFile.(LocalIndexFile.java:43)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopier.deleteFile(IndexCopier.java:276)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnReadDirectory.removeDeletedFiles(CopyOnReadDirectory.java:315)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnReadDirectory.access$300(CopyOnReadDirectory.java:51)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnReadDirectory$2.run(CopyOnReadDirectory.java:278)
> 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:745)
> {noformat}
> As a fix
> # Avoid closing the directory multiple times in DefaultIndexReader
> # Make CopyOnReadDirectory resilient to multiple close calls
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7630) Suggest directory update doesn't close AnalyzingInfixSuggester after building
[
https://issues.apache.org/jira/browse/OAK-7630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-7630:
---
Fix Version/s: 1.6.16
> Suggest directory update doesn't close AnalyzingInfixSuggester after building
> -
>
> Key: OAK-7630
> URL: https://issues.apache.org/jira/browse/OAK-7630
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.8.0
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
> Fix For: 1.10, 1.9.6, 1.8.6, 1.6.16
>
>
> {{SuggestHelper#updateSuggester}} updates suggester by doing a {{build()}} on
> a newly created instance of {{AnalyzingInfixSuggester}}. But it never closes
> the suggester instance, which, in turn, leads to un-closed reader. With FS
> based directory (when copy-on-write is enabled), this leads to leaking file
> handles. FSDirectory does get closed on GC though.
> The issue was reported by [~mreutegg]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-7630) Suggest directory update doesn't close AnalyzingInfixSuggester after building
[
https://issues.apache.org/jira/browse/OAK-7630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711974#comment-16711974
]
Vikas Saurabh commented on OAK-7630:
Backport on 1.6 at [r1848352|https://svn.apache.org/1848352].
> Suggest directory update doesn't close AnalyzingInfixSuggester after building
> -
>
> Key: OAK-7630
> URL: https://issues.apache.org/jira/browse/OAK-7630
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.8.0
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
> Fix For: 1.10, 1.9.6, 1.8.6, 1.6.16
>
>
> {{SuggestHelper#updateSuggester}} updates suggester by doing a {{build()}} on
> a newly created instance of {{AnalyzingInfixSuggester}}. But it never closes
> the suggester instance, which, in turn, leads to un-closed reader. With FS
> based directory (when copy-on-write is enabled), this leads to leaking file
> handles. FSDirectory does get closed on GC though.
> The issue was reported by [~mreutegg]
--
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=16711905#comment-16711905
]
Hudson commented on OAK-7941:
-
Previously failing build now is OK.
Passed run: [Jackrabbit Oak
#1838|https://builds.apache.org/job/Jackrabbit%20Oak/1838/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/1838/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-7941) Test failure: IndexCopierTest.directoryContentMismatch_COR
[
https://issues.apache.org/jira/browse/OAK-7941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711731#comment-16711731
]
Hudson commented on OAK-7941:
-
Previously failing build now is OK.
Passed run: [Jackrabbit Oak
#1837|https://builds.apache.org/job/Jackrabbit%20Oak/1837/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/1837/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-7941) Test failure: IndexCopierTest.directoryContentMismatch_COR
[
https://issues.apache.org/jira/browse/OAK-7941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711597#comment-16711597
]
Hudson commented on OAK-7941:
-
Previously failing build now is OK.
Passed run: [Jackrabbit Oak
#1836|https://builds.apache.org/job/Jackrabbit%20Oak/1836/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/1836/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] [Created] (OAK-7948) Make it possible to use StatisticsProvider to register metrics for QueryEngine
Tommaso Teofili created OAK-7948:
Summary: Make it possible to use StatisticsProvider to register
metrics for QueryEngine
Key: OAK-7948
URL: https://issues.apache.org/jira/browse/OAK-7948
Project: Jackrabbit Oak
Issue Type: Task
Components: query
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili
As discussed in OAK-7094 and on https://markmail.org/thread/w57nakppekhhahl7 it
should be possible to register metrics for the Oak query engine using the
{{StatisticsProvider}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (OAK-7946) Doc / size index stats fails when indexes not loaded
[ https://issues.apache.org/jira/browse/OAK-7946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili reassigned OAK-7946: Assignee: Tommaso Teofili > Doc / size index stats fails when indexes not loaded > > > Key: OAK-7946 > URL: https://issues.apache.org/jira/browse/OAK-7946 > Project: Jackrabbit Oak > Issue Type: Task > Components: lucene >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili >Priority: Major > > As a follow up to OAK-7893, it seems that sometimes the index size and doc > count stats cannot be calculated because the underlying Lucene index cannot > be obtained either because the repository is not yet started or because the > indexes weren't previously loaded / accessed except from within the stats > calculation callback. -- 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=16711507#comment-16711507 ] Thomas Mueller commented on OAK-7947: - The attached solves the issue. It contains various changes, possibly some of them are not needed, and some might be incorrect / problematic. This is work-in-progress. Still it would be nice to get some feedback from those who are more familiar with this code, for example [~catholicon] [~teofili] [~chetanm]. Changes I did: * IndexTracker.getIndexDefinition constructs the node and returns it if the index isn't in the indices map yet. I don't know why it returned null before, it seems wrong to me. * LuceneIndexNodeManager always opened the index, I don't know why. SearcherHolder now doesn't always do that. I basically make SearcherHolder open the index lazily. * LucenePropertyIndex acquireIndexNode is called when planning, and that method opens the index files. I don't know why. I created a class LazyLuceneIndexNode that wraps LuceneIndexNode and creates it lazily. * OakStreamingIndexFile now logs the directory name as well, not just the file name. * DefaultIndexReader now opens the directory (DirectoryReader.open) lazily; only when calling getReader. * FulltextIndexPlanner.estimatedEntryCount now only calls getNumDocs when really needed (that is, only if "entryCount" isn't set in the index definition). That should avoid having to open the index if we know the entryCount is high. > 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)
[jira] [Updated] (OAK-7947) Lazy loading of Lucene index files startup
[ https://issues.apache.org/jira/browse/OAK-7947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-7947: Attachment: OAK-7947.patch > 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)
[jira] [Created] (OAK-7947) Lazy loading of Lucene index files startup
Thomas Mueller created OAK-7947: --- Summary: 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 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)
[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=16711457#comment-16711457
]
Hudson commented on OAK-7941:
-
Previously failing build now is OK.
Passed run: [Jackrabbit Oak
#1835|https://builds.apache.org/job/Jackrabbit%20Oak/1835/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/1835/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] [Resolved] (OAK-7945) Document the recover-journal command
[ https://issues.apache.org/jira/browse/OAK-7945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Mari resolved OAK-7945. - Resolution: Fixed Fix Version/s: 1.9.13 Fixed at r1848302. > Document the recover-journal command > > > Key: OAK-7945 > URL: https://issues.apache.org/jira/browse/OAK-7945 > Project: Jackrabbit Oak > Issue Type: Documentation > Components: segment-tar >Reporter: Francesco Mari >Assignee: Francesco Mari >Priority: Major > Fix For: 1.10, 1.9.13 > > > Add documentation for the recover-journal command. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7932) A distributed segment store for the cloud
[
https://issues.apache.org/jira/browse/OAK-7932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711389#comment-16711389
]
Axel Hanikel commented on OAK-7932:
---
[~mduerig] Yes, I think we were talking about this during the September
Oakathon.
The "root" socket does not publish the root segment, but the RecordId of the
head - basically what would normally be written to the journal.log. Probably I
should have named it differently: {{headWriterSocket}} or
{{journalWriterSocket}}.
> A distributed segment store for the cloud
> -
>
> Key: OAK-7932
> URL: https://issues.apache.org/jira/browse/OAK-7932
> Project: Jackrabbit Oak
> Issue Type: Wish
> Components: segment-tar
>Reporter: Axel Hanikel
>Assignee: Axel Hanikel
>Priority: Minor
>
> h1. Outline
> This issue documents some proof-of-concept work for adapting the segment tar
> nodestore to a
> distributed environment. The main idea is to adopt an actor-like model,
> meaning:
> - Communication between actors (services) is done exclusively via messages.
> - An actor (which could also be a thread) processes one message at a time,
> avoiding sharing
> state with other actors as far as possible.
> - Segments are kept in RAM and are written to external storage lazily only
> for disaster recovery.
> - As RAM is a very limited resource, different actors own their share of
> the total segment space.
> - An actor can also cache a few segments which it does not own but which
> it uses often (such as
> the one containing the root node)
> - The granularity of operating on whole segments may be too coarse, so
> perhaps reducing the segment
> size would improve performance.
> - We could even use the segment solely as an addressing component and
> operate at the record level.
> That would avoid copying data around when collecting garbage: garbage
> records would just be
> evicted from RAM.
> h1. Implementation
> The first idea was to use ZeroMQ for communication because it seems to be a
> high-quality and
> easy to use implementation. A major drawback is that the library is written
> in C and the Java
> library which does the JNI stuff seems hard to set up and did not work for
> me. There is a native
> Java implementation of the ZeroMQ protocol, aptly called jeromq, which seems
> to work well so far,
> but I don't know about its performance yet.
> There is an attempt to use jeromq in the segment store in a very very very
> early stage at
> [https://github.com/ahanikel/jackrabbit-oak/tree/zeromq] . It is based on the
> memory segment store
> and currently just replaces direct function calls for reading and writing
> segments with messages being
> sent and received.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OAK-7946) Doc / size index stats fails when indexes not loaded
Tommaso Teofili created OAK-7946: Summary: Doc / size index stats fails when indexes not loaded Key: OAK-7946 URL: https://issues.apache.org/jira/browse/OAK-7946 Project: Jackrabbit Oak Issue Type: Task Components: lucene Reporter: Tommaso Teofili As a follow up to OAK-7893, it seems that sometimes the index size and doc count stats cannot be calculated because the underlying Lucene index cannot be obtained either because the repository is not yet started or because the indexes weren't previously loaded / accessed except from within the stats calculation callback. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7937) Implement CugAccessControlManager.getEffectivePolicies(Set principals)
[ https://issues.apache.org/jira/browse/OAK-7937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711273#comment-16711273 ] angela commented on OAK-7937: - [~stillalex], i commented on the feature branch. what i meant regarding everyone was the following: it is part of the design that every effective cug policy affects almost every single principal (exceptions are defined by the CugExclude): principals listed in the policy will be granted read, while all others (except for those in cugexclude) will be denied read access. that's what i meant with the _everyone_ group. the question was: do we really want to treat the deny-for-everyone the same way and thus return all CUG-policies defined in the repository because they effectively prevent the set of principals to read at those locations? and i am not sure this is really sensible if there were thousands of cugs present... so we might remember ourselves that the method is only guaranteed to be besteffort and thus ignore the everyone-case. but since i already mention the cug-exclude: if any principal is of the passed set is excluded we should probably also shortcut and return an empty array. > Implement CugAccessControlManager.getEffectivePolicies(Set > principals) > - > > Key: OAK-7937 > URL: https://issues.apache.org/jira/browse/OAK-7937 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: angela >Assignee: Alex Deparvu >Priority: Major > Fix For: 1.10 > > > today CugAccessControlManager.getEffectivePolicies(Set principals) > returns an empty array and has a comment stating that this is not implemented. > having thought this through again, i think there was some benefit in having > the implementation. as long as the given set of principal does NOT include > everyone the return value should just include the CUG-policies that > explicitly list any of principals. IF _everyone_ was part of the set, the > return-value basically includes _all_ CUG-policies, because every CUG will > deny read-access for everyone except for the principals explicitly listed in > the CUG-policy... if we do the latter as lazy as possible it might still be > doable even in a scenario, when there are tons of CUG-policies specified. > [~stillalex], wdyt? do you want to take care of this? -- 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=16711259#comment-16711259
]
Alex Deparvu commented on OAK-7906:
---
took some time to work on setting up jdk12 build on travis [0] and appveyor
(win support) [1]. the builds don't seem stable yet, but if there's anything to
report I'll post here.
appveyor seems to offer win support, so hopefully we can reproduce the build
issues in a way that could be shared (not just on individual machines):
{noformat}
Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
2018-10-24T18:41:47Z)
Maven home: C:\maven\apache-maven-3.6.0\bin\..
Java version: 12-ea, vendor: Oracle Corporation, runtime: C:\jdk12\jdk-12
Default locale: en_US, platform encoding: Cp1252
OS name: "windows server 2016", version: "10.0", arch: "amd64", family:
"windows"
{noformat}
[0] https://travis-ci.org/stillalex/jackrabbit-oak/builds/458708054
[1] https://ci.appveyor.com/project/stillalex/jackrabbit-oak
> 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] [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=16711255#comment-16711255 ] Robert Munteanu commented on OAK-7906: -- Ah ok, I did not know that. > 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] [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=16711251#comment-16711251 ] Julian Reschke commented on OAK-7906: - Actually, it *is* reported :-). Might not have a public issue though. > 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] [Created] (OAK-7945) Document the recover-journal command
Francesco Mari created OAK-7945: --- Summary: Document the recover-journal command Key: OAK-7945 URL: https://issues.apache.org/jira/browse/OAK-7945 Project: Jackrabbit Oak Issue Type: Documentation Components: segment-tar Reporter: Francesco Mari Assignee: Francesco Mari Fix For: 1.10 Add documentation for the recover-journal command. -- 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=16711211#comment-16711211 ] Robert Munteanu commented on OAK-7906: -- Then it looks like a JDK bug, right? Might be worth reporting. > 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] [Resolved] (OAK-7925) OakUpgrade for RDBMK: user name and password must match
[
https://issues.apache.org/jira/browse/OAK-7925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomek Rękawek resolved OAK-7925.
Resolution: Fixed
> OakUpgrade for RDBMK: user name and password must match
> ---
>
> Key: OAK-7925
> URL: https://issues.apache.org/jira/browse/OAK-7925
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: upgrade
>Affects Versions: 1.0.39, 1.0.42, 1.2.30, 1.4.23, 1.6.15, 1.8.9
>Reporter: Thomas Mueller
>Assignee: Tomek Rękawek
>Priority: Major
> Fix For: 1.10, 1.0.43, 1.2.31, 1.4.24, 1.8.10, 1.6.16, 1.9.13
>
>
> The oak-upgrade MigrationOptions class has a very ugly bug:
> {noformat}
> this.srcUser = args.getOption(OptionParserFactory.SRC_USER);
> this.srcPassword = args.getOption(OptionParserFactory.SRC_USER);
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
