[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=16964365#comment-16964365
]
Manfred Baedke commented on OAK-8710:
-
I'd propose to ignore all principals that are not JackrabbitPrincipals and all
credentials that are not javax.jcr.Credentials.
> 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
>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-8726) Build Jackrabbit Oak #2471 failed
[ https://issues.apache.org/jira/browse/OAK-8726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16964356#comment-16964356 ] Hudson commented on OAK-8726: - Previously failing build now is OK. Passed run: [Jackrabbit Oak #2475|https://builds.apache.org/job/Jackrabbit%20Oak/2475/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2475/console] > Build Jackrabbit Oak #2471 failed > - > > Key: OAK-8726 > URL: https://issues.apache.org/jira/browse/OAK-8726 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2471 has failed. > First failed run: [Jackrabbit Oak > #2471|https://builds.apache.org/job/Jackrabbit%20Oak/2471/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2471/console] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OAK-8733) Simplify ExternalGroupPrincipalProvider
[
https://issues.apache.org/jira/browse/OAK-8733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber resolved OAK-8733.
---
Resolution: Fixed
Committed revision 1869225.
> Simplify ExternalGroupPrincipalProvider
> ---
>
> Key: OAK-8733
> URL: https://issues.apache.org/jira/browse/OAK-8733
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Minor
> Fix For: 1.20.0
>
>
> the following 2 methods can be simplified in
> {{ExternalGroupPrincipalProvider}}
> - _getGroupPrincipals_:
> {{userTree.hasProperty(REP_EXTERNAL_PRINCIPAL_NAMES)}} can be omitted from
> the if clause, as the return value of {{getProperty}} is anyway checked for
> _null_.
> - _ExternalGroupPrincipalProvider.GroupPrincipalIterator.getNext()_: the
> {{PropertyValue}} as obtained from the {{ResultRow}} will never contain
> _null_ elements and the extra check for _null_ can be omitted. if extra
> defensiveness is desired the values could be filtered for null elements.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (OAK-8733) Simplify ExternalGroupPrincipalProvider
Angela Schreiber created OAK-8733:
-
Summary: Simplify ExternalGroupPrincipalProvider
Key: OAK-8733
URL: https://issues.apache.org/jira/browse/OAK-8733
Project: Jackrabbit Oak
Issue Type: Improvement
Components: auth-external
Reporter: Angela Schreiber
Assignee: Angela Schreiber
Fix For: 1.20.0
the following 2 methods can be simplified in {{ExternalGroupPrincipalProvider}}
- _getGroupPrincipals_: {{userTree.hasProperty(REP_EXTERNAL_PRINCIPAL_NAMES)}}
can be omitted from the if clause, as the return value of {{getProperty}} is
anyway checked for _null_.
- _ExternalGroupPrincipalProvider.GroupPrincipalIterator.getNext()_: the
{{PropertyValue}} as obtained from the {{ResultRow}} will never contain _null_
elements and the extra check for _null_ can be omitted. if extra defensiveness
is desired the values could be filtered for null elements.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8726) Build Jackrabbit Oak #2471 failed
[ https://issues.apache.org/jira/browse/OAK-8726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16964221#comment-16964221 ] Hudson commented on OAK-8726: - Previously failing build now is OK. Passed run: [Jackrabbit Oak #2474|https://builds.apache.org/job/Jackrabbit%20Oak/2474/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2474/console] > Build Jackrabbit Oak #2471 failed > - > > Key: OAK-8726 > URL: https://issues.apache.org/jira/browse/OAK-8726 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2471 has failed. > First failed run: [Jackrabbit Oak > #2471|https://builds.apache.org/job/Jackrabbit%20Oak/2471/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2471/console] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OAK-8662) Benchmark results for eagercachesize
[ https://issues.apache.org/jira/browse/OAK-8662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber resolved OAK-8662. --- Resolution: Fixed > Benchmark results for eagercachesize > - > > Key: OAK-8662 > URL: https://issues.apache.org/jira/browse/OAK-8662 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: benchmarks >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Major > Fix For: 1.20.0 > > Attachments: eagercachesize-read100-repeat10.txt, > eagercachesize-read100.txt, eagercachesize-read1000-repeat10.txt, > eagercachesize-read1000.txt, eagercachesize-read1-repeat10.txt, > eagercachesize-read10.txt, eagercachesize.txt > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OAK-8732) Does oak have a performance test report? How about performance in the case of billions of nodes
zhouxu created OAK-8732: --- Summary: Does oak have a performance test report? How about performance in the case of billions of nodes Key: OAK-8732 URL: https://issues.apache.org/jira/browse/OAK-8732 Project: Jackrabbit Oak Issue Type: Test Components: 1.14 Reporter: zhouxu -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OAK-8731) Can oak support big data? Billions of nodes
zhouxu created OAK-8731: --- Summary: Can oak support big data? Billions of nodes Key: OAK-8731 URL: https://issues.apache.org/jira/browse/OAK-8731 Project: Jackrabbit Oak Issue Type: Wish Components: 1.14 Reporter: zhouxu -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (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=16964106#comment-16964106
]
Angela Schreiber edited comment on OAK-8673 at 10/31/19 4:18 PM:
-
[~thomasm], [~fabrizio.fort...@gmail.com], as just discussed in the office, I
would very much appreciate if you had a bit of time to look at the results and
the {{EagerCacheSizeTest}} and my intermediate summary above. I verified that
there is really a new test-session created for each test-run in order to make
sure there is a {{PathEntryMapCache}} computed every time (if the cache size is
not exceeded). as soon as the cache-size is exceeded the evaluation will fall
back to {{DefaultPermissionCache}}, which will load permission entries as they
are needed. the read-only nature of the benchmark asserts that we don't hit the
cache-reset.
if you feel you first need to get some understanding of the underlying feature,
you can start from {{PermissionProviderImpl}} to get the bigger picture or
directly start at {{PermissionCacheBuilder}}.
was (Author: anchela):
[~thomasm], [~fabrizio.fort...@gmail.com], as just discussed in the office, I
would very much appreciate if you had a bit of time to look at the results and
the {{EagerCacheSizeTest}}. I verified that there is really a new test-session
created for each test-run in order to make sure there is a
{{PathEntryMapCache}} computed every time (if the cache size is not exceeded).
as soon as the cache-size is exceeded the evaluation will fall back to
{{DefaultPermissionCache}}, which will load permission entries as they are
needed. the read-only nature of the benchmark asserts that we don't hit the
cache-reset.
if you feel you first need to get some understanding of the underlying feature,
you can start from {{PermissionProviderImpl}} to get the bigger picture or
directly start at {{PermissionCacheBuilder}}.
> 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.
> Result are attached to OAK-8662 (possibly more to come).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8726) Build Jackrabbit Oak #2471 failed
[ https://issues.apache.org/jira/browse/OAK-8726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16964147#comment-16964147 ] Hudson commented on OAK-8726: - Previously failing build now is OK. Passed run: [Jackrabbit Oak #2473|https://builds.apache.org/job/Jackrabbit%20Oak/2473/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2473/console] > Build Jackrabbit Oak #2471 failed > - > > Key: OAK-8726 > URL: https://issues.apache.org/jira/browse/OAK-8726 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2471 has failed. > First failed run: [Jackrabbit Oak > #2471|https://builds.apache.org/job/Jackrabbit%20Oak/2471/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2471/console] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (OAK-7653) upgrade to Jacoco version compatible with Java 11
[ https://issues.apache.org/jira/browse/OAK-7653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16880532#comment-16880532 ] Julian Reschke edited comment on OAK-7653 at 10/31/19 3:25 PM: --- trunk: (1.9.9) [r1839570|http://svn.apache.org/r1839570] 1.8: (1.8.8) [r1840135|http://svn.apache.org/r1840135] 1.6: (1.6.18) [r1862760|http://svn.apache.org/r1862760] 1.4: [r1869221|http://svn.apache.org/r1869221] was (Author: reschke): trunk: (1.9.9) [r1839570|http://svn.apache.org/r1839570] 1.8: (1.8.8) [r1840135|http://svn.apache.org/r1840135] 1.6: [r1862760|http://svn.apache.org/r1862760] > upgrade to Jacoco version compatible with Java 11 > - > > Key: OAK-7653 > URL: https://issues.apache.org/jira/browse/OAK-7653 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.10.0, 1.9.9, 1.8.8, 1.4.25, 1.6.18 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-7653) upgrade to Jacoco version compatible with Java 11
[ https://issues.apache.org/jira/browse/OAK-7653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-7653: Fix Version/s: 1.4.25 > upgrade to Jacoco version compatible with Java 11 > - > > Key: OAK-7653 > URL: https://issues.apache.org/jira/browse/OAK-7653 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_4 > Fix For: 1.10.0, 1.9.9, 1.8.8, 1.4.25, 1.6.18 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-7653) upgrade to Jacoco version compatible with Java 11
[ https://issues.apache.org/jira/browse/OAK-7653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-7653: Labels: (was: candidate_oak_1_4) > upgrade to Jacoco version compatible with Java 11 > - > > Key: OAK-7653 > URL: https://issues.apache.org/jira/browse/OAK-7653 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.10.0, 1.9.9, 1.8.8, 1.4.25, 1.6.18 > > -- 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=16964106#comment-16964106
]
Angela Schreiber commented on OAK-8673:
---
[~thomasm], [~fabrizio.fort...@gmail.com], as just discussed in the office, I
would very much appreciate if you had a bit of time to look at the results and
the {{EagerCacheSizeTest}}. I verified that there is really a new test-session
created for each test-run in order to make sure there is a
{{PathEntryMapCache}} computed every time (if the cache size is not exceeded).
as soon as the cache-size is exceeded the evaluation will fall back to
{{DefaultPermissionCache}}, which will load permission entries as they are
needed. the read-only nature of the benchmark asserts that we don't hit the
cache-reset.
if you feel you first need to get some understanding of the underlying feature,
you can start from {{PermissionProviderImpl}} to get the bigger picture or
directly start at {{PermissionCacheBuilder}}.
> 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.
> Result are attached to OAK-8662 (possibly more to come).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (OAK-8730) Add option for repeated read to ReadDeepTreeTest
[
https://issues.apache.org/jira/browse/OAK-8730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber resolved OAK-8730.
---
Fix Version/s: 1.20.0
Resolution: Fixed
Committed revision 1869220.
> Add option for repeated read to ReadDeepTreeTest
>
>
> Key: OAK-8730
> URL: https://issues.apache.org/jira/browse/OAK-8730
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: benchmarks
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Minor
> Fix For: 1.20.0
>
>
> In order to no only read random items but also be able to profile repeated
> reads as they are common with Apache Sling and Adobe AEM, I will add a
> benchmark option to {{ReadDeepTreeTest}} and {{EagerCacheSizeTest}} that
> allows to specify how many times a given randomly selected item will be read.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-8730) Add option for repeated read to ReadDeepTreeTest
[
https://issues.apache.org/jira/browse/OAK-8730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber updated OAK-8730:
--
Description: In order to no only read random items but also be able to
profile repeated reads as they are common with Apache Sling and Adobe AEM, I
will add a benchmark option to {{ReadDeepTreeTest}} and {{EagerCacheSizeTest}}
that allows to specify how many times a given randomly selected item will be
read. (was: In order to no only read random items but also be able to profile
repeated reads as they are common with Apache Sling and Adobe AEM, I will add a
benchmark option to )
> Add option for repeated read to ReadDeepTreeTest
>
>
> Key: OAK-8730
> URL: https://issues.apache.org/jira/browse/OAK-8730
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: benchmarks
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Minor
>
> In order to no only read random items but also be able to profile repeated
> reads as they are common with Apache Sling and Adobe AEM, I will add a
> benchmark option to {{ReadDeepTreeTest}} and {{EagerCacheSizeTest}} that
> allows to specify how many times a given randomly selected item will be read.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-8730) Add option for repeated read to ReadDeepTreeTest
[ https://issues.apache.org/jira/browse/OAK-8730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber updated OAK-8730: -- Description: In order to no only read random items but also be able to profile repeated reads as they are common with Apache Sling and Adobe AEM, I will add a benchmark option to > Add option for repeated read to ReadDeepTreeTest > > > Key: OAK-8730 > URL: https://issues.apache.org/jira/browse/OAK-8730 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: benchmarks >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Minor > > In order to no only read random items but also be able to profile repeated > reads as they are common with Apache Sling and Adobe AEM, I will add a > benchmark option to -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OAK-8730) Add option for repeated read to ReadDeepTreeTest
Angela Schreiber created OAK-8730: - Summary: Add option for repeated read to ReadDeepTreeTest Key: OAK-8730 URL: https://issues.apache.org/jira/browse/OAK-8730 Project: Jackrabbit Oak Issue Type: Technical task Components: benchmarks Reporter: Angela Schreiber Assignee: Angela Schreiber -- 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.
Result are attached to OAK-8662 (possibly more to come).
was:Based on the result of
> 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.
> 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: Based on the result of > 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 > > Based on the result of -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (OAK-7675) oak-pojosr: replace mockito-all by mockito-core
[ https://issues.apache.org/jira/browse/OAK-7675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16604735#comment-16604735 ] Julian Reschke edited comment on OAK-7675 at 10/31/19 2:33 PM: --- trunk: (1.9.7) [r1837296|http://svn.apache.org/r1837296] 1.10: (1.9.7) [r1837296|http://svn.apache.org/r1837296] 1.8: (1.8.8) [r1840151|http://svn.apache.org/r1840151] 1.6: (1.6.18) [r1862752|http://svn.apache.org/r1862752] 1.4: [r1869218|http://svn.apache.org/r1869218] was (Author: reschke): trunk: (1.9.7) [r1837296|http://svn.apache.org/r1837296] 1.8: (1.8.8) [r1840151|http://svn.apache.org/r1840151] 1.6: [r1862752|http://svn.apache.org/r1862752] > oak-pojosr: replace mockito-all by mockito-core > --- > > Key: OAK-7675 > URL: https://issues.apache.org/jira/browse/OAK-7675 > Project: Jackrabbit Oak > Issue Type: Task > Components: pojosr >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Trivial > Fix For: 1.10.0, 1.9.7, 1.8.8, 1.4.25, 1.6.18 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-7675) oak-pojosr: replace mockito-all by mockito-core
[ https://issues.apache.org/jira/browse/OAK-7675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-7675: Fix Version/s: 1.4.25 > oak-pojosr: replace mockito-all by mockito-core > --- > > Key: OAK-7675 > URL: https://issues.apache.org/jira/browse/OAK-7675 > Project: Jackrabbit Oak > Issue Type: Task > Components: pojosr >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Trivial > Labels: candidate_oak_1_4 > Fix For: 1.10.0, 1.9.7, 1.8.8, 1.4.25, 1.6.18 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-7675) oak-pojosr: replace mockito-all by mockito-core
[ https://issues.apache.org/jira/browse/OAK-7675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-7675: Labels: (was: candidate_oak_1_4) > oak-pojosr: replace mockito-all by mockito-core > --- > > Key: OAK-7675 > URL: https://issues.apache.org/jira/browse/OAK-7675 > Project: Jackrabbit Oak > Issue Type: Task > Components: pojosr >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Trivial > Fix For: 1.10.0, 1.9.7, 1.8.8, 1.4.25, 1.6.18 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OAK-8729) Lucene Directory concurrency issue
Thomas Mueller created OAK-8729:
---
Summary: Lucene Directory concurrency issue
Key: OAK-8729
URL: https://issues.apache.org/jira/browse/OAK-8729
Project: Jackrabbit Oak
Issue Type: Improvement
Components: lucene
Reporter: Thomas Mueller
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-8662) Benchmark results for eagercachesize
[ https://issues.apache.org/jira/browse/OAK-8662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber updated OAK-8662: -- Attachment: eagercachesize-read100-repeat10.txt eagercachesize-read1000-repeat10.txt eagercachesize-read1-repeat10.txt > Benchmark results for eagercachesize > - > > Key: OAK-8662 > URL: https://issues.apache.org/jira/browse/OAK-8662 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: benchmarks >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Major > Fix For: 1.20.0 > > Attachments: eagercachesize-read100-repeat10.txt, > eagercachesize-read100.txt, eagercachesize-read1000-repeat10.txt, > eagercachesize-read1000.txt, eagercachesize-read1-repeat10.txt, > eagercachesize-read10.txt, eagercachesize.txt > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OAK-8724) Delegatee: extract result message handling into separate class
[
https://issues.apache.org/jira/browse/OAK-8724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber resolved OAK-8724.
---
Fix Version/s: 1.20.0
Resolution: Fixed
Committed revision 1869212.
> Delegatee: extract result message handling into separate class
> --
>
> Key: OAK-8724
> URL: https://issues.apache.org/jira/browse/OAK-8724
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Minor
> Fix For: 1.20.0
>
>
> in order to improve readability and maintainability of
> {{org.apache.jackrabbit.oak.spi.security.authentication.external.impl.jmx.Delegatee}}
> i would suggest to extract that static result message formatting into a
> separate class.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (OAK-8728) Delegatee.internalListOrphanedIdentities contains redundant check for null
[
https://issues.apache.org/jira/browse/OAK-8728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber resolved OAK-8728.
---
Fix Version/s: 1.20.0
Resolution: Fixed
Committed revision 1869212.
> Delegatee.internalListOrphanedIdentities contains redundant check for null
> --
>
> Key: OAK-8728
> URL: https://issues.apache.org/jira/browse/OAK-8728
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Minor
> Fix For: 1.20.0
>
>
> {{Delegatee.internalListOrphanedIdentities}} contains a redundant check for
> {{SyncedIdentity.getExternalIdRef}} not being null, which is already covered
> by {{isMyIDP(syncedIdentity)}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (OAK-8727) Delegatee.isMyIDP contains redundant test for empty provider name
[
https://issues.apache.org/jira/browse/OAK-8727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber resolved OAK-8727.
---
Fix Version/s: 1.20.0
Resolution: Fixed
Committed revision 1869212.
> Delegatee.isMyIDP contains redundant test for empty provider name
> -
>
> Key: OAK-8727
> URL: https://issues.apache.org/jira/browse/OAK-8727
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Minor
> Fix For: 1.20.0
>
>
> since {{ExternalIdentityRef.getProviderName}} return either null or a
> non-empty IDP name, the extra check for empty provider name in
> {{Delegatee.isMyIDP}} is superfluous.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (OAK-8728) Delegatee.internalListOrphanedIdentities contains redundant check for null
Angela Schreiber created OAK-8728:
-
Summary: Delegatee.internalListOrphanedIdentities contains
redundant check for null
Key: OAK-8728
URL: https://issues.apache.org/jira/browse/OAK-8728
Project: Jackrabbit Oak
Issue Type: Improvement
Components: auth-external
Reporter: Angela Schreiber
Assignee: Angela Schreiber
{{Delegatee.internalListOrphanedIdentities}} contains a redundant check for
{{SyncedIdentity.getExternalIdRef}} not being null, which is already covered by
{{isMyIDP(syncedIdentity)}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8162) When query with OR is divided into union of queries, options (like index tag) are not passed into subqueries.
[
https://issues.apache.org/jira/browse/OAK-8162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16964022#comment-16964022
]
Julian Reschke commented on OAK-8162:
-
Is this a backport candidate?
> When query with OR is divided into union of queries, options (like index tag)
> are not passed into subqueries.
> --
>
> Key: OAK-8162
> URL: https://issues.apache.org/jira/browse/OAK-8162
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.10.2
>Reporter: Piotr Tajduś
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.14.0
>
>
> When query with OR is divided into union of queries, options (like index tag)
> are not passed into subqueries - in effect alternative query sometimes f.e.
> uses indexes it shouldn't use.
> {noformat}
> org.apache.jackrabbit.oak.query.QueryImpl.buildAlternativeQuery()
> org.apache.jackrabbit.oak.query.QueryImpl.copyOf()
>
> 2019-03-21 16:32:25,600 DEBUG
> [org.apache.jackrabbit.oak.query.QueryEngineImpl] (default task-1) Parsing
> JCR-SQL2 statement: select distinct d.* from [crkid:document] as d where
> ([d].[metadane/inneMetadane/*/wartosc] = 'AX' and
> [d].[metadane/inneMetadane/*/klucz] = 'InnyKod') or
> ([d].[metadane/inneMetadane/*/wartosc] = 'AB' and
> [d].[metadane/inneMetadane/*/klucz] = 'InnyKod') option(index tag
> crkid_dokument_month_2019_3)
> 2019-03-21 16:32:25,607 DEBUG [org.apache.jackrabbit.oak.query.QueryImpl]
> (default task-1) cost using filter Filter(query=select distinct d.* from
> [crkid:document] as d where ([d].[metadane/inneMetadane/*/wartosc] = 'AB')
> and ([d].[metadane/inneMetadane/*/klucz] = 'InnyKod'), path=*,
> property=[metadane/inneMetadane/*/klucz=[InnyKod],
> metadane/inneMetadane/*/wartosc=[AB]])
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (OAK-8727) Delegatee.isMyIDP contains redundant test for empty provider name
Angela Schreiber created OAK-8727:
-
Summary: Delegatee.isMyIDP contains redundant test for empty
provider name
Key: OAK-8727
URL: https://issues.apache.org/jira/browse/OAK-8727
Project: Jackrabbit Oak
Issue Type: Improvement
Components: auth-external
Reporter: Angela Schreiber
Assignee: Angela Schreiber
since {{ExternalIdentityRef.getProviderName}} return either null or a non-empty
IDP name, the extra check for empty provider name in {{Delegatee.isMyIDP}} is
superfluous.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-6973) Define public/internal packages
[ https://issues.apache.org/jira/browse/OAK-6973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16964019#comment-16964019 ] Julian Reschke commented on OAK-6973: - The annotation has been introduced with OAK-8707 - we still need to figure out where (else) to use it. > Define public/internal packages > --- > > Key: OAK-6973 > URL: https://issues.apache.org/jira/browse/OAK-6973 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Marcel Reutegger >Priority: Major > Fix For: 1.20.0 > > > As part of the Oak modularization packages previously exported without a > version will at some point have to adhere to proper semantic versioning. See > also OAK-3919 and its sub-tasks. > Since some of those packages are not meant to be used outside of Oak, there > should be a mechanism to define which exported packages are public and which > are considered internal. While semantic versioning rules apply to both > categories, we may want to provide different guarantees/guidance to consumers > of those packages. E.g. increasing the major version of a package used only > by Oak has less impact compared to a major version increase of a 'public' > package used by many applications. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OAK-8162) When query with OR is divided into union of queries, options (like index tag) are not passed into subqueries.
[
https://issues.apache.org/jira/browse/OAK-8162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller resolved OAK-8162.
-
Resolution: Fixed
Yes, this is fixed. I also change the fix version to 1.14.
> When query with OR is divided into union of queries, options (like index tag)
> are not passed into subqueries.
> --
>
> Key: OAK-8162
> URL: https://issues.apache.org/jira/browse/OAK-8162
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.10.2
>Reporter: Piotr Tajduś
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.14.0
>
>
> When query with OR is divided into union of queries, options (like index tag)
> are not passed into subqueries - in effect alternative query sometimes f.e.
> uses indexes it shouldn't use.
> {noformat}
> org.apache.jackrabbit.oak.query.QueryImpl.buildAlternativeQuery()
> org.apache.jackrabbit.oak.query.QueryImpl.copyOf()
>
> 2019-03-21 16:32:25,600 DEBUG
> [org.apache.jackrabbit.oak.query.QueryEngineImpl] (default task-1) Parsing
> JCR-SQL2 statement: select distinct d.* from [crkid:document] as d where
> ([d].[metadane/inneMetadane/*/wartosc] = 'AX' and
> [d].[metadane/inneMetadane/*/klucz] = 'InnyKod') or
> ([d].[metadane/inneMetadane/*/wartosc] = 'AB' and
> [d].[metadane/inneMetadane/*/klucz] = 'InnyKod') option(index tag
> crkid_dokument_month_2019_3)
> 2019-03-21 16:32:25,607 DEBUG [org.apache.jackrabbit.oak.query.QueryImpl]
> (default task-1) cost using filter Filter(query=select distinct d.* from
> [crkid:document] as d where ([d].[metadane/inneMetadane/*/wartosc] = 'AB')
> and ([d].[metadane/inneMetadane/*/klucz] = 'InnyKod'), path=*,
> property=[metadane/inneMetadane/*/klucz=[InnyKod],
> metadane/inneMetadane/*/wartosc=[AB]])
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-8162) When query with OR is divided into union of queries, options (like index tag) are not passed into subqueries.
[
https://issues.apache.org/jira/browse/OAK-8162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-8162:
Fix Version/s: (was: 1.20.0)
1.14.0
> When query with OR is divided into union of queries, options (like index tag)
> are not passed into subqueries.
> --
>
> Key: OAK-8162
> URL: https://issues.apache.org/jira/browse/OAK-8162
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.10.2
>Reporter: Piotr Tajduś
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.14.0
>
>
> When query with OR is divided into union of queries, options (like index tag)
> are not passed into subqueries - in effect alternative query sometimes f.e.
> uses indexes it shouldn't use.
> {noformat}
> org.apache.jackrabbit.oak.query.QueryImpl.buildAlternativeQuery()
> org.apache.jackrabbit.oak.query.QueryImpl.copyOf()
>
> 2019-03-21 16:32:25,600 DEBUG
> [org.apache.jackrabbit.oak.query.QueryEngineImpl] (default task-1) Parsing
> JCR-SQL2 statement: select distinct d.* from [crkid:document] as d where
> ([d].[metadane/inneMetadane/*/wartosc] = 'AX' and
> [d].[metadane/inneMetadane/*/klucz] = 'InnyKod') or
> ([d].[metadane/inneMetadane/*/wartosc] = 'AB' and
> [d].[metadane/inneMetadane/*/klucz] = 'InnyKod') option(index tag
> crkid_dokument_month_2019_3)
> 2019-03-21 16:32:25,607 DEBUG [org.apache.jackrabbit.oak.query.QueryImpl]
> (default task-1) cost using filter Filter(query=select distinct d.* from
> [crkid:document] as d where ([d].[metadane/inneMetadane/*/wartosc] = 'AB')
> and ([d].[metadane/inneMetadane/*/klucz] = 'InnyKod'), path=*,
> property=[metadane/inneMetadane/*/klucz=[InnyKod],
> metadane/inneMetadane/*/wartosc=[AB]])
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8162) When query with OR is divided into union of queries, options (like index tag) are not passed into subqueries.
[
https://issues.apache.org/jira/browse/OAK-8162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16964003#comment-16964003
]
Julian Reschke commented on OAK-8162:
-
Should this issue be marked "resolved" then?
> When query with OR is divided into union of queries, options (like index tag)
> are not passed into subqueries.
> --
>
> Key: OAK-8162
> URL: https://issues.apache.org/jira/browse/OAK-8162
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.10.2
>Reporter: Piotr Tajduś
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.20.0
>
>
> When query with OR is divided into union of queries, options (like index tag)
> are not passed into subqueries - in effect alternative query sometimes f.e.
> uses indexes it shouldn't use.
> {noformat}
> org.apache.jackrabbit.oak.query.QueryImpl.buildAlternativeQuery()
> org.apache.jackrabbit.oak.query.QueryImpl.copyOf()
>
> 2019-03-21 16:32:25,600 DEBUG
> [org.apache.jackrabbit.oak.query.QueryEngineImpl] (default task-1) Parsing
> JCR-SQL2 statement: select distinct d.* from [crkid:document] as d where
> ([d].[metadane/inneMetadane/*/wartosc] = 'AX' and
> [d].[metadane/inneMetadane/*/klucz] = 'InnyKod') or
> ([d].[metadane/inneMetadane/*/wartosc] = 'AB' and
> [d].[metadane/inneMetadane/*/klucz] = 'InnyKod') option(index tag
> crkid_dokument_month_2019_3)
> 2019-03-21 16:32:25,607 DEBUG [org.apache.jackrabbit.oak.query.QueryImpl]
> (default task-1) cost using filter Filter(query=select distinct d.* from
> [crkid:document] as d where ([d].[metadane/inneMetadane/*/wartosc] = 'AB')
> and ([d].[metadane/inneMetadane/*/klucz] = 'InnyKod'), path=*,
> property=[metadane/inneMetadane/*/klucz=[InnyKod],
> metadane/inneMetadane/*/wartosc=[AB]])
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8605) Read the journal lazily in the SplitPersistence
[ https://issues.apache.org/jira/browse/OAK-8605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16964002#comment-16964002 ] Julian Reschke commented on OAK-8605: - Should this issue be marked "resolved" then? > Read the journal lazily in the SplitPersistence > --- > > Key: OAK-8605 > URL: https://issues.apache.org/jira/browse/OAK-8605 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-azure >Reporter: Tomek Rękawek >Priority: Major > Fix For: 1.20.0 > > > The SplitPersistence reads the whole read-only journal at once, during the > initialisation. We may read it in a lazy way, to avoid the fetching the whole > append blob from the Azure, which may be slow (see OAK-8604). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8654) Introduce auto-retry in the SegmentStoreMigrator
[ https://issues.apache.org/jira/browse/OAK-8654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16964001#comment-16964001 ] Julian Reschke commented on OAK-8654: - Should this issue be marked "resolved" then? > Introduce auto-retry in the SegmentStoreMigrator > > > Key: OAK-8654 > URL: https://issues.apache.org/jira/browse/OAK-8654 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-azure >Reporter: Tomek Rękawek >Priority: Major > Fix For: 1.20.0 > > > When migrating a large repository, the timeout exception may happen for > various reasons. We should handle them automatically and auto-retry the > failed operation a few times before giving up. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (OAK-5215) remove use of deprecated guava methods
[ https://issues.apache.org/jira/browse/OAK-5215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16963927#comment-16963927 ] Julian Reschke edited comment on OAK-5215 at 10/31/19 12:59 PM: trunk: (1.5.15) [r1772672|http://svn.apache.org/r1772672] 1.4: [r1869211|http://svn.apache.org/r1869211] was (Author: reschke): trunk: (1.5.15) [r1772672|http://svn.apache.org/r1772672] > remove use of deprecated guava methods > -- > > Key: OAK-5215 > URL: https://issues.apache.org/jira/browse/OAK-5215 > Project: Jackrabbit Oak > Issue Type: Bug >Affects Versions: 1.4.10, 1.5.14 >Reporter: Torgeir Veimo >Assignee: Alex Deparvu >Priority: Minor > Fix For: 1.5.15, 1.6.0, 1.4.25 > > Attachments: OAK-5115.patch, guava.patch > > > When running in a non-osgi environment it's sometimes necessary to use a more > recent version of the guava dependency due to requirements of other > components. By changing the use of methods that are deprecated in later > version of guava, eg. v 19.0, it is possible to use any guava version between > 15.0 (current) and 19.0. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-5215) remove use of deprecated guava methods
[ https://issues.apache.org/jira/browse/OAK-5215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-5215: Fix Version/s: 1.4.25 > remove use of deprecated guava methods > -- > > Key: OAK-5215 > URL: https://issues.apache.org/jira/browse/OAK-5215 > Project: Jackrabbit Oak > Issue Type: Bug >Affects Versions: 1.4.10, 1.5.14 >Reporter: Torgeir Veimo >Assignee: Alex Deparvu >Priority: Minor > Labels: candidate_oak_1_4 > Fix For: 1.5.15, 1.6.0, 1.4.25 > > Attachments: OAK-5115.patch, guava.patch > > > When running in a non-osgi environment it's sometimes necessary to use a more > recent version of the guava dependency due to requirements of other > components. By changing the use of methods that are deprecated in later > version of guava, eg. v 19.0, it is possible to use any guava version between > 15.0 (current) and 19.0. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-5215) remove use of deprecated guava methods
[ https://issues.apache.org/jira/browse/OAK-5215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-5215: Labels: (was: candidate_oak_1_4) > remove use of deprecated guava methods > -- > > Key: OAK-5215 > URL: https://issues.apache.org/jira/browse/OAK-5215 > Project: Jackrabbit Oak > Issue Type: Bug >Affects Versions: 1.4.10, 1.5.14 >Reporter: Torgeir Veimo >Assignee: Alex Deparvu >Priority: Minor > Fix For: 1.5.15, 1.6.0, 1.4.25 > > Attachments: OAK-5115.patch, guava.patch > > > When running in a non-osgi environment it's sometimes necessary to use a more > recent version of the guava dependency due to requirements of other > components. By changing the use of methods that are deprecated in later > version of guava, eg. v 19.0, it is possible to use any guava version between > 15.0 (current) and 19.0. -- 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=16963967#comment-16963967
]
Manfred Baedke commented on OAK-8710:
-
[~angela],
bq. the test case you provided seems odd to me as it doesn't include the login
step
Yes, because it doesn't test that. Like e.g. testLogoutSuccessClearsSubject(),
it's just about one single aspect of the logout behavior, namely that logout
ignores unknown principals.
Quote from
https://docs.oracle.com/javase/8/docs/technotes/guides/security/jaas/JAASLMDevGuide.html#logout:
"This method removes Principals, and removes/destroys credentials associated
with the Subject during the commit operation. This method should not touch
those Principals or credentials previously existing in the Subject".
I'll send you a link to the describing the scenario where the issue happened.
> 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
>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-8726) Build Jackrabbit Oak #2471 failed
[ https://issues.apache.org/jira/browse/OAK-8726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16963953#comment-16963953 ] Hudson commented on OAK-8726: - Previously failing build now is OK. Passed run: [Jackrabbit Oak #2472|https://builds.apache.org/job/Jackrabbit%20Oak/2472/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2472/console] > Build Jackrabbit Oak #2471 failed > - > > Key: OAK-8726 > URL: https://issues.apache.org/jira/browse/OAK-8726 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2471 has failed. > First failed run: [Jackrabbit Oak > #2471|https://builds.apache.org/job/Jackrabbit%20Oak/2471/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2471/console] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-5215) remove use of deprecated guava methods
[ https://issues.apache.org/jira/browse/OAK-5215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16963927#comment-16963927 ] Julian Reschke commented on OAK-5215: - trunk: (1.5.15) [r1772672|http://svn.apache.org/r1772672] > remove use of deprecated guava methods > -- > > Key: OAK-5215 > URL: https://issues.apache.org/jira/browse/OAK-5215 > Project: Jackrabbit Oak > Issue Type: Bug >Affects Versions: 1.4.10, 1.5.14 >Reporter: Torgeir Veimo >Assignee: Alex Deparvu >Priority: Minor > Labels: candidate_oak_1_4 > Fix For: 1.5.15, 1.6.0 > > Attachments: OAK-5115.patch, guava.patch > > > When running in a non-osgi environment it's sometimes necessary to use a more > recent version of the guava dependency due to requirements of other > components. By changing the use of methods that are deprecated in later > version of guava, eg. v 19.0, it is possible to use any guava version between > 15.0 (current) and 19.0. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8722) dead locking related code in NodeDelegate.updateMixins
[
https://issues.apache.org/jira/browse/OAK-8722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-8722:
Fix Version/s: 1.20.0
> dead locking related code in NodeDelegate.updateMixins
> --
>
> Key: OAK-8722
> URL: https://issues.apache.org/jira/browse/OAK-8722
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 1.20.0
>
> Attachments: OAK-8722.diff
>
>
> {noformat}
> // 3. deal with locked nodes
> boolean wasLockable = isNodeType(MIX_LOCKABLE);
> boolean isLockable = isNodeType(MIX_LOCKABLE);
> if (wasLockable && !isLockable && holdsLock(false)) {
> // TODO: This should probably be done in a commit hook
> unlock();
> sessionDelegate.refresh(true);
> }
> {noformat}
> AFAICT, this code block will never be executed. Clean up, [~angela]?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8722) dead locking related code in NodeDelegate.updateMixins
[
https://issues.apache.org/jira/browse/OAK-8722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16963919#comment-16963919
]
Julian Reschke commented on OAK-8722:
-
Proposed patch: [^OAK-8722.diff]
> dead locking related code in NodeDelegate.updateMixins
> --
>
> Key: OAK-8722
> URL: https://issues.apache.org/jira/browse/OAK-8722
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Attachments: OAK-8722.diff
>
>
> {noformat}
> // 3. deal with locked nodes
> boolean wasLockable = isNodeType(MIX_LOCKABLE);
> boolean isLockable = isNodeType(MIX_LOCKABLE);
> if (wasLockable && !isLockable && holdsLock(false)) {
> // TODO: This should probably be done in a commit hook
> unlock();
> sessionDelegate.refresh(true);
> }
> {noformat}
> AFAICT, this code block will never be executed. Clean up, [~angela]?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-8722) dead locking related code in NodeDelegate.updateMixins
[
https://issues.apache.org/jira/browse/OAK-8722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-8722:
Attachment: OAK-8722.diff
> dead locking related code in NodeDelegate.updateMixins
> --
>
> Key: OAK-8722
> URL: https://issues.apache.org/jira/browse/OAK-8722
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Attachments: OAK-8722.diff
>
>
> {noformat}
> // 3. deal with locked nodes
> boolean wasLockable = isNodeType(MIX_LOCKABLE);
> boolean isLockable = isNodeType(MIX_LOCKABLE);
> if (wasLockable && !isLockable && holdsLock(false)) {
> // TODO: This should probably be done in a commit hook
> unlock();
> sessionDelegate.refresh(true);
> }
> {noformat}
> AFAICT, this code block will never be executed. Clean up, [~angela]?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8725) Improve tests for oak-external-auth
[ https://issues.apache.org/jira/browse/OAK-8725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16963877#comment-16963877 ] Angela Schreiber commented on OAK-8725: --- Committed revision 1869208. > Improve tests for oak-external-auth > --- > > Key: OAK-8725 > URL: https://issues.apache.org/jira/browse/OAK-8725 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: auth-external >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Major > > equivalent to OAK-8320 for all packages in _oak-auth-external_ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OAK-8726) Build Jackrabbit Oak #2471 failed
Hudson created OAK-8726: --- Summary: Build Jackrabbit Oak #2471 failed Key: OAK-8726 URL: https://issues.apache.org/jira/browse/OAK-8726 Project: Jackrabbit Oak Issue Type: Bug Components: continuous integration Reporter: Hudson No description is provided The build Jackrabbit Oak #2471 has failed. First failed run: [Jackrabbit Oak #2471|https://builds.apache.org/job/Jackrabbit%20Oak/2471/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2471/console] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8716) Build Jackrabbit Oak #2461 failed
[ https://issues.apache.org/jira/browse/OAK-8716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16963768#comment-16963768 ] Hudson commented on OAK-8716: - Previously failing build now is OK. Passed run: [Jackrabbit Oak #2470|https://builds.apache.org/job/Jackrabbit%20Oak/2470/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2470/console] > Build Jackrabbit Oak #2461 failed > - > > Key: OAK-8716 > URL: https://issues.apache.org/jira/browse/OAK-8716 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2461 has failed. > First failed run: [Jackrabbit Oak > #2461|https://builds.apache.org/job/Jackrabbit%20Oak/2461/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2461/console] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (OAK-8310) Potentially misleading conflict exception message
[ https://issues.apache.org/jira/browse/OAK-8310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16864172#comment-16864172 ] Julian Reschke edited comment on OAK-8310 at 10/31/19 8:30 AM: --- trunk: (1.14.0) [r1859020|http://svn.apache.org/r1859020] 1.10: (1.10.3) [r1861350|http://svn.apache.org/r1861350] 1.8: (1.8.14) [r1862118|http://svn.apache.org/r1862118] 1.6: (1.6.18) [r1862875|http://svn.apache.org/r1862875] 1.4: [r1869203|http://svn.apache.org/r1869203] was (Author: reschke): trunk: (1.14.0) [r1859020|http://svn.apache.org/r1859020] 1.10: (1.10.3) [r1861350|http://svn.apache.org/r1861350] 1.8: (1.8.14) [r1862118|http://svn.apache.org/r1862118] 1.6: [r1862875|http://svn.apache.org/r1862875] > Potentially misleading conflict exception message > - > > Key: OAK-8310 > URL: https://issues.apache.org/jira/browse/OAK-8310 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk >Affects Versions: 1.8.0, 1.10.0, 1.12.0 >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.4.25, 1.10.3, 1.14.0, 1.6.18, 1.8.14 > > > A conflicting merge on a DocumentNodeStore may have a misleading exception > message, when a node is added that already exists and the existing node has > changes that were done after it was added. > The conflict message will then say there's an existing node that was added at > the revision it was last modified instead of when it was added. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (OAK-5272) Expose BlobStore API to provide information whether blob id is content hashed
[ https://issues.apache.org/jira/browse/OAK-5272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller reassigned OAK-5272: --- Assignee: (was: Thomas Mueller) > Expose BlobStore API to provide information whether blob id is content hashed > - > > Key: OAK-5272 > URL: https://issues.apache.org/jira/browse/OAK-5272 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: blob >Reporter: Amit Jain >Priority: Major > Fix For: 1.20.0 > > > As per discussion in OAK-5253 it's better to have some information from the > BlobStore(s) whether the blob id can be solely relied upon for comparison. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8310) Potentially misleading conflict exception message
[ https://issues.apache.org/jira/browse/OAK-8310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8310: Labels: (was: candidate_oak_1_4) > Potentially misleading conflict exception message > - > > Key: OAK-8310 > URL: https://issues.apache.org/jira/browse/OAK-8310 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk >Affects Versions: 1.8.0, 1.10.0, 1.12.0 >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.4.25, 1.10.3, 1.14.0, 1.6.18, 1.8.14 > > > A conflicting merge on a DocumentNodeStore may have a misleading exception > message, when a node is added that already exists and the existing node has > changes that were done after it was added. > The conflict message will then say there's an existing node that was added at > the revision it was last modified instead of when it was added. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8310) Potentially misleading conflict exception message
[ https://issues.apache.org/jira/browse/OAK-8310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8310: Fix Version/s: 1.4.25 > Potentially misleading conflict exception message > - > > Key: OAK-8310 > URL: https://issues.apache.org/jira/browse/OAK-8310 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk >Affects Versions: 1.8.0, 1.10.0, 1.12.0 >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Labels: candidate_oak_1_4 > Fix For: 1.4.25, 1.10.3, 1.14.0, 1.6.18, 1.8.14 > > > A conflicting merge on a DocumentNodeStore may have a misleading exception > message, when a node is added that already exists and the existing node has > changes that were done after it was added. > The conflict message will then say there's an existing node that was added at > the revision it was last modified instead of when it was added. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OAK-8725) Improve tests for oak-external-auth
Angela Schreiber created OAK-8725: - Summary: Improve tests for oak-external-auth Key: OAK-8725 URL: https://issues.apache.org/jira/browse/OAK-8725 Project: Jackrabbit Oak Issue Type: Improvement Components: auth-external Reporter: Angela Schreiber Assignee: Angela Schreiber equivalent to OAK-8320 for all packages in _oak-auth-external_ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OAK-8721) Automatically pick the latest active index version
[ https://issues.apache.org/jira/browse/OAK-8721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller resolved OAK-8721. - Fix Version/s: 1.20.0 Resolution: Fixed > Automatically pick the latest active index version > -- > > Key: OAK-8721 > URL: https://issues.apache.org/jira/browse/OAK-8721 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing, lucene >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Major > Fix For: 1.20.0 > > > When using the composite node store for blue-green deployments, multiple > versions of a index can exist at the same time, for a short period of time > (while both blue and green are running at the same time). It is possible to > select which index is active using the "useIfExists" settings in the index > configurations. However, this is complicated and hard to explain / understand. > Instead, we can rely on naming patterns of the index node name. E.g. > * lucene > * lucene-2 (newer product version) > * lucene-2-custom-2 (customized version of lucene-2) > * lucene-2-custom-3 (customized again) > * lucene-3-custom-1 (newer product version) > It would be good if index selection is automatic, meaning only indexes are > active that are available in the read-only repository (of the composite node > store). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8721) Automatically pick the latest active index version
[ https://issues.apache.org/jira/browse/OAK-8721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16963729#comment-16963729 ] Thomas Mueller commented on OAK-8721: - http://svn.apache.org/r1869202 (trunk) Compared to the pull request, I added some logic so that filtering of indexes is only done when using the composite node store (when using non-default mounts). That way, installations without the composite node store won't be affected. > Automatically pick the latest active index version > -- > > Key: OAK-8721 > URL: https://issues.apache.org/jira/browse/OAK-8721 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing, lucene >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Major > > When using the composite node store for blue-green deployments, multiple > versions of a index can exist at the same time, for a short period of time > (while both blue and green are running at the same time). It is possible to > select which index is active using the "useIfExists" settings in the index > configurations. However, this is complicated and hard to explain / understand. > Instead, we can rely on naming patterns of the index node name. E.g. > * lucene > * lucene-2 (newer product version) > * lucene-2-custom-2 (customized version of lucene-2) > * lucene-2-custom-3 (customized again) > * lucene-3-custom-1 (newer product version) > It would be good if index selection is automatic, meaning only indexes are > active that are available in the read-only repository (of the composite node > store). -- 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=16963722#comment-16963722
]
Angela Schreiber commented on OAK-8710:
---
[~baedke], i am not familiar with the circumstances you describe. what i wanted
to indicate was the test case you provided seems odd to me as it doesn't
include the login step. however, i would appreciate if you could provide
additional information that would help me understand what kind of login was
associated with the scenario you are describing.
> 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
>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] [Resolved] (OAK-8718) LuceneIndexStatsUpdateCallback is slow and synchronous which leads to slowness
[ https://issues.apache.org/jira/browse/OAK-8718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohit Kataria resolved OAK-8718. Resolution: Fixed > LuceneIndexStatsUpdateCallback is slow and synchronous which leads to slowness > -- > > Key: OAK-8718 > URL: https://issues.apache.org/jira/browse/OAK-8718 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing >Reporter: Mohit Kataria >Assignee: Mohit Kataria >Priority: Major > Fix For: 1.20.0 > > Attachments: OAK-8718.patch > > > LuceneIndexStatsUpdateCallback is slow and synchronous which lead to > slowness. > Resolution: > Make this callback to be executed only in asyncIndexUpdate and also make this > configurable > i.e. call only if previous call + currentTime > configured time. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8718) LuceneIndexStatsUpdateCallback is slow and synchronous which leads to slowness
[ https://issues.apache.org/jira/browse/OAK-8718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohit Kataria updated OAK-8718: --- Attachment: OAK-8718.patch > LuceneIndexStatsUpdateCallback is slow and synchronous which leads to slowness > -- > > Key: OAK-8718 > URL: https://issues.apache.org/jira/browse/OAK-8718 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing >Reporter: Mohit Kataria >Assignee: Mohit Kataria >Priority: Major > Fix For: 1.20.0 > > Attachments: OAK-8718.patch > > > LuceneIndexStatsUpdateCallback is slow and synchronous which lead to > slowness. > Resolution: > Make this callback to be executed only in asyncIndexUpdate and also make this > configurable > i.e. call only if previous call + currentTime > configured time. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8718) LuceneIndexStatsUpdateCallback is slow and synchronous which leads to slowness
[ https://issues.apache.org/jira/browse/OAK-8718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohit Kataria updated OAK-8718: --- Fix Version/s: 1.20.0 > LuceneIndexStatsUpdateCallback is slow and synchronous which leads to slowness > -- > > Key: OAK-8718 > URL: https://issues.apache.org/jira/browse/OAK-8718 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing >Reporter: Mohit Kataria >Assignee: Mohit Kataria >Priority: Major > Fix For: 1.20.0 > > Attachments: OAK-8718.patch > > > LuceneIndexStatsUpdateCallback is slow and synchronous which lead to > slowness. > Resolution: > Make this callback to be executed only in asyncIndexUpdate and also make this > configurable > i.e. call only if previous call + currentTime > configured time. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8718) LuceneIndexStatsUpdateCallback is slow and synchronous which leads to slowness
[ https://issues.apache.org/jira/browse/OAK-8718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16963718#comment-16963718 ] Mohit Kataria commented on OAK-8718: Commit revision: [http://svn.apache.org/viewvc?view=revision=1869201] > LuceneIndexStatsUpdateCallback is slow and synchronous which leads to slowness > -- > > Key: OAK-8718 > URL: https://issues.apache.org/jira/browse/OAK-8718 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing >Reporter: Mohit Kataria >Assignee: Mohit Kataria >Priority: Major > > LuceneIndexStatsUpdateCallback is slow and synchronous which lead to > slowness. > Resolution: > Make this callback to be executed only in asyncIndexUpdate and also make this > configurable > i.e. call only if previous call + currentTime > configured time. -- This message was sent by Atlassian Jira (v8.3.4#803005)
