[jira] [Commented] (OAK-8734) Sorted query with multiple path restrictions and sorting performs very slowly if one of the passed paths is a traversal
[
https://issues.apache.org/jira/browse/OAK-8734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16973989#comment-16973989
]
Nitin Gupta commented on OAK-8734:
--
Fixed with [https://svn.apache.org/viewvc?view=revision=1869780]
> Sorted query with multiple path restrictions and sorting performs very slowly
> if one of the passed paths is a traversal
>
>
> Key: OAK-8734
> URL: https://issues.apache.org/jira/browse/OAK-8734
> Project: Jackrabbit Oak
> Issue Type: Bug
>Reporter: Nitin Gupta
>Assignee: Nitin Gupta
>Priority: Major
>
> A query like [1] with multiple path restrictions and an order can be
> extremely slow .
> * Removing the orderby makes it much faste.
> * Removing one path will make it faster.
> The issue appears to be that, as soon as one path-restricred subquery is not
> handled at the index (ie its a traversal, since the cost of traversal on an
> empty path is 0), it appears that the entire sorting happens in the query
> engine which makes the query very very slow if there are lots of items (and
> defeats optimisations like guessTotal which prevent iteration / inflation of
> the complete result set).
> [1]
> {code:java}
> (
> /jcr:root/content/dam/products//element(*, dam:Asset)
> |
> /jcr:root/content/dam/projects//element(*, dam:Asset))
> order by jcr:content/@jcr:lastModified descendin
> )
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (OAK-8734) Sorted query with multiple path restrictions and sorting performs very slowly if one of the passed paths is a traversal
[
https://issues.apache.org/jira/browse/OAK-8734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nitin Gupta resolved OAK-8734.
--
Resolution: Fixed
> Sorted query with multiple path restrictions and sorting performs very slowly
> if one of the passed paths is a traversal
>
>
> Key: OAK-8734
> URL: https://issues.apache.org/jira/browse/OAK-8734
> Project: Jackrabbit Oak
> Issue Type: Bug
>Reporter: Nitin Gupta
>Assignee: Nitin Gupta
>Priority: Major
>
> A query like [1] with multiple path restrictions and an order can be
> extremely slow .
> * Removing the orderby makes it much faste.
> * Removing one path will make it faster.
> The issue appears to be that, as soon as one path-restricred subquery is not
> handled at the index (ie its a traversal, since the cost of traversal on an
> empty path is 0), it appears that the entire sorting happens in the query
> engine which makes the query very very slow if there are lots of items (and
> defeats optimisations like guessTotal which prevent iteration / inflation of
> the complete result set).
> [1]
> {code:java}
> (
> /jcr:root/content/dam/products//element(*, dam:Asset)
> |
> /jcr:root/content/dam/projects//element(*, dam:Asset))
> order by jcr:content/@jcr:lastModified descendin
> )
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-8734) Sorted query with multiple path restrictions and sorting performs very slowly if one of the passed paths is a traversal
[
https://issues.apache.org/jira/browse/OAK-8734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nitin Gupta updated OAK-8734:
-
Fix Version/s: 1.20.0
> Sorted query with multiple path restrictions and sorting performs very slowly
> if one of the passed paths is a traversal
>
>
> Key: OAK-8734
> URL: https://issues.apache.org/jira/browse/OAK-8734
> Project: Jackrabbit Oak
> Issue Type: Bug
>Reporter: Nitin Gupta
>Assignee: Nitin Gupta
>Priority: Major
> Fix For: 1.20.0
>
>
> A query like [1] with multiple path restrictions and an order can be
> extremely slow .
> * Removing the orderby makes it much faste.
> * Removing one path will make it faster.
> The issue appears to be that, as soon as one path-restricred subquery is not
> handled at the index (ie its a traversal, since the cost of traversal on an
> empty path is 0), it appears that the entire sorting happens in the query
> engine which makes the query very very slow if there are lots of items (and
> defeats optimisations like guessTotal which prevent iteration / inflation of
> the complete result set).
> [1]
> {code:java}
> (
> /jcr:root/content/dam/products//element(*, dam:Asset)
> |
> /jcr:root/content/dam/projects//element(*, dam:Asset))
> order by jcr:content/@jcr:lastModified descendin
> )
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8761) Build Jackrabbit Oak #2493 failed
[ https://issues.apache.org/jira/browse/OAK-8761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16973628#comment-16973628 ] Hudson commented on OAK-8761: - Previously failing build now is OK. Passed run: [Jackrabbit Oak #2498|https://builds.apache.org/job/Jackrabbit%20Oak/2498/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2498/console] > Build Jackrabbit Oak #2493 failed > - > > Key: OAK-8761 > URL: https://issues.apache.org/jira/browse/OAK-8761 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2493 has failed. > First failed run: [Jackrabbit Oak > #2493|https://builds.apache.org/job/Jackrabbit%20Oak/2493/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2493/console] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8761) Build Jackrabbit Oak #2493 failed
[ https://issues.apache.org/jira/browse/OAK-8761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16973573#comment-16973573 ] Hudson commented on OAK-8761: - Previously failing build now is OK. Passed run: [Jackrabbit Oak #2497|https://builds.apache.org/job/Jackrabbit%20Oak/2497/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2497/console] > Build Jackrabbit Oak #2493 failed > - > > Key: OAK-8761 > URL: https://issues.apache.org/jira/browse/OAK-8761 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2493 has failed. > First failed run: [Jackrabbit Oak > #2493|https://builds.apache.org/job/Jackrabbit%20Oak/2493/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2493/console] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8763) LoginContextProviderImpl uses any subject found in the AccessControlContext.
[ https://issues.apache.org/jira/browse/OAK-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-8763: Description: LoginContextProviderImpl#getLoginContext(...) extracts the most recent subject from the AccessControlContext and then uses it for either a PreAuthContext or a JaasLoginContext. This is wrong, because there is no reason to assume that such a subject has anything to do with Oak. It particularly hurts when it's readonly, because JAAS will then silently fail to add principals and credentials. We would need a way to identify pre-authenticated subjects and subjects that are not pre-authenticated should not be used to create a JaasLoginContext. was: LoginContextProviderImpl#getLoginContext(...) extracts the most recent subject from the AccessControlContext and the uses it for either a PreAuthContext or a JaasLoginContext. This is wrong, because there is no reason to assume that such a subject has anything to do with Oak. It particularly hurts when it's readonly, because JAAS will then silently fail to add principals and credentials. We would need a way to identify pre-authenticated subjects and subjects that are not pre-authenticated should not be used to create a JaasLoginContext. > LoginContextProviderImpl uses any subject found in the AccessControlContext. > > > Key: OAK-8763 > URL: https://issues.apache.org/jira/browse/OAK-8763 > Project: Jackrabbit Oak > Issue Type: Bug > Components: security-spi >Reporter: Manfred Baedke >Assignee: Angela Schreiber >Priority: Major > > LoginContextProviderImpl#getLoginContext(...) extracts the most recent > subject from the AccessControlContext and then uses it for either a > PreAuthContext or a JaasLoginContext. This is wrong, because there is no > reason to assume that such a subject has anything to do with Oak. It > particularly hurts when it's readonly, because JAAS will then silently fail > to add principals and credentials. > We would need a way to identify pre-authenticated subjects and subjects that > are not pre-authenticated should not be used to create a JaasLoginContext. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OAK-8765) oak-run segment-copy command should include option to specify the number of entries to transfer from the journal
Andrei Dulceanu created OAK-8765:
Summary: oak-run segment-copy command should include option to
specify the number of entries to transfer from the journal
Key: OAK-8765
URL: https://issues.apache.org/jira/browse/OAK-8765
Project: Jackrabbit Oak
Issue Type: Improvement
Components: segment-azure, segment-tar
Reporter: Andrei Dulceanu
Assignee: Andrei Dulceanu
In {{SegmentStoreMigrator}} we already have the option to transfer only the
last revision of the journal, but this is not yet exposed in
{{SegmentCopyCommand}}. It would be nice to make it more flexible and include
also a {{--last}} option as we already have for {{oak-run check}} to specify
the number of entries to transfer.
/cc [~tomekr]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (OAK-8710) AbstractLoginModule#logout() must not remove 'foreign' principals/credentials
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16973424#comment-16973424
]
Angela Schreiber edited comment on OAK-8710 at 11/13/19 4:18 PM:
-
the fix causes unexpected errors being logged with {{ContentSession.close()}},
will revert the changes to get a precise understanding what's the reason ->
revision 1869749.
was (Author: anchela):
the fix causes unexpected errors being logged with {{ContentSession.close()}},
will revert the changes to get a precise understanding what's the reason.
> AbstractLoginModule#logout() must not remove 'foreign' principals/credentials
> --
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external, core, security-spi
>Reporter: Manfred Baedke
>Assignee: Angela Schreiber
>Priority: Major
> Fix For: 1.20.0
>
> Attachments: OAK-8710.patch, logout.png
>
>
> 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] [Comment Edited] (OAK-8763) LoginContextProviderImpl uses any subject found in the AccessControlContext.
[ https://issues.apache.org/jira/browse/OAK-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16973480#comment-16973480 ] Manfred Baedke edited comment on OAK-8763 at 11/13/19 4:10 PM: --- See https://issues.apache.org/jira/secure/attachment/12985222/logout.png for an example of a preexisting readonly subject not featuring the principals and credentials it's supposed to hold (note that LoginModuleImpl#credentials holds ImpersonationCredentials not to be found in the subject). was (Author: baedke): See https://issues.apache.org/jira/secure/attachment/12985222/logout.png for an example of a preexisting readonly subject not featuring the principals and credentials it's supposed to hold (note that LoginModuleImpl#credentials holds ImpersonationCredentials not to be found in the subject. > LoginContextProviderImpl uses any subject found in the AccessControlContext. > > > Key: OAK-8763 > URL: https://issues.apache.org/jira/browse/OAK-8763 > Project: Jackrabbit Oak > Issue Type: Bug > Components: security-spi >Reporter: Manfred Baedke >Assignee: Angela Schreiber >Priority: Major > > LoginContextProviderImpl#getLoginContext(...) extracts the most recent > subject from the AccessControlContext and the uses it for either a > PreAuthContext or a JaasLoginContext. This is wrong, because there is no > reason to assume that such a subject has anything to do with Oak. It > particularly hurts when it's readonly, because JAAS will then silently fail > to add principals and credentials. > We would need a way to identify pre-authenticated subjects and subjects that > are not pre-authenticated should not be used to create a JaasLoginContext. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8763) LoginContextProviderImpl uses any subject found in the AccessControlContext.
[ https://issues.apache.org/jira/browse/OAK-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16973480#comment-16973480 ] Manfred Baedke commented on OAK-8763: - See https://issues.apache.org/jira/secure/attachment/12985222/logout.png for an example of a preexisting readonly subject not featuring the principals and credentials it's supposed to hold (note that LoginModuleImpl#credentials holds ImpersonationCredentials not to be found in the subject. > LoginContextProviderImpl uses any subject found in the AccessControlContext. > > > Key: OAK-8763 > URL: https://issues.apache.org/jira/browse/OAK-8763 > Project: Jackrabbit Oak > Issue Type: Bug > Components: security-spi >Reporter: Manfred Baedke >Assignee: Angela Schreiber >Priority: Major > > LoginContextProviderImpl#getLoginContext(...) extracts the most recent > subject from the AccessControlContext and the uses it for either a > PreAuthContext or a JaasLoginContext. This is wrong, because there is no > reason to assume that such a subject has anything to do with Oak. It > particularly hurts when it's readonly, because JAAS will then silently fail > to add principals and credentials. > We would need a way to identify pre-authenticated subjects and subjects that > are not pre-authenticated should not be used to create a JaasLoginContext. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8764) RDBDocumentStore: avoid potential dangerous use of addAll(entrySet) in logging code
[ https://issues.apache.org/jira/browse/OAK-8764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16973471#comment-16973471 ] Julian Reschke commented on OAK-8764: - trunk: [r1869748|http://svn.apache.org/r1869748] > RDBDocumentStore: avoid potential dangerous use of addAll(entrySet) in > logging code > --- > > Key: OAK-8764 > URL: https://issues.apache.org/jira/browse/OAK-8764 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_10 > Fix For: 1.20.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8764) RDBDocumentStore: avoid potential dangerous use of addAll(entrySet) in logging code
[ https://issues.apache.org/jira/browse/OAK-8764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8764: Labels: candidate_oak_1_10 (was: ) > RDBDocumentStore: avoid potential dangerous use of addAll(entrySet) in > logging code > --- > > Key: OAK-8764 > URL: https://issues.apache.org/jira/browse/OAK-8764 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_10 > Fix For: 1.20.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OAK-8764) RDBDocumentStore: avoid potential dangerous use of addAll(entrySet) in logging code
[ https://issues.apache.org/jira/browse/OAK-8764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved OAK-8764. - Fix Version/s: 1.20.0 Resolution: Fixed > RDBDocumentStore: avoid potential dangerous use of addAll(entrySet) in > logging code > --- > > Key: OAK-8764 > URL: https://issues.apache.org/jira/browse/OAK-8764 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.20.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OAK-8764) RDBDocumentStore: avoid potential dangerous use of addAll(entrySet) in logging code
Julian Reschke created OAK-8764: --- Summary: RDBDocumentStore: avoid potential dangerous use of addAll(entrySet) in logging code Key: OAK-8764 URL: https://issues.apache.org/jira/browse/OAK-8764 Project: Jackrabbit Oak Issue Type: Technical task Components: rdbmk Reporter: Julian Reschke Assignee: Julian Reschke -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8763) LoginContextProviderImpl uses any subject found in the AccessControlContext.
[ https://issues.apache.org/jira/browse/OAK-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-8763: Description: LoginContextProviderImpl#getLoginContext(...) extracts the most recent subject from the AccessControlContext and the uses it for either a PreAuthContext or a JaasLoginContext. This is wrong, because there is no reason to assume that such a subject has anything to do with Oak. It particularly hurts when it's readonly, because JAAS will then silently fail to add principals and credentials. We would need a way to identify pre-authenticated subjects and subjects that are not pre-authenticated should not be used to create a JaasLoginContext. was:LoginContextProviderImpl#getLoginContext(...) extracts the most recent subject from the AccessControlContext and the uses it for either a PreAuthContext or a JaasLoginContext. This is wrong, because there is no reason to assume that such a subject has anything to do with Oak. It particularly hurts when it's readonly, because JAAS will then silently fail to add principals and credentials. > LoginContextProviderImpl uses any subject found in the AccessControlContext. > > > Key: OAK-8763 > URL: https://issues.apache.org/jira/browse/OAK-8763 > Project: Jackrabbit Oak > Issue Type: Bug > Components: security-spi >Reporter: Manfred Baedke >Assignee: Angela Schreiber >Priority: Major > > LoginContextProviderImpl#getLoginContext(...) extracts the most recent > subject from the AccessControlContext and the uses it for either a > PreAuthContext or a JaasLoginContext. This is wrong, because there is no > reason to assume that such a subject has anything to do with Oak. It > particularly hurts when it's readonly, because JAAS will then silently fail > to add principals and credentials. > We would need a way to identify pre-authenticated subjects and subjects that > are not pre-authenticated should not be used to create a JaasLoginContext. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OAK-8763) LoginContextProviderImpl uses any subject found in the AccessControlContext.
Manfred Baedke created OAK-8763: --- Summary: LoginContextProviderImpl uses any subject found in the AccessControlContext. Key: OAK-8763 URL: https://issues.apache.org/jira/browse/OAK-8763 Project: Jackrabbit Oak Issue Type: Bug Components: security-spi Reporter: Manfred Baedke Assignee: Angela Schreiber LoginContextProviderImpl#getLoginContext(...) extracts the most recent subject from the AccessControlContext and the uses it for either a PreAuthContext or a JaasLoginContext. This is wrong, because there is no reason to assume. that such a subject has anything to do with Oak. It particularly hurts when it's readonly, because JAAS will then silently fail to add principals and credentials. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (OAK-8710) AbstractLoginModule#logout() must not remove 'foreign' principals/credentials
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber reopened OAK-8710:
---
the fix causes unexpected errors being logged with {{ContentSession.close()}},
will revert the changes to get a precise understanding what's the reason.
> AbstractLoginModule#logout() must not remove 'foreign' principals/credentials
> --
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external, core, security-spi
>Reporter: Manfred Baedke
>Assignee: Angela Schreiber
>Priority: Major
> Fix For: 1.20.0
>
> Attachments: OAK-8710.patch, logout.png
>
>
> 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] [Comment Edited] (OAK-8570) RDB*Store: update mssql-jdbc driver reference to 7.4.1.jre8
[ https://issues.apache.org/jira/browse/OAK-8570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16912620#comment-16912620 ] Julian Reschke edited comment on OAK-8570 at 11/13/19 3:02 PM: --- trunk: (1.18.0) [r1865654|http://svn.apache.org/r1865654] 1.10: (1.10.6) [r1867820|http://svn.apache.org/r1867820] 1.8: [r1869744|http://svn.apache.org/r1869744] was (Author: reschke): trunk: (1.18.0) [r1865654|http://svn.apache.org/r1865654] 1.10: [r1867820|http://svn.apache.org/r1867820] > RDB*Store: update mssql-jdbc driver reference to 7.4.1.jre8 > --- > > Key: OAK-8570 > URL: https://issues.apache.org/jira/browse/OAK-8570 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_6 > Fix For: 1.20.0, 1.8.18, 1.10.6 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8570) RDB*Store: update mssql-jdbc driver reference to 7.4.1.jre8
[ https://issues.apache.org/jira/browse/OAK-8570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8570: Fix Version/s: 1.8.18 > RDB*Store: update mssql-jdbc driver reference to 7.4.1.jre8 > --- > > Key: OAK-8570 > URL: https://issues.apache.org/jira/browse/OAK-8570 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_8 > Fix For: 1.20.0, 1.8.18, 1.10.6 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8570) RDB*Store: update mssql-jdbc driver reference to 7.4.1.jre8
[ https://issues.apache.org/jira/browse/OAK-8570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8570: Labels: candidate_oak_1_6 (was: candidate_oak_1_8) > RDB*Store: update mssql-jdbc driver reference to 7.4.1.jre8 > --- > > Key: OAK-8570 > URL: https://issues.apache.org/jira/browse/OAK-8570 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_6 > Fix For: 1.20.0, 1.8.18, 1.10.6 > > -- 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=16973400#comment-16973400
]
Thomas Mueller commented on OAK-8673:
-
[~angela] I'm sorry I don't fully understand this... Is there some
documentation where this is explained? It might help to have it, for cases were
the cache sizes need to be adjusted (to avoid out of memory). As far as I know
(maybe wrong), there is:
* eager cache (per session? in number of entries and not memory usage.
configurable as you configured it, but how?)
* lazy-evaluation cache (per session? how large? I assume in number of entries
and not memory usage. configurable?)
* defaultpermissioncache (what is that exactly? is it lazy-evaluation cache or
eager cache or something else?)
When opening a session, the eager cache is filled if cache size is large
enough(?) If too large, then not. But there is a lazy-evaluation. What I still
don't get - If benchmark results are if the eager cache is disabled, why is it
so slow? Is it just that for this test case, hit rate on the lazy-evaluation
cache is so bad?
> 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] [Created] (OAK-8762) Several potential NullPointerException bugs
Qian Chen created OAK-8762:
--
Summary: Several potential NullPointerException bugs
Key: OAK-8762
URL: https://issues.apache.org/jira/browse/OAK-8762
Project: Jackrabbit Oak
Issue Type: Bug
Reporter: Qian Chen
Hi all,
Our bug scanner has reported some NPE bugs.
The bugs are caused by the
{code:java}
return null
{code}
in function
[retrieve()|https://github.com/apache/jackrabbit-oak/tree/trunk/oak-core/src/test/java/org/apache/jackrabbit/oak/query/QueryLogAnalyzer.java#L155]
Since the return value of the method retrieve() may be null , a NPE bug may
take place in
[retrieve()|https://github.com/apache/jackrabbit-oak/tree/trunk/oak-core/src/test/java/org/apache/jackrabbit/oak/query/QueryLogAnalyzer.java#L156]
when the return value of the method retrieve() was [passed
to|https://github.com/apache/jackrabbit-oak/tree/trunk/oak-core/src/test/java/org/apache/jackrabbit/oak/query/QueryLogAnalyzer.java#L63]
the first parameter of the method retrieve() .
And when the return value of the method retrieve() was [passed
to|https://github.com/apache/jackrabbit-oak/tree/trunk/oak-core/src/test/java/org/apache/jackrabbit/oak/query/QueryLogAnalyzer.java#L64]
the parameter of the method filterParams() , a NPE bug may also
[occur|https://github.com/apache/jackrabbit-oak/tree/trunk/oak-core/src/test/java/org/apache/jackrabbit/oak/query/QueryLogAnalyzer.java#L137].
Thanks.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8761) Build Jackrabbit Oak #2493 failed
[ https://issues.apache.org/jira/browse/OAK-8761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16973348#comment-16973348 ] Hudson commented on OAK-8761: - Previously failing build now is OK. Passed run: [Jackrabbit Oak #2496|https://builds.apache.org/job/Jackrabbit%20Oak/2496/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2496/console] > Build Jackrabbit Oak #2493 failed > - > > Key: OAK-8761 > URL: https://issues.apache.org/jira/browse/OAK-8761 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2493 has failed. > First failed run: [Jackrabbit Oak > #2493|https://builds.apache.org/job/Jackrabbit%20Oak/2493/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2493/console] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (OAK-8568) RDB*Store: update mysql jdbc driver reference to 8.0.17
[ https://issues.apache.org/jira/browse/OAK-8568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16912379#comment-16912379 ] Julian Reschke edited comment on OAK-8568 at 11/13/19 1:01 PM: --- trunk: (1.18.0) [r1865631|http://svn.apache.org/r1865631] 1.10: (1.10.6) [r1867787|http://svn.apache.org/r1867787] 1.8: [r1869736|http://svn.apache.org/r1869736] was (Author: reschke): trunk: (1.18.0) [r1865631|http://svn.apache.org/r1865631] 1.10: [r1867787|http://svn.apache.org/r1867787] > RDB*Store: update mysql jdbc driver reference to 8.0.17 > --- > > Key: OAK-8568 > URL: https://issues.apache.org/jira/browse/OAK-8568 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_6 > Fix For: 1.18.0, 1.8.18, 1.10.6 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8568) RDB*Store: update mysql jdbc driver reference to 8.0.17
[ https://issues.apache.org/jira/browse/OAK-8568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8568: Labels: candidate_oak_1_6 (was: candidate_oak_1_8) > RDB*Store: update mysql jdbc driver reference to 8.0.17 > --- > > Key: OAK-8568 > URL: https://issues.apache.org/jira/browse/OAK-8568 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_6 > Fix For: 1.18.0, 1.8.18, 1.10.6 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8568) RDB*Store: update mysql jdbc driver reference to 8.0.17
[ https://issues.apache.org/jira/browse/OAK-8568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8568: Fix Version/s: 1.8.18 > RDB*Store: update mysql jdbc driver reference to 8.0.17 > --- > > Key: OAK-8568 > URL: https://issues.apache.org/jira/browse/OAK-8568 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_8 > Fix For: 1.18.0, 1.8.18, 1.10.6 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8761) Build Jackrabbit Oak #2493 failed
[ https://issues.apache.org/jira/browse/OAK-8761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16973266#comment-16973266 ] Hudson commented on OAK-8761: - Build is still failing. Failed run: [Jackrabbit Oak #2495|https://builds.apache.org/job/Jackrabbit%20Oak/2495/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2495/console] > Build Jackrabbit Oak #2493 failed > - > > Key: OAK-8761 > URL: https://issues.apache.org/jira/browse/OAK-8761 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2493 has failed. > First failed run: [Jackrabbit Oak > #2493|https://builds.apache.org/job/Jackrabbit%20Oak/2493/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2493/console] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OAK-8650) PrincipalProviderTest fails with java 14
[
https://issues.apache.org/jira/browse/OAK-8650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber resolved OAK-8650.
---
Fix Version/s: 1.20.0
Resolution: Fixed
Committed revision 1869734.
> PrincipalProviderTest fails with java 14
>
>
> Key: OAK-8650
> URL: https://issues.apache.org/jira/browse/OAK-8650
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: security-spi
>Reporter: Julian Reschke
>Assignee: Angela Schreiber
>Priority: Minor
> Fix For: 1.20.0
>
> Attachments: OAK-8650.patch
>
>
> (with the fix for OAK-7358 applied, and jacoco turned off)
> {noformat}
> [ERROR] Tests run: 3, Failures: 0, Errors: 3, Skipped: 0, Time elapsed:
> 0.013 s <<< FAILURE! - in
> org.apache.jackrabbit.oak.spi.security.principal.PrincipalProviderTest
> [ERROR]
> testGetItemBasedPrincipal(org.apache.jackrabbit.oak.spi.security.principal.PrincipalProviderTest)
> Time elapsed: 0.012 s <<< ERROR!
> org.mockito.exceptions.base.MockitoException:Cannot call abstract real method
> on java object!
> Calling real methods is only possible when mocking non abstract method.
> //correct example:
> when(mockOfConcreteClass.nonAbstractMethod()).thenCallRealMethod();
> at
> org.apache.jackrabbit.oak.spi.security.principal.PrincipalProviderTest.testGetItemBasedPrincipal(PrincipalProviderTest.java:36)[ERROR]
>
> testGetMembershipPrincipals(org.apache.jackrabbit.oak.spi.security.principal.PrincipalProviderTest)
> Time elapsed: 0 s <<< ERROR!
> org.mockito.exceptions.base.MockitoException:Cannot call abstract real method
> on java object!
> Calling real methods is only possible when mocking non abstract method.
> //correct example:
> when(mockOfConcreteClass.nonAbstractMethod()).thenCallRealMethod();
> at
> org.apache.jackrabbit.oak.spi.security.principal.PrincipalProviderTest.testGetMembershipPrincipals(PrincipalProviderTest.java:43)[ERROR]
>
> testNegativeOffset(org.apache.jackrabbit.oak.spi.security.principal.PrincipalProviderTest)
> Time elapsed: 0.001 s <<< ERROR!
> java.lang.Exception: Unexpected exception,
> expected but
> was
> at
> org.apache.jackrabbit.oak.spi.security.principal.PrincipalProviderTest.testNegativeOffset(PrincipalProviderTest.java:51){noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (OAK-8710) AbstractLoginModule#logout() must not remove 'foreign' principals/credentials
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16973240#comment-16973240
]
Angela Schreiber edited comment on OAK-8710 at 11/13/19 10:58 AM:
--
[~reschke], i don't need it in a maintenance branch and would just fix it in
1.20.0. also it was manfred that spotted the issues and pointed to the
specification... but it seems in the meantime the issue he is investigating is
_not_ caused by the logout so, you would have to ask him.
and btw: i don't think this can be fixed without API changes (except for
removing AbstractLoginModule.logout altogether, which would essentially break
subclasses not contained in oak)
was (Author: anchela):
[~reschke], i don't need it in a maintenance branch and would just fix it in
1.20.0. also it was manfred that spotted the issues and pointed to the
specification... but it seems in the meantime the issue he is investigating is
_not_ caused by the logout so, you would have to ask him.
> AbstractLoginModule#logout() must not remove 'foreign' principals/credentials
> --
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external, core, security-spi
>Reporter: Manfred Baedke
>Assignee: Angela Schreiber
>Priority: Major
> Fix For: 1.20.0
>
> Attachments: OAK-8710.patch, logout.png
>
>
> 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() must not remove 'foreign' principals/credentials
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16973240#comment-16973240
]
Angela Schreiber commented on OAK-8710:
---
[~reschke], i don't need it in a maintenance branch and would just fix it in
1.20.0. also it was manfred that spotted the issues and pointed to the
specification... but it seems in the meantime the issue he is investigating is
_not_ caused by the logout so, you would have to ask him.
> AbstractLoginModule#logout() must not remove 'foreign' principals/credentials
> --
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external, core, security-spi
>Reporter: Manfred Baedke
>Assignee: Angela Schreiber
>Priority: Major
> Fix For: 1.20.0
>
> Attachments: OAK-8710.patch, logout.png
>
>
> 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() must not remove 'foreign' principals/credentials
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16973231#comment-16973231
]
Julian Reschke commented on OAK-8710:
-
Is this something that we need to resolve in maintenance branches? If so, a
change not involving an API change might be better. (And yes, sorry for
mentioning that only now).
> AbstractLoginModule#logout() must not remove 'foreign' principals/credentials
> --
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external, core, security-spi
>Reporter: Manfred Baedke
>Assignee: Angela Schreiber
>Priority: Major
> Fix For: 1.20.0
>
> Attachments: OAK-8710.patch, logout.png
>
>
> 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-8760) ClusterViewDocument uses static instance og SimpleDateFormat
[ https://issues.apache.org/jira/browse/OAK-8760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16973223#comment-16973223 ] Julian Reschke commented on OAK-8760: - I was just going through SpotBugs warnings. I realize that this might be contentious, but my preference is to resolve these warnings even if not strictly needed to avoid future confusion. That said, it might be better to actually improve the ISO8601 formatter in jackrabbit-commons to cover this case (and other cases) as well. Will have a look at it. > ClusterViewDocument uses static instance og SimpleDateFormat > > > Key: OAK-8760 > URL: https://issues.apache.org/jira/browse/OAK-8760 > Project: Jackrabbit Oak > Issue Type: Bug > Components: documentmk >Reporter: Julian Reschke >Priority: Minor > Attachments: OAK-8760.diff > > > ...which is not thread-safe. -- 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=16973206#comment-16973206
]
Angela Schreiber commented on OAK-8673:
---
[~thomasm], because the test does random reads and will hit the node store to
see if there are any permission entries defined for the given path with the
following 2 exceptions:
- permission entries have already been loaded in the defaultpermissioncache
- there are no permission entries for that path and the second map (that's the
one with the fixed size) still contains that path indicating that no entries
exist
if we were to read to same node x-times (instead of reading x random items), it
won't make a big difference.
if you are looking at the other results, you will spot that the
defaultpermissioncache is only triggered for the most severe parts, because the
way the test is setup it distributes the entries among the principals i can
create another variant that will no distribute the entries evenly to illustrate
that.
> 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] [Comment Edited] (OAK-8567) update tomcat-jdbc dependency to 8.5.43
[ https://issues.apache.org/jira/browse/OAK-8567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16912330#comment-16912330 ] Julian Reschke edited comment on OAK-8567 at 11/13/19 10:04 AM: trunk: (1.18.0) [r1865630|http://svn.apache.org/r1865630] 1.10: (1.10.6) [r1867774|http://svn.apache.org/r1867774] 1.8: [r1869733|http://svn.apache.org/r1869733] was (Author: reschke): trunk: (1.18.0) [r1865630|http://svn.apache.org/r1865630] 1.10: [r1867774|http://svn.apache.org/r1867774] > update tomcat-jdbc dependency to 8.5.43 > --- > > Key: OAK-8567 > URL: https://issues.apache.org/jira/browse/OAK-8567 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_6 > Fix For: 1.20.0, 1.8.18, 1.10.6 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8567) update tomcat-jdbc dependency to 8.5.43
[ https://issues.apache.org/jira/browse/OAK-8567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8567: Fix Version/s: 1.8.18 > update tomcat-jdbc dependency to 8.5.43 > --- > > Key: OAK-8567 > URL: https://issues.apache.org/jira/browse/OAK-8567 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_8 > Fix For: 1.20.0, 1.8.18, 1.10.6 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8567) update tomcat-jdbc dependency to 8.5.43
[ https://issues.apache.org/jira/browse/OAK-8567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8567: Labels: candidate_oak_1_6 (was: ) > update tomcat-jdbc dependency to 8.5.43 > --- > > Key: OAK-8567 > URL: https://issues.apache.org/jira/browse/OAK-8567 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_6 > Fix For: 1.20.0, 1.8.18, 1.10.6 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8567) update tomcat-jdbc dependency to 8.5.43
[ https://issues.apache.org/jira/browse/OAK-8567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8567: Labels: (was: candidate_oak_1_8) > update tomcat-jdbc dependency to 8.5.43 > --- > > Key: OAK-8567 > URL: https://issues.apache.org/jira/browse/OAK-8567 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.20.0, 1.8.18, 1.10.6 > > -- 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=16973185#comment-16973185
]
Thomas Mueller commented on OAK-8673:
-
> beyond the task at hand to re-evaluate if the current value of
> eager-cache-size is sufficient
Well you don't want to expand the cache size if there is a risk of running out
of memory... But given the next statement I'm not sure if there really is such
a risk...
> even for the lazy-evaluation a cache is populated (in fact there are even 2
> maps in that case), so depending on the distribution of permission entries
> and the access pattern (read/writing), the lazy cache might even consume more
> memory than the eager-cache...
But, why are benchmark results so bad the eager cache is disabled (size set to
0)?
> 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-8710) AbstractLoginModule#logout() must not remove 'foreign' principals/credentials
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber updated OAK-8710:
--
Fix Version/s: 1.20.0
> AbstractLoginModule#logout() must not remove 'foreign' principals/credentials
> --
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external, core, security-spi
>Reporter: Manfred Baedke
>Assignee: Angela Schreiber
>Priority: Major
> Fix For: 1.20.0
>
> Attachments: OAK-8710.patch, logout.png
>
>
> 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-8710) AbstractLoginModule#logout() must not remove 'foreign' principals/credentials
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber resolved OAK-8710.
---
Resolution: Fixed
Committed revision 1869730.
> AbstractLoginModule#logout() must not remove 'foreign' principals/credentials
> --
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external, core, security-spi
>Reporter: Manfred Baedke
>Assignee: Angela Schreiber
>Priority: Major
> Attachments: OAK-8710.patch, logout.png
>
>
> 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-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=16973162#comment-16973162
]
Angela Schreiber commented on OAK-8673:
---
[~thomasm], we had A in jackrabbit 1 and it was quite a terrible idea.
regarding B: we can look at this. but as a matter of fact the permissions are
slightly different to indices and other types of 'caches' as the number of
permissions is for the vast majority of use cases limited... in either way,
both topics essentially are beyond the task at hand to re-evaluate if the
current value of eager-cache-size is sufficient or should be adjusted. i would
therefore prefer to cover them with separate issues. also note: even for the
lazy-evaluation a cache is populated (in fact there are even 2 maps in that
case), so depending on the distribution of permission entries and the access
pattern (read/writing), the lazy cache might even consume more memory than the
eager-cache i will come up with some numbers to illustrate this.
> 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=16973150#comment-16973150
]
Thomas Mueller commented on OAK-8673:
-
So with cach size 0 (no cache), the system is very slow (basically unusable).
So a cache is need. I see two problems:
* A: Having one cache per session is problematic if there is no limit in the
number of sessions: there is no way to guarantee the system will not run out of
memory. Is there no way to use just one cache (for all sessions)?
* B: Having a cache size in number of entries is problematic, if memory usage
of entries is very different: there is no way to guarantee the system will not
run out of memory. To solve this, in various places in Oak we use "weighted"
caches, and estimate memory usage of entries (e.g. for strings, 24 + number of
characters). I can help with this.
I think both A and B need to be addressed.
> 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-8710) AbstractLoginModule#logout() must not remove 'foreign' principals/credentials
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16973115#comment-16973115
]
Julian Reschke commented on OAK-8710:
-
I have no opinion; this is outside my technical field :-)
> AbstractLoginModule#logout() must not remove 'foreign' principals/credentials
> --
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external, core, security-spi
>Reporter: Manfred Baedke
>Assignee: Angela Schreiber
>Priority: Major
> Attachments: OAK-8710.patch, logout.png
>
>
> 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)
