[jira] [Comment Edited] (OAK-8710) AbstractLoginModule#logout() may fail in the presence of unknown principals
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16968404#comment-16968404
]
Manfred Baedke edited comment on OAK-8710 at 11/6/19 9:20 PM:
--
[~angela],
Re tests: I was trying to stay in line with other tests in the same test class
(like testLogoutSuccessClearsSubject()), which test single aspects of the
contract only and also do not login. TestLoginModule#login() doesn't do
anything anyway. But yes, in view of that JAAS tech notes, that needs to be
reworked.
was (Author: baedke):
[~angela],
Re tests: I was trying to keep in line with other tests in the same test class
(like testLogoutSuccessClearsSubject()), which test single aspects of the
contract only and also do not login. TestLoginModule#login() doesn't do
anything anyway. But yes, in view of that JAAS tech notes, that needs to be
reworked.
> AbstractLoginModule#logout() may fail in the presence of unknown principals
> ---
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security-spi
>Reporter: Manfred Baedke
>Assignee: Angela Schreiber
>Priority: Major
>
> See
> https://github.com/apache/jackrabbit-oak/blob/9569d659f0655d3ba16c1cfe1fbb5f53959f701f/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/AbstractLoginModule.java#L189:
> The criterion for logout() to succeed is
> {code}!subject.getPrincipals().isEmpty() &&
> !subject.getPublicCredentials(Credentials.class).isEmpty(){code}
> This did not work in a case where the subject was created by a thread
> handling an authenticated JMX connection (and later passed on to other
> threads due to AccessControlContext inheritage).
> I'd propose to make logout() succeed unconditionally, but I'm not entirely
> sure about side effects.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8710) AbstractLoginModule#logout() may fail in the presence of unknown principals
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16968476#comment-16968476
]
Angela Schreiber commented on OAK-8710:
---
[~baedke], ok. i guess what is really important for the issue at hand is that
only principals/credentials that have been set by the commit of this login
module get removed upon logout (or destroyed in case the subject is readonly).
will ping you to review the patch (and tests) to make sure we have the same
reading of the contract and to make sure the original issue reported with jmx
gets actually solved.
> AbstractLoginModule#logout() may fail in the presence of unknown principals
> ---
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security-spi
>Reporter: Manfred Baedke
>Assignee: Angela Schreiber
>Priority: Major
>
> See
> https://github.com/apache/jackrabbit-oak/blob/9569d659f0655d3ba16c1cfe1fbb5f53959f701f/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/AbstractLoginModule.java#L189:
> The criterion for logout() to succeed is
> {code}!subject.getPrincipals().isEmpty() &&
> !subject.getPublicCredentials(Credentials.class).isEmpty(){code}
> This did not work in a case where the subject was created by a thread
> handling an authenticated JMX connection (and later passed on to other
> threads due to AccessControlContext inheritage).
> I'd propose to make logout() succeed unconditionally, but I'm not entirely
> sure about side effects.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8740) Build Jackrabbit Oak #2479 failed
[ https://issues.apache.org/jira/browse/OAK-8740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16968461#comment-16968461 ] Hudson commented on OAK-8740: - Previously failing build now is OK. Passed run: [Jackrabbit Oak #2486|https://builds.apache.org/job/Jackrabbit%20Oak/2486/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2486/console] > Build Jackrabbit Oak #2479 failed > - > > Key: OAK-8740 > URL: https://issues.apache.org/jira/browse/OAK-8740 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2479 has failed. > First failed run: [Jackrabbit Oak > #2479|https://builds.apache.org/job/Jackrabbit%20Oak/2479/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2479/console] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8710) AbstractLoginModule#logout() may fail in the presence of unknown principals
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16968404#comment-16968404
]
Manfred Baedke commented on OAK-8710:
-
[~angela],
Re tests: I was trying to keep in line with other tests in the same test class
(like testLogoutSuccessClearsSubject()), which test single aspects of the
contract only and also do not login. TestLoginModule#login() doesn't do
anything anyway. But yes, in view of that JAAS tech notes, that needs to be
reworked.
> AbstractLoginModule#logout() may fail in the presence of unknown principals
> ---
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security-spi
>Reporter: Manfred Baedke
>Assignee: Angela Schreiber
>Priority: Major
>
> See
> https://github.com/apache/jackrabbit-oak/blob/9569d659f0655d3ba16c1cfe1fbb5f53959f701f/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/AbstractLoginModule.java#L189:
> The criterion for logout() to succeed is
> {code}!subject.getPrincipals().isEmpty() &&
> !subject.getPublicCredentials(Credentials.class).isEmpty(){code}
> This did not work in a case where the subject was created by a thread
> handling an authenticated JMX connection (and later passed on to other
> threads due to AccessControlContext inheritage).
> I'd propose to make logout() succeed unconditionally, but I'm not entirely
> sure about side effects.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-5858) Lucene index may return the wrong result if path is excluded
[
https://issues.apache.org/jira/browse/OAK-5858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-5858:
Fix Version/s: (was: 1.20.0)
> Lucene index may return the wrong result if path is excluded
>
>
> Key: OAK-5858
> URL: https://issues.apache.org/jira/browse/OAK-5858
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Thomas Mueller
>Priority: Major
>
> If a query uses a Lucene index that has "excludedPaths", the query result may
> be wrong (not contain all matching nodes). This is case even if there is a
> property index available for the queried property. Example:
> {noformat}
> Indexes:
> /oak:index/resourceType/type = "property"
> /oak:index/lucene/type = "lucene"
> /oak:index/lucene/excludedPaths = ["/etc"]
> /oak:index/lucene/indexRules/nt:base/properties/resourceType
> Query:
> /jcr:root/etc//*[jcr:like(@resourceType, "x%y")]
> Index cost:
> cost for /oak:index/resourceType is 1602.0
> cost for /oak:index/lucene is 1001.0
> Result:
> (empty)
> Expected result:
> /etc/a
> /etc/b
> {noformat}
> Here, the lucene index is picked, even thought the query explicitly queries
> for /etc, and the lucene index has this path excluded.
> I think the lucene index should not be picked in case the index does not
> match the query path.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-5980) Bad Join Query Plan Used
[
https://issues.apache.org/jira/browse/OAK-5980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-5980:
Fix Version/s: (was: 1.20.0)
> Bad Join Query Plan Used
>
>
> Key: OAK-5980
> URL: https://issues.apache.org/jira/browse/OAK-5980
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
>
> For a join query, where selectors are joined over ischildnode but also can
> use an index,
> the selectors sometimes use the index instead of the much less
> expensive parent join. Example:
> {noformat}
> select [a].* from [nt:unstructured] as [a]
> inner join [nt:unstructured] as [b] on ischildnode([b], [a])
> inner join [nt:unstructured] as [c] on ischildnode([c], [b])
> inner join [nt:unstructured] as [d] on ischildnode([d], [c])
> inner join [nt:unstructured] as [e] on ischildnode([e], [d])
> where [a].[classname] = 'letter'
> and isdescendantnode([a], '/content')
> and [c].[classname] = 'chapter'
> and localname([b]) = 'chapters'
> and [e].[classname] = 'list'
> and localname([d]) = 'lists'
> and [e].[path] = cast('/content/abc' as path)
> {noformat}
> The order of selectors is sometimes wrong (not e, d, c, b, a), but
> more importantly, selectors c and a use the index on className.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-5739) Misleading traversal warning for spellcheck queries without index
[
https://issues.apache.org/jira/browse/OAK-5739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-5739:
Fix Version/s: (was: 1.20.0)
> Misleading traversal warning for spellcheck queries without index
> -
>
> Key: OAK-5739
> URL: https://issues.apache.org/jira/browse/OAK-5739
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
>
> In OAK-4313 we avoid traversal for native queries, but we see in some cases
> traversal warnings as follows:
> {noformat}
> org.apache.jackrabbit.oak.query.QueryImpl query plan
> [nt:base] as [a] /* traverse "" where (spellcheck([a], 'NothingToFind'))
> and (issamenode([a], [/])) */
> org.apache.jackrabbit.oak.query.QueryImpl Traversal query (query without
> index):
> select [jcr:path], [jcr:score], [rep:spellcheck()] from [nt:base] as a where
> spellcheck('NothingToFind')
> and issamenode(a, '/')
> /* xpath: /jcr:root
> [rep:spellcheck('NothingToFind')]/(rep:spellcheck()) */;
> consider creating an index
> {noformat}
> This warning is misleading. If no index is available, then either the query
> should fail, or the warning should say that the query result is not correct
> because traversal is used.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-5706) Function based indexes with "like" conditions
[
https://issues.apache.org/jira/browse/OAK-5706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-5706:
Fix Version/s: (was: 1.20.0)
> Function based indexes with "like" conditions
> -
>
> Key: OAK-5706
> URL: https://issues.apache.org/jira/browse/OAK-5706
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: indexing
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
>
> Currently, a function-based index is not used when using "like" conditions,
> as follows:
> {noformat}
> /jcr:root//*[jcr:like(fn:lower-case(fn:name()), 'abc%')]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (OAK-5369) Lucene Property Index: Syntax Error, cannot parse
[
https://issues.apache.org/jira/browse/OAK-5369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller resolved OAK-5369.
-
Resolution: Won't Fix
> Lucene Property Index: Syntax Error, cannot parse
> -
>
> Key: OAK-5369
> URL: https://issues.apache.org/jira/browse/OAK-5369
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.20.0
>
>
> The following query throws an exception in Apache Lucene:
> {noformat}
> /jcr:root//*[jcr:contains(., 'hello -- world')]
> 22.12.2016 16:42:54.511 *WARN* [qtp1944702753-3846]
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex query via
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex@1c0006db
> failed.
> java.lang.RuntimeException: INVALID_SYNTAX_CANNOT_PARSE: Syntax Error, cannot
> parse hello -- world:
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.tokenToQuery(LucenePropertyIndex.java:1450)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.tokenToQuery(LucenePropertyIndex.java:1418)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.access$900(LucenePropertyIndex.java:180)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$3.visitTerm(LucenePropertyIndex.java:1353)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$3.visit(LucenePropertyIndex.java:1307)
> at
> org.apache.jackrabbit.oak.query.fulltext.FullTextContains.accept(FullTextContains.java:63)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.getFullTextQuery(LucenePropertyIndex.java:1303)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.getLuceneRequest(LucenePropertyIndex.java:791)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.access$300(LucenePropertyIndex.java:180)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$1.loadDocs(LucenePropertyIndex.java:375)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$1.computeNext(LucenePropertyIndex.java:317)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$1.computeNext(LucenePropertyIndex.java:306)
> at
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
> at
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$LucenePathCursor$1.hasNext(LucenePropertyIndex.java:1571)
> at com.google.common.collect.Iterators$7.computeNext(Iterators.java:645)
> at
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
> at
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
> at
> org.apache.jackrabbit.oak.spi.query.Cursors$PathCursor.hasNext(Cursors.java:205)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$LucenePathCursor.hasNext(LucenePropertyIndex.java:1595)
> at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.next(SelectorImpl.java:420)
> at
> org.apache.jackrabbit.oak.query.QueryImpl$RowIterator.fetchNext(QueryImpl.java:828)
> at
> org.apache.jackrabbit.oak.query.QueryImpl$RowIterator.hasNext(QueryImpl.java:853)
> at
> org.apache.jackrabbit.oak.jcr.query.QueryResultImpl$1.fetch(QueryResultImpl.java:98)
> at
> org.apache.jackrabbit.oak.jcr.query.QueryResultImpl$1.(QueryResultImpl.java:94)
> at
> org.apache.jackrabbit.oak.jcr.query.QueryResultImpl.getRows(QueryResultImpl.java:78)
> Caused by:
> org.apache.lucene.queryparser.flexible.standard.parser.ParseException: Syntax
> Error, cannot parse hello -- world:
> at
> org.apache.lucene.queryparser.flexible.standard.parser.StandardSyntaxParser.generateParseException(StandardSyntaxParser.java:1054)
> at
> org.apache.lucene.queryparser.flexible.standard.parser.StandardSyntaxParser.jj_consume_token(StandardSyntaxParser.java:936)
> at
> org.apache.lucene.queryparser.flexible.standard.parser.StandardSyntaxParser.Clause(StandardSyntaxParser.java:486)
> at
> org.apache.lucene.queryparser.flexible.standard.parser.StandardSyntaxParser.ModClause(StandardSyntaxParser.java:303)
> at
> org.apache.lucene.queryparser.flexible.standard.parser.StandardSyntaxParser.ConjQuery(StandardSyntaxParser.java:234)
> at
> org.apache.lucene.queryparser.flexible.standard.parser.StandardSyntaxParser.DisjQuery(StandardSyntaxParser.java:204)
> at
>
[jira] [Updated] (OAK-3866) Sorting on relative properties doesn't work in Solr
[
https://issues.apache.org/jira/browse/OAK-3866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-3866:
Fix Version/s: (was: 1.20.0)
> Sorting on relative properties doesn't work in Solr
> ---
>
> Key: OAK-3866
> URL: https://issues.apache.org/jira/browse/OAK-3866
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: solr
>Affects Versions: 1.0.22, 1.2.9, 1.3.13
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
>Priority: Major
>
> Executing a query like
> {noformat}
> /jcr:root/content/foo//*[(@sling:resourceType = 'x' or @sling:resourceType =
> 'y') and jcr:contains(., 'bar*~')] order by jcr:content/@jcr:primaryType
> descending
> {noformat}
> would assume sorting on the _jcr:primaryType_ property of resulting nodes'
> _jcr:content_ children.
> That is currently not supported in Solr, while it is in Lucene as the latter
> supports index time aggregation.
> We should inspect if it's possible to extend support for Solr too, most
> probably via index time aggregation.
> The query should not fail but at least log a warning about that limitation
> for the time being.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-3437) Regression in org.apache.jackrabbit.core.query.JoinTest#testJoinWithOR5 when enabling OAK-1617
[
https://issues.apache.org/jira/browse/OAK-3437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-3437:
Fix Version/s: (was: 1.20.0)
> Regression in org.apache.jackrabbit.core.query.JoinTest#testJoinWithOR5 when
> enabling OAK-1617
> --
>
> Key: OAK-3437
> URL: https://issues.apache.org/jira/browse/OAK-3437
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: solr
>Reporter: Davide Giannella
>Assignee: Tommaso Teofili
>Priority: Major
>
> When enabling OAK-1617 (still to be committed) there's a regression in the
> {{oak-solr-core}} unit tests
> - {{org.apache.jackrabbit.core.query.JoinTest#testJoinWithOR3}}
> - {{org.apache.jackrabbit.core.query.JoinTest#testJoinWithOR4}}
> - {{org.apache.jackrabbit.core.query.JoinTest#testJoinWithOR5}}
> The WIP of the feature can be found in
> https://github.com/davidegiannella/jackrabbit-oak/tree/OAK-1617 and a full
> patch will be attached shortly for review in OAK-1617 itself.
> The feature is currently disabled, in order to enable it for unit testing an
> approach like this can be taken
> https://github.com/davidegiannella/jackrabbit-oak/blob/177df1a8073b1237857267e23d12a433e3d890a4/oak-core/src/test/java/org/apache/jackrabbit/oak/query/SQL2OptimiseQueryTest.java#L142
> or setting the system property {{-Doak.query.sql2optimisation}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-6387) Building an index (new index + reindex): temporarily store blob references
[ https://issues.apache.org/jira/browse/OAK-6387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-6387: Fix Version/s: (was: 1.20.0) > Building an index (new index + reindex): temporarily store blob references > -- > > Key: OAK-6387 > URL: https://issues.apache.org/jira/browse/OAK-6387 > Project: Jackrabbit Oak > Issue Type: Bug > Components: lucene, query >Reporter: Thomas Mueller >Priority: Major > > If reindexing a Lucene index takes multiple days, and if datastore garbage > collection (DSGC) is run during that time, then DSGC may remove binaries of > that index because they are not referenced. > It would be good if all binaries that are needed, and that are older than > (for example) one hour, are referenced during reindexing (for example in a > temporary location). So that DSGC will not remove them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-6597) rep:excerpt not working for content indexed by aggregation in lucene
[
https://issues.apache.org/jira/browse/OAK-6597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-6597:
Fix Version/s: (was: 1.20.0)
> rep:excerpt not working for content indexed by aggregation in lucene
>
>
> Key: OAK-6597
> URL: https://issues.apache.org/jira/browse/OAK-6597
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.6.1, 1.7.6, 1.8.0
>Reporter: Dirk Rudolph
>Assignee: Chetan Mehrotra
>Priority: Major
> Labels: excerpt
> Attachments: excerpt-with-aggregation-test.patch
>
>
> I mentioned that properties that got indexed due to an aggregation are not
> considered for excerpts (highlighting) as they are not indexed as stored
> fields.
> See the attached patch that implements a test for excerpts in
> {{LuceneIndexAggregationTest2}}.
> It creates the following structure:
> {code}
> /content/foo [test:Page]
> + bar (String)
> - jcr:content [test:PageContent]
> + bar (String)
> {code}
> where both strings (the _bar_ property at _foo_ and the _bar_ property at
> _jcr:content_) contain different text.
> Afterwards it queries for 2 terms ("tinc*" and "aliq*") that either exist in
> _/content/foo/bar_ or _/content/foo/jcr:content/bar_ but not in both. For the
> former one the excerpt is properly provided for the later one it isn't.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-7166) Union with different selector names
[
https://issues.apache.org/jira/browse/OAK-7166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-7166:
Fix Version/s: (was: 1.20.0)
> Union with different selector names
> ---
>
> Key: OAK-7166
> URL: https://issues.apache.org/jira/browse/OAK-7166
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
>
> The following query returns the wrong nodes:
> {noformat}
> /jcr:root/libs/(* | */* | */*/* | */*/*/* | */*/*/*/*)/install
> select b.[jcr:path] as [jcr:path], b.[jcr:score] as [jcr:score], b.* from
> [nt:base] as a
> inner join [nt:base] as b on ischildnode(b, a)
> where ischildnode(a, '/libs') and name(b) = 'install'
> union select c.[jcr:path] as [jcr:path], c.[jcr:score] as [jcr:score], c.*
> from [nt:base] as a
> inner join [nt:base] as b on ischildnode(b, a)
> inner join [nt:base] as c on ischildnode(c, b)
> where ischildnode(a, '/libs') and name(c) = 'install'
> union select d.[jcr:path] as [jcr:path], d.[jcr:score] as [jcr:score], d.*
> from [nt:base] as a
> inner join [nt:base] as b on ischildnode(b, a)
> inner join [nt:base] as c on ischildnode(c, b)
> inner join [nt:base] as d on ischildnode(d, c)
> where ischildnode(a, '/libs') and name(d) = 'install'
> {noformat}
> If I change the selector name to "x" in each subquery, then it works. There
> is no XPath version of this workaround:
> {noformat}
> select x.[jcr:path] as [jcr:path], x.[jcr:score] as [jcr:score], x.* from
> [nt:base] as a
> inner join [nt:base] as x on ischildnode(x, a)
> where ischildnode(a, '/libs') and name(x) = 'install'
> union select x.[jcr:path] as [jcr:path], x.[jcr:score] as [jcr:score], x.*
> from [nt:base] as a
> inner join [nt:base] as b on ischildnode(b, a)
> inner join [nt:base] as x on ischildnode(x, b)
> where ischildnode(a, '/libs') and name(x) = 'install'
> union select x.[jcr:path] as [jcr:path], x.[jcr:score] as [jcr:score], x.*
> from [nt:base] as a
> inner join [nt:base] as b on ischildnode(b, a)
> inner join [nt:base] as c on ischildnode(c, b)
> inner join [nt:base] as x on ischildnode(x, c)
> where ischildnode(a, '/libs') and name(x) = 'install'
> {noformat}
> Need to check if this is a Oak bug, or a bug in the query tool I use.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-7263) oak-lucene should not depend on oak-store-document
[
https://issues.apache.org/jira/browse/OAK-7263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-7263:
Fix Version/s: (was: 1.20.0)
> oak-lucene should not depend on oak-store-document
> --
>
> Key: OAK-7263
> URL: https://issues.apache.org/jira/browse/OAK-7263
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Robert Munteanu
>Priority: Major
>
> {{oak-lucene}} has a hard dependency on {{oak-store-document}} and that looks
> wrong to me.
> {noformat}[ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile
> (default-compile) on project oak-lucene: Compilation failure: Compilation
> failure:
> [ERROR]
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneDocumentHolder.java:[31,54]
> package org.apache.jackrabbit.oak.plugins.document.spi does not exist
> [ERROR]
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneDocumentHolder.java:[37,46]
> cannot find symbol
> [ERROR] symbol: class JournalProperty
> [ERROR]
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyBuilder.java:[33,54]
> package org.apache.jackrabbit.oak.plugins.document.spi does not exist
> [ERROR]
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyBuilder.java:[34,54]
> package org.apache.jackrabbit.oak.plugins.document.spi does not exist
> [ERROR]
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyBuilder.java:[38,47]
> cannot find symbol
> [ERROR] symbol: class JournalPropertyBuilder
> [ERROR]
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyBuilder.java:[106,12]
> cannot find symbol
> [ERROR] symbol: class JournalProperty
> [ERROR] location: class
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.LuceneJournalPropertyBuilder
> [ERROR]
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LuceneIndexProviderService.java:[55,54]
> package org.apache.jackrabbit.oak.plugins.document.spi does not exist
> [ERROR]
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/IndexedPaths.java:[29,54]
> package org.apache.jackrabbit.oak.plugins.document.spi does not exist
> [ERROR]
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/IndexedPaths.java:[33,31]
> cannot find symbol
> [ERROR] symbol: class JournalProperty
> [ERROR]
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyService.java:[22,54]
> package org.apache.jackrabbit.oak.plugins.document.spi does not exist
> [ERROR]
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyService.java:[23,54]
> package org.apache.jackrabbit.oak.plugins.document.spi does not exist
> [ERROR]
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyService.java:[25,54]
> cannot find symbol
> [ERROR] symbol: class JournalPropertyService
> [ERROR]
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyService.java:[33,12]
> cannot find symbol
> [ERROR] symbol: class JournalPropertyBuilder
> [ERROR] location: class
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.LuceneJournalPropertyService
> [ERROR]
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyBuilder.java:[50,5]
> method does not override or implement a method from a supertype
> [ERROR]
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyBuilder.java:[61,5]
> method does not override or implement a method from a supertype
> [ERROR]
>
[jira] [Commented] (OAK-7370) order by jcr:score desc doesn't work across union query created by optimizing OR clauses
[
https://issues.apache.org/jira/browse/OAK-7370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16968356#comment-16968356
]
Thomas Mueller commented on OAK-7370:
-
Thanks [~catholicon]! I removed the fix version.
> order by jcr:score desc doesn't work across union query created by optimizing
> OR clauses
>
>
> Key: OAK-7370
> URL: https://issues.apache.org/jira/browse/OAK-7370
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: Vikas Saurabh
>Assignee: Thomas Mueller
>Priority: Major
>
> Merging of sub-queries created due to optimizing OR clauses doesn't work for
> sorting on {{jcr:score}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-7370) order by jcr:score desc doesn't work across union query created by optimizing OR clauses
[
https://issues.apache.org/jira/browse/OAK-7370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-7370:
Fix Version/s: (was: 1.20.0)
> order by jcr:score desc doesn't work across union query created by optimizing
> OR clauses
>
>
> Key: OAK-7370
> URL: https://issues.apache.org/jira/browse/OAK-7370
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: Vikas Saurabh
>Assignee: Thomas Mueller
>Priority: Major
>
> Merging of sub-queries created due to optimizing OR clauses doesn't work for
> sorting on {{jcr:score}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (OAK-7370) order by jcr:score desc doesn't work across union query created by optimizing OR clauses
[
https://issues.apache.org/jira/browse/OAK-7370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh reassigned OAK-7370:
--
Assignee: Thomas Mueller (was: Vikas Saurabh)
[~thomasm], assigning this issue to you. Also, I think we can remove
fixVersion, right?
> order by jcr:score desc doesn't work across union query created by optimizing
> OR clauses
>
>
> Key: OAK-7370
> URL: https://issues.apache.org/jira/browse/OAK-7370
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: Vikas Saurabh
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.20.0
>
>
> Merging of sub-queries created due to optimizing OR clauses doesn't work for
> sorting on {{jcr:score}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (OAK-6833) LuceneIndex*Test failures
[
https://issues.apache.org/jira/browse/OAK-6833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh resolved OAK-6833.
Fix Version/s: (was: 1.20.0)
Resolution: Cannot Reproduce
[~reschke], I think we haven't seen these failures for a long time. Resolving
this one as not reproducible. Please re-open if that's not correct.
> LuceneIndex*Test failures
> -
>
> Key: OAK-6833
> URL: https://issues.apache.org/jira/browse/OAK-6833
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Julian Reschke
>Assignee: Vikas Saurabh
>Priority: Major
> Attachments:
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexAugmentTest.xml,
>
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexAugmentTest.xml,
>
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexAugmentTest.xml,
>
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexAugmentTest.xml,
>
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexAugmentTest.xml,
>
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.xml,
>
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.xml,
>
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.xml,
>
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.xml,
>
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.xml,
>
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.xml,
>
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.xml,
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexAugmentTest.txt,
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexAugmentTest.txt,
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexAugmentTest.txt,
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexAugmentTest.txt,
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexAugmentTest.txt,
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.txt,
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.txt,
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.txt,
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.txt,
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.txt,
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.txt,
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.txt,
> unit-tests.log, unit-tests.log, unit-tests.log
>
>
> {noformat}
> [ERROR] testLuceneWithRelativeProperty[1: useBlobStore
> (false)](org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest)
> Time elapsed: 0.063 s <<< FAILURE!
> java.lang.AssertionError: expected: but was:
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.testLuceneWithRelativeProperty(LuceneIndexEditorTest.java:341)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-7261) DocumentStore: inconsistent behaviour for invalid Strings as document ID
[ https://issues.apache.org/jira/browse/OAK-7261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-7261: Fix Version/s: (was: 1.20.0) 1.22.0 > DocumentStore: inconsistent behaviour for invalid Strings as document ID > > > Key: OAK-7261 > URL: https://issues.apache.org/jira/browse/OAK-7261 > Project: Jackrabbit Oak > Issue Type: Bug > Components: documentmk, mongomk, rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Fix For: 1.22.0 > > > - H2DB and Derby roundtrip any string > - PostgreSQL rejects the invalid string early > - DB2 and Oracle fail the same way as segment store (they persist the > replacement character) (see OAK-5506) > - MySQL and SQLServer fail the same way as DB2 and Oracle, but here it's the > RDBDocumentStore's fault, because the ID column is binary, and we transform > to byte sequences ourselves > - Mongo claims it saved the document, but upon lookup, returns something > with a different ID > Note that due to how RDB reads work, the returned document has the ID that > was requested, not what the DB actually contains. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8743) org.apache.jackrabbit.oak.stats.Clock should extend from java.time.Clock
[ https://issues.apache.org/jira/browse/OAK-8743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8743: Fix Version/s: 1.22.0 > org.apache.jackrabbit.oak.stats.Clock should extend from java.time.Clock > > > Key: OAK-8743 > URL: https://issues.apache.org/jira/browse/OAK-8743 > Project: Jackrabbit Oak > Issue Type: Task > Components: core-spi >Reporter: Julian Reschke >Priority: Minor > Fix For: 1.22.0 > > Attachments: OAK-8743.diff > > > Why? > - simple > - might make it more versatile > - avoid surprises if we find out later that we need it and have become > incompatible in the meantime -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8743) org.apache.jackrabbit.oak.stats.Clock should extend from java.time.Clock
[ https://issues.apache.org/jira/browse/OAK-8743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16968326#comment-16968326 ] Julian Reschke commented on OAK-8743: - Scheduling for after 1.20.0, as this affects the API and would back tricky to remove again. > org.apache.jackrabbit.oak.stats.Clock should extend from java.time.Clock > > > Key: OAK-8743 > URL: https://issues.apache.org/jira/browse/OAK-8743 > Project: Jackrabbit Oak > Issue Type: Task > Components: core-spi >Reporter: Julian Reschke >Priority: Minor > Fix For: 1.22.0 > > Attachments: OAK-8743.diff > > > Why? > - simple > - might make it more versatile > - avoid surprises if we find out later that we need it and have become > incompatible in the meantime -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-6789) RDB: RevisionGC performance on Oracle
[
https://issues.apache.org/jira/browse/OAK-6789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-6789:
Labels: (was: candidate_oak_1_0 candidate_oak_1_2 candidate_oak_1_4)
> RDB: RevisionGC performance on Oracle
> -
>
> Key: OAK-6789
> URL: https://issues.apache.org/jira/browse/OAK-6789
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: rdbmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
> Fix For: 1.7.10, 1.6.7, 1.8.0
>
> Attachments: OAK-6789.diff
>
>
> In RevisionGC on Oracle, performance of deletes is bad. Using RevisionGCTest:
> {noformat}
> VersionGCStats{ignoredGCDueToCheckPoint=false, canceled=false,
> deletedDocGCCount=92092 (of which leaf: 92000), updateResurrectedGCCount=0,
> splitDocGCCount=1, intermediateSplitDocGCCount=0, iterationCount=2,
> timeActive=7.429 min, timeToCollectDeletedDocs=1394 ms,
> timeToCheckDeletedDocs=250.4 ms, timeToSortDocIds=374.0 us,
> timeTakenToUpdateResurrectedDocs=17.00 us, timeTakenToDeleteDeletedDocs=7.399
> min, timeTakenToCollectAndDeleteSplitDocs=97.95 ms}
> Performed RevisionGC in 7,429 min
> {noformat}
> Compared with DB2:
> {noformat}
> VersionGCStats{ignoredGCDueToCheckPoint=false, canceled=false,
> deletedDocGCCount=96096 (of which leaf: 96000), updateResurrectedGCCount=0,
> splitDocGCCount=1, intermediateSplitDocGCCount=0, iterationCount=2,
> timeActive=8.240 s, timeToCollectDeletedDocs=1780 ms,
> timeToCheckDeletedDocs=259.7 ms, timeToSortDocIds=237.0 us,
> timeTakenToUpdateResurrectedDocs=19.00 us, timeTakenToDeleteDeletedDocs=4.552
> s, timeTakenToCollectAndDeleteSplitDocs=685.4 ms}
> Performed RevisionGC in 8,243 s
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-7472) tests should pass with locking disabled
[ https://issues.apache.org/jira/browse/OAK-7472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-7472: Labels: (was: candidate_oak_1_4) > tests should pass with locking disabled > --- > > Key: OAK-7472 > URL: https://issues.apache.org/jira/browse/OAK-7472 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: jcr >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.10.0, 1.9.2, 1.8.8, 1.6.18 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-6852) RDBDocumentStore conditional remove: check condition properly
[ https://issues.apache.org/jira/browse/OAK-6852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-6852: Labels: (was: candidate_oak_1_0 candidate_oak_1_2 candidate_oak_1_4) > RDBDocumentStore conditional remove: check condition properly > - > > Key: OAK-6852 > URL: https://issues.apache.org/jira/browse/OAK-6852 > Project: Jackrabbit Oak > Issue Type: Bug > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Fix For: 1.7.10, 1.6.7, 1.8.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-7161) LengthCachingDataStore's use of LineIterator.close()
[
https://issues.apache.org/jira/browse/OAK-7161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16968302#comment-16968302
]
Julian Reschke commented on OAK-7161:
-
trunk: (1.9.0) [r1821237|http://svn.apache.org/r1821237]
1.8: (1.8.4) [r1832301|http://svn.apache.org/r1832301]
1.6: (1.6.13) [r1836534|http://svn.apache.org/r1836534]
1.4: [r1869460|http://svn.apache.org/r1869460]
> LengthCachingDataStore's use of LineIterator.close()
>
>
> Key: OAK-7161
> URL: https://issues.apache.org/jira/browse/OAK-7161
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: upgrade
> Environment: Later versions of commons-io added an exception to
> {{LineIterator.close()}}. See https://issues.apache.org/jira/browse/IO-505.
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
> Fix For: 1.9.0, 1.10.0, 1.8.4, 1.6.13, 1.4.25
>
> Attachments: OAK-7161.diff
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-7161) LengthCachingDataStore's use of LineIterator.close()
[
https://issues.apache.org/jira/browse/OAK-7161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-7161:
Fix Version/s: 1.4.25
> LengthCachingDataStore's use of LineIterator.close()
>
>
> Key: OAK-7161
> URL: https://issues.apache.org/jira/browse/OAK-7161
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: upgrade
> Environment: Later versions of commons-io added an exception to
> {{LineIterator.close()}}. See https://issues.apache.org/jira/browse/IO-505.
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
> Labels: candidate_oak_1_4
> Fix For: 1.9.0, 1.10.0, 1.8.4, 1.6.13, 1.4.25
>
> Attachments: OAK-7161.diff
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-7161) LengthCachingDataStore's use of LineIterator.close()
[
https://issues.apache.org/jira/browse/OAK-7161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-7161:
Labels: (was: candidate_oak_1_4)
> LengthCachingDataStore's use of LineIterator.close()
>
>
> Key: OAK-7161
> URL: https://issues.apache.org/jira/browse/OAK-7161
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: upgrade
> Environment: Later versions of commons-io added an exception to
> {{LineIterator.close()}}. See https://issues.apache.org/jira/browse/IO-505.
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
> Fix For: 1.9.0, 1.10.0, 1.8.4, 1.6.13, 1.4.25
>
> Attachments: OAK-7161.diff
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (OAK-7161) LengthCachingDataStore's use of LineIterator.close()
[
https://issues.apache.org/jira/browse/OAK-7161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-7161:
Comment: was deleted
(was: trunk: [r1821237|http://svn.apache.org/r1821237]
1.8: [r1832301|http://svn.apache.org/r1832301]
1.6: [r1836534|http://svn.apache.org/r1836534]
)
> LengthCachingDataStore's use of LineIterator.close()
>
>
> Key: OAK-7161
> URL: https://issues.apache.org/jira/browse/OAK-7161
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: upgrade
> Environment: Later versions of commons-io added an exception to
> {{LineIterator.close()}}. See https://issues.apache.org/jira/browse/IO-505.
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
> Fix For: 1.9.0, 1.10.0, 1.8.4, 1.6.13, 1.4.25
>
> Attachments: OAK-7161.diff
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8729) Lucene Directory concurrency issue
[
https://issues.apache.org/jira/browse/OAK-8729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16968297#comment-16968297
]
Mohit Kataria commented on OAK-8729:
[~thomasm],
One thing that I am still not sure is why we had not faced this issue
previously.
The close method for wrapForRead [1] calls remote.close and local.close [2]
[2]and same instance is being used by wrapForWrite[3].
Can we perform operations even if close had been called on Directory instance?
[1]:
[https://github.com/apache/jackrabbit-oak/blob/ab488781ec52d724ccd68862a3726e3023083857/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/directory/DefaultDirectoryFactory.java#L70]
[2]:
[https://github.com/apache/jackrabbit-oak/blob/trunk/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/directory/CopyOnReadDirectory.java#L304-L305]
[3]:
[https://github.com/apache/jackrabbit-oak/blob/ab488781ec52d724ccd68862a3726e3023083857/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/directory/DefaultDirectoryFactory.java#L72|https://github.com/apache/jackrabbit-oak/blob/ab488781ec52d724ccd68862a3726e3023083857/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/directory/DefaultDirectoryFactory.java#L70]
> Lucene Directory concurrency issue
> --
>
> Key: OAK-8729
> URL: https://issues.apache.org/jira/browse/OAK-8729
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Affects Versions: 1.12.0, 1.14.0, 1.16.0, 1.18.0
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.20.0
>
> Attachments: OAK-8729.patch
>
>
> There is a concurrency issue in the DefaultDirectoryFactory. It is
> reproducible sometimes using CopyOnWriteDirectoryTest.copyOnWrite(), if run
> in a loop (1000 times). The problem is that the MemoryNodeBuilder is used
> concurrently:
> * thread 1 is closing the directory (after writing to it)
> * thread 2 is trying to create a new file
> {noformat}
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.exists(MemoryNodeBuilder.java:284)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.setProperty(MemoryNodeBuilder.java:525)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.OakDirectory.close(OakDirectory.java:264)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.BufferedOakDirectory.close(BufferedOakDirectory.java:217)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnReadDirectory$2.run(CopyOnReadDirectory.java:305)
> 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)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.exists(MemoryNodeBuilder.java:284)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.setChildNode(MemoryNodeBuilder.java:362)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.setChildNode(MemoryNodeBuilder.java:356)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.child(MemoryNodeBuilder.java:342)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.OakDirectory.createOutput(OakDirectory.java:214)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.BufferedOakDirectory.createOutput(BufferedOakDirectory.java:178)
> at org.apache.lucene.store.Directory.copy(Directory.java:184)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnWriteDirectory$3.call(CopyOnWriteDirectory.java:322)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnWriteDirectory$3.call(CopyOnWriteDirectory.java:1)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnWriteDirectory$2$1.call(CopyOnWriteDirectory.java:105)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnWriteDirectory$2$1.call(CopyOnWriteDirectory.java:1)
> 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:745)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-7748) DocumentStore: test (and optionally optimize) bulk update fallback logic
[ https://issues.apache.org/jira/browse/OAK-7748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-7748: Labels: (was: candidate_oak_1_4) > DocumentStore: test (and optionally optimize) bulk update fallback logic > > > Key: OAK-7748 > URL: https://issues.apache.org/jira/browse/OAK-7748 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: documentmk, rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.10.0, 1.9.9, 1.6.15, 1.8.9 > > Attachments: OAK-7748-for-1.6.diff, OAK-7748.diff, OAK-7748.diff, > OAK-7748.diff > > > ...add a simple test that exercises the bulk update fallback logic -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-7333) RDBDocumentStore: refactor index report
[ https://issues.apache.org/jira/browse/OAK-7333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-7333: Labels: (was: candidate_oak_1_4) > RDBDocumentStore: refactor index report > --- > > Key: OAK-7333 > URL: https://issues.apache.org/jira/browse/OAK-7333 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.9.0, 1.10.0, 1.8.4, 1.6.18 > > > - use field names when accessing metadata > - dump more fields > - prepare for reporting missing indices -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-7181) RDBDocumentStore: use try-with-resources for ChangesTracker
[ https://issues.apache.org/jira/browse/OAK-7181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-7181: Labels: (was: candidate_oak_1_4) > RDBDocumentStore: use try-with-resources for ChangesTracker > --- > > Key: OAK-7181 > URL: https://issues.apache.org/jira/browse/OAK-7181 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Trivial > Fix For: 1.9.0, 1.10.0, 1.8.4, 1.6.18 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-7342) RDBDocumentStore: missing rollback after delete failures
[
https://issues.apache.org/jira/browse/OAK-7342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-7342:
Labels: (was: candidate_oak_1_0 candidate_oak_1_2 candidate_oak_1_4)
> RDBDocumentStore: missing rollback after delete failures
>
>
> Key: OAK-7342
> URL: https://issues.apache.org/jira/browse/OAK-7342
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: rdbmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 1.9.0, 1.10.0, 1.8.10, 1.6.18
>
>
> There are a few places where after an exception, the connections isn't rolled
> back (harmless, if the connection pool does it for us).
> This can be detected when running with PostgreSQL and setting
> {noformat}
> -Dorg.apache.jackrabbit.oak.plugins.document.rdb.RDBConnectionHandler.CHECKCONNECTIONONCLOSE=true
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-5855) RDBDocumentStore: improve query support for VersionGC
[
https://issues.apache.org/jira/browse/OAK-5855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-5855:
Labels: (was: candidate_oak_1_4)
> RDBDocumentStore: improve query support for VersionGC
> -
>
> Key: OAK-5855
> URL: https://issues.apache.org/jira/browse/OAK-5855
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: rdbmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 1.7.0, 1.6.6, 1.8.0
>
> Attachments: OAK-5855-10.diff, OAK-5855-11.diff, OAK-5855-12.diff,
> OAK-5855-13.diff, OAK-5855-14.diff, OAK-5855-15.diff, OAK-5855-16.diff
>
>
> ...matching {{MongoVersionSupport}}, such as: no batched query needed; just
> return an iterable over delete candidates.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (OAK-4652) indexName logged in QueryImpl is wrong in case of multiple indexes satisfying the query
[
https://issues.apache.org/jira/browse/OAK-4652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16968136#comment-16968136
]
Julian Reschke edited comment on OAK-4652 at 11/6/19 10:59 AM:
---
trunk: (1.5.8) [r1755295|http://svn.apache.org/r1755295]
1.4: [r1869458|http://svn.apache.org/r1869458]
was (Author: reschke):
trunk: (1.5.8) [r1755295|http://svn.apache.org/r1755295]
> indexName logged in QueryImpl is wrong in case of multiple indexes satisfying
> the query
> ---
>
> Key: OAK-4652
> URL: https://issues.apache.org/jira/browse/OAK-4652
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Labels: candidate_oak_1_2
> Fix For: 1.5.8, 1.6.0, 1.4.25
>
>
> QueryImpl currently computes the indexName like
> {code}
> for (IndexPlan p : ipList) {
> // TODO limit is after all conditions
> long entryCount = Math.min(maxEntryCount,
> p.getEstimatedEntryCount());
> double c = p.getCostPerExecution() + entryCount *
> p.getCostPerEntry();
> if (c < cost) {
> cost = c;
> if (p.getPlanName() != null) {
> indexName += "[" + p.getPlanName() + "]";
> }
> indexPlan = p;
> }
> }
> {code}
> If there are multiple index plans then indexName contains multiple plan names
> which causes confusion
> {noformat}
>cost for
> lucene-property[/oak:index/keymatchKeywords][/oak:index/newImport] is 786.0
> {noformat}
> Instead of concatenating the indexName should be generated outside
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-4652) indexName logged in QueryImpl is wrong in case of multiple indexes satisfying the query
[
https://issues.apache.org/jira/browse/OAK-4652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-4652:
Fix Version/s: 1.4.25
> indexName logged in QueryImpl is wrong in case of multiple indexes satisfying
> the query
> ---
>
> Key: OAK-4652
> URL: https://issues.apache.org/jira/browse/OAK-4652
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Labels: candidate_oak_1_2, candidate_oak_1_4
> Fix For: 1.5.8, 1.6.0, 1.4.25
>
>
> QueryImpl currently computes the indexName like
> {code}
> for (IndexPlan p : ipList) {
> // TODO limit is after all conditions
> long entryCount = Math.min(maxEntryCount,
> p.getEstimatedEntryCount());
> double c = p.getCostPerExecution() + entryCount *
> p.getCostPerEntry();
> if (c < cost) {
> cost = c;
> if (p.getPlanName() != null) {
> indexName += "[" + p.getPlanName() + "]";
> }
> indexPlan = p;
> }
> }
> {code}
> If there are multiple index plans then indexName contains multiple plan names
> which causes confusion
> {noformat}
>cost for
> lucene-property[/oak:index/keymatchKeywords][/oak:index/newImport] is 786.0
> {noformat}
> Instead of concatenating the indexName should be generated outside
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-4652) indexName logged in QueryImpl is wrong in case of multiple indexes satisfying the query
[
https://issues.apache.org/jira/browse/OAK-4652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-4652:
Labels: candidate_oak_1_2 (was: candidate_oak_1_2 candidate_oak_1_4)
> indexName logged in QueryImpl is wrong in case of multiple indexes satisfying
> the query
> ---
>
> Key: OAK-4652
> URL: https://issues.apache.org/jira/browse/OAK-4652
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Labels: candidate_oak_1_2
> Fix For: 1.5.8, 1.6.0, 1.4.25
>
>
> QueryImpl currently computes the indexName like
> {code}
> for (IndexPlan p : ipList) {
> // TODO limit is after all conditions
> long entryCount = Math.min(maxEntryCount,
> p.getEstimatedEntryCount());
> double c = p.getCostPerExecution() + entryCount *
> p.getCostPerEntry();
> if (c < cost) {
> cost = c;
> if (p.getPlanName() != null) {
> indexName += "[" + p.getPlanName() + "]";
> }
> indexPlan = p;
> }
> }
> {code}
> If there are multiple index plans then indexName contains multiple plan names
> which causes confusion
> {noformat}
>cost for
> lucene-property[/oak:index/keymatchKeywords][/oak:index/newImport] is 786.0
> {noformat}
> Instead of concatenating the indexName should be generated outside
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (OAK-8729) Lucene Directory concurrency issue
[
https://issues.apache.org/jira/browse/OAK-8729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16967586#comment-16967586
]
Nitin Gupta edited comment on OAK-8729 at 11/6/19 9:28 AM:
---
[~thomasm] - lgtm .
Seems like you tagged a different nitin. My ldap/id here is ngupta .
was (Author: nitigup):
[~thomasm] - lgtm
> Lucene Directory concurrency issue
> --
>
> Key: OAK-8729
> URL: https://issues.apache.org/jira/browse/OAK-8729
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Affects Versions: 1.12.0, 1.14.0, 1.16.0, 1.18.0
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.20.0
>
> Attachments: OAK-8729.patch
>
>
> There is a concurrency issue in the DefaultDirectoryFactory. It is
> reproducible sometimes using CopyOnWriteDirectoryTest.copyOnWrite(), if run
> in a loop (1000 times). The problem is that the MemoryNodeBuilder is used
> concurrently:
> * thread 1 is closing the directory (after writing to it)
> * thread 2 is trying to create a new file
> {noformat}
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.exists(MemoryNodeBuilder.java:284)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.setProperty(MemoryNodeBuilder.java:525)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.OakDirectory.close(OakDirectory.java:264)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.BufferedOakDirectory.close(BufferedOakDirectory.java:217)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnReadDirectory$2.run(CopyOnReadDirectory.java:305)
> 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)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.exists(MemoryNodeBuilder.java:284)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.setChildNode(MemoryNodeBuilder.java:362)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.setChildNode(MemoryNodeBuilder.java:356)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.child(MemoryNodeBuilder.java:342)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.OakDirectory.createOutput(OakDirectory.java:214)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.BufferedOakDirectory.createOutput(BufferedOakDirectory.java:178)
> at org.apache.lucene.store.Directory.copy(Directory.java:184)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnWriteDirectory$3.call(CopyOnWriteDirectory.java:322)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnWriteDirectory$3.call(CopyOnWriteDirectory.java:1)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnWriteDirectory$2$1.call(CopyOnWriteDirectory.java:105)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnWriteDirectory$2$1.call(CopyOnWriteDirectory.java:1)
> 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:745)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8729) Lucene Directory concurrency issue
[
https://issues.apache.org/jira/browse/OAK-8729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16968212#comment-16968212
]
Mohit Kataria commented on OAK-8729:
[~thomasm], +1 for patch
> Lucene Directory concurrency issue
> --
>
> Key: OAK-8729
> URL: https://issues.apache.org/jira/browse/OAK-8729
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Affects Versions: 1.12.0, 1.14.0, 1.16.0, 1.18.0
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.20.0
>
> Attachments: OAK-8729.patch
>
>
> There is a concurrency issue in the DefaultDirectoryFactory. It is
> reproducible sometimes using CopyOnWriteDirectoryTest.copyOnWrite(), if run
> in a loop (1000 times). The problem is that the MemoryNodeBuilder is used
> concurrently:
> * thread 1 is closing the directory (after writing to it)
> * thread 2 is trying to create a new file
> {noformat}
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.exists(MemoryNodeBuilder.java:284)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.setProperty(MemoryNodeBuilder.java:525)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.OakDirectory.close(OakDirectory.java:264)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.BufferedOakDirectory.close(BufferedOakDirectory.java:217)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnReadDirectory$2.run(CopyOnReadDirectory.java:305)
> 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)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.exists(MemoryNodeBuilder.java:284)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.setChildNode(MemoryNodeBuilder.java:362)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.setChildNode(MemoryNodeBuilder.java:356)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.child(MemoryNodeBuilder.java:342)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.OakDirectory.createOutput(OakDirectory.java:214)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.BufferedOakDirectory.createOutput(BufferedOakDirectory.java:178)
> at org.apache.lucene.store.Directory.copy(Directory.java:184)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnWriteDirectory$3.call(CopyOnWriteDirectory.java:322)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnWriteDirectory$3.call(CopyOnWriteDirectory.java:1)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnWriteDirectory$2$1.call(CopyOnWriteDirectory.java:105)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnWriteDirectory$2$1.call(CopyOnWriteDirectory.java:1)
> 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:745)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8673) Determine and possibly adjust size of eagerCacheSize
[
https://issues.apache.org/jira/browse/OAK-8673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16968163#comment-16968163
]
Thomas Mueller commented on OAK-8673:
-
[~angela] Thanks! One more question: In the issue description, you write "we
almost never benefit from the lazy permission evaluation (compared to reading
all permission entries right away)". I assume you mean lazy permission
evaluation isn't _faster_ than reading all permission entries right away,
right? If so, is it a lot _slower_? There are two points I want to make:
* We should understand why it does / does not impact performance - this is
important to be able to have a somewhat accurate mental model
* Maybe it has an impact on memory usage? So we could say let's keep lazy
evaluation to save memory? How much?
If the answer is: lazy evaluation doesn't save any memory and doesn't have any
memory impact, then we can probably simplify the code (to never or always do
lazy evaluation, whatever is simpler).
> Determine and possibly adjust size of eagerCacheSize
>
>
> Key: OAK-8673
> URL: https://issues.apache.org/jira/browse/OAK-8673
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: core, security
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Major
>
> The initial results of the {{EagerCacheSizeTest}} seem to indicate that we
> almost never benefit from the lazy permission evaluation (compared to reading
> all permission entries right away). From my understanding of the results the
> only exception are those cases where only very few items are being accessed
> (e.g. reading 100 items).
> However, I am not totally sure if this is not a artifact of the random-read.
> I therefore started extending the benchmark with an option to re-read a
> randomly picked item more that once, which according to some analysis done
> quite some time ago is a common scenario specially when using Oak in
> combination with Apache Sling.
> Benchmarks with 10-times re-reading the same random item:
> As I would have expected it seems that the negative impact of lazy-loading is
> somewhat reduced, as the re-reading will hit the cache populated while
> reading.
> Result are attached to OAK-8662 (possibly more to come).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8673) Determine and possibly adjust size of eagerCacheSize
[
https://issues.apache.org/jira/browse/OAK-8673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16968149#comment-16968149
]
Angela Schreiber commented on OAK-8673:
---
[~thomasm], well i am pretty confident that the eagerly-loaded cache is not
populated in the case of 0. but i am running the benchmarks anyway just for the
sake of having the numbers. regarding your question: it's the other way round
:-). the total number of permission entries (either estimated or exactly
know) in combination with the configured size will determine if the entries are
all loaded upon init or if lazy-loading is used. so, the bigger the number of
permission entries, the bigger the configured size needs to be in order to
pre-load the entries. if the size is 0, it will always lazy load. if the size
is infinitely big it will do no lazy loading.
> Determine and possibly adjust size of eagerCacheSize
>
>
> Key: OAK-8673
> URL: https://issues.apache.org/jira/browse/OAK-8673
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: core, security
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Major
>
> The initial results of the {{EagerCacheSizeTest}} seem to indicate that we
> almost never benefit from the lazy permission evaluation (compared to reading
> all permission entries right away). From my understanding of the results the
> only exception are those cases where only very few items are being accessed
> (e.g. reading 100 items).
> However, I am not totally sure if this is not a artifact of the random-read.
> I therefore started extending the benchmark with an option to re-read a
> randomly picked item more that once, which according to some analysis done
> quite some time ago is a common scenario specially when using Oak in
> combination with Apache Sling.
> Benchmarks with 10-times re-reading the same random item:
> As I would have expected it seems that the negative impact of lazy-loading is
> somewhat reduced, as the re-reading will hit the cache populated while
> reading.
> Result are attached to OAK-8662 (possibly more to come).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-8673) Determine and possibly adjust size of eagerCacheSize
[
https://issues.apache.org/jira/browse/OAK-8673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber updated OAK-8673:
--
Description:
The initial results of the {{EagerCacheSizeTest}} seem to indicate that we
almost never benefit from the lazy permission evaluation (compared to reading
all permission entries right away). From my understanding of the results the
only exception are those cases where only very few items are being accessed
(e.g. reading 100 items).
However, I am not totally sure if this is not a artifact of the random-read. I
therefore started extending the benchmark with an option to re-read a randomly
picked item more that once, which according to some analysis done quite some
time ago is a common scenario specially when using Oak in combination with
Apache Sling.
Benchmarks with 10-times re-reading the same random item:
As I would have expected it seems that the negative impact of lazy-loading is
somewhat reduced, as the re-reading will hit the cache populated while reading.
Result are attached to OAK-8662 (possibly more to come).
was:
The initial results of the {{EagerCacheSizeTest}} seem to indicate that we
almost never benefit from the lazy permission evaluation (compared to reading
all permission entries right away). From my understanding of the results the
only exception are those cases where only very few items are being accessed
(e.g. reading 100 items).
However, I am not totally sure if this is not a artifact of the random-read. I
therefore started extending the benchmark with an option to re-read a randomly
picked item more that once, which according to some analysis done quite some
time ago is a common scenario specially when using Oak in combination with
Apache Sling.
Result are attached to OAK-8662 (possibly more to come).
> Determine and possibly adjust size of eagerCacheSize
>
>
> Key: OAK-8673
> URL: https://issues.apache.org/jira/browse/OAK-8673
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: core, security
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Major
>
> The initial results of the {{EagerCacheSizeTest}} seem to indicate that we
> almost never benefit from the lazy permission evaluation (compared to reading
> all permission entries right away). From my understanding of the results the
> only exception are those cases where only very few items are being accessed
> (e.g. reading 100 items).
> However, I am not totally sure if this is not a artifact of the random-read.
> I therefore started extending the benchmark with an option to re-read a
> randomly picked item more that once, which according to some analysis done
> quite some time ago is a common scenario specially when using Oak in
> combination with Apache Sling.
> Benchmarks with 10-times re-reading the same random item:
> As I would have expected it seems that the negative impact of lazy-loading is
> somewhat reduced, as the re-reading will hit the cache populated while
> reading.
> Result are attached to OAK-8662 (possibly more to come).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
