[jira] [Comment Edited] (OAK-4129) Use CredentialsSupport in TokenConfigurationImpl and TokenProviderImpl
[
https://issues.apache.org/jira/browse/OAK-4129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15263268#comment-15263268
]
Alexander Klimetschek edited comment on OAK-4129 at 4/28/16 11:43 PM:
--
Will this really solve the problem of OAK-3899? Maybe it would, but the
description doesn't make it clear...
The problem over there is that some authentication mechanisms do not have a
user id that is passed into session.login(), but some other credential like a
token, and only in the middle of the login module process the external identity
provider figures out the (local) user id (very much like the TokenLoginModule
itself), which is required for the TokenLoginModule to create a token in
commit().
This means we currently cannot do "external identity provider authentication
w/o user id in credentials + create token" in one go. We are using a workaround
in which we create a new token using a new JCR session in the sling
authentication handler after the first login was successful (but did not
provide a ".token" in the attributes).
The only thing to get this issue fixed would be to respect
{{javax.security.auth.login.name}} from the shared state in the token impl -
which is completely independent on the type of Credentials passed in. Also, to
support the .token creation, the custom Credentials must have a map where you
can add the token to, to return it to the caller of session.login(), and that
would require a common interface like {{AttributedCredentials}} with
set/getAttributes().
was (Author: alexander.klimetschek):
Will this really solve the problem of OAK-3899? Maybe it would, but the
description doesn't make it clear...
The problem over there is that some authentication mechanisms do not have a
user id that is passed into session.login(), but some other credential like a
token, and only in the middle of the login module process the external identity
provider figures out the (local) user id (very much like the TokenLoginModule
itself), which is required for the TokenLoginModule to create a token in
commit().
This means we currently cannot do "external identity provider authentication
w/o user id in credentials + create token" in one go. We are using a workaround
in which we create a new token using a new JCR session in the sling
authentication handler after the first login was successful (but did not
provide a ".token" in the attributes).
The only thing to get this issue fixed would be to respect
{{javax.security.auth.login.name}} from the shared state in the token impl -
which is completely independent on the type of Credentials passed in. Also, to
support the .token creation, the custom Credentials must have a map where you
can add the token to, to return it to the caller of session.login(), and that
would require a common interface like "AttributedCredentials" with
set/getAttributes().
> Use CredentialsSupport in TokenConfigurationImpl and TokenProviderImpl
> --
>
> Key: OAK-4129
> URL: https://issues.apache.org/jira/browse/OAK-4129
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core
>Reporter: angela
>Assignee: angela
>Priority: Minor
>
> the default token implementation could make use of the {{CredentialsSupport}}
> thus not limiting the functionality to {{SimpleCredentials}}, which could
> still be used as default.
> in order to do so the {{CredentialsSupport}} would need to be extended with
> the ability to setAttibutes (i.e. an attribute map) to credentials
> corresponding to the getAttributes method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-4129) Use CredentialsSupport in TokenConfigurationImpl and TokenProviderImpl
[
https://issues.apache.org/jira/browse/OAK-4129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15263268#comment-15263268
]
Alexander Klimetschek edited comment on OAK-4129 at 4/28/16 11:43 PM:
--
Will this really solve the problem of OAK-3899? Maybe it would, but the
description doesn't make it clear...
The problem over there is that some authentication mechanisms do not have a
user id that is passed into session.login(), but some other credential like a
token, and only in the middle of the login module process the external identity
provider figures out the (local) user id (very much like the TokenLoginModule
itself), which is required for the TokenLoginModule to create a token in
commit().
This means we currently cannot do "external identity provider authentication
w/o user id in credentials + create token" in one go. We are using a workaround
in which we create a new token using a new JCR session in the sling
authentication handler after the first login was successful (but did not
provide a ".token" in the attributes).
The only thing to get this issue fixed would be to respect
{{javax.security.auth.login.name}} from the shared state in the token impl -
which is completely independent on the type of Credentials passed in. Also, to
support the .token creation, the custom Credentials must have a map where you
can add the token to, to return it to the caller of session.login(), and that
would require a common interface like "AttributedCredentials" with
set/getAttributes().
was (Author: alexander.klimetschek):
Will this really solve the problem of OAK-3899? Maybe it would, but the
description doesn't make it clear...
The problem over there is that some authentication mechanisms do not have a
user id that is passed into session.login(), but some other credential like a
token, and only in the middle of the login module process the external identity
provider figures out the (local) user id (very much like the TokenLoginModule
itself), which is required for the TokenLoginModule to create a token in
commit().
This means we currently cannot do "external identity provider authentication
w/o user id in credentials + create token" in one go. We are using a workaround
in which we create a new token using a new JCR session in the sling
authentication handler after the first login was successful (but did not
provide a ".token" in the attributes).
The only thing to get this issue fixed would be to respect
{{javax.security.auth.login.name}} in the shared state - which is completely
independent on the type of Credentials passed in. Also, to support the .token
creation, the custom Credentials must have a map where you can add the token
to, to return it to the caller of session.login(), and that would require a
common interface like "AttributedCredentials" with set/getAttributes().
> Use CredentialsSupport in TokenConfigurationImpl and TokenProviderImpl
> --
>
> Key: OAK-4129
> URL: https://issues.apache.org/jira/browse/OAK-4129
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core
>Reporter: angela
>Assignee: angela
>Priority: Minor
>
> the default token implementation could make use of the {{CredentialsSupport}}
> thus not limiting the functionality to {{SimpleCredentials}}, which could
> still be used as default.
> in order to do so the {{CredentialsSupport}} would need to be extended with
> the ability to setAttibutes (i.e. an attribute map) to credentials
> corresponding to the getAttributes method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-4129) Use CredentialsSupport in TokenConfigurationImpl and TokenProviderImpl
[
https://issues.apache.org/jira/browse/OAK-4129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15263268#comment-15263268
]
Alexander Klimetschek edited comment on OAK-4129 at 4/28/16 11:42 PM:
--
Will this really solve the problem of OAK-3899? Maybe it would, but the
description doesn't make it clear...
The problem over there is that some authentication mechanisms do not have a
user id that is passed into session.login(), but some other credential like a
token, and only in the middle of the login module process the external identity
provider figures out the (local) user id (very much like the TokenLoginModule
itself), which is required for the TokenLoginModule to create a token in
commit().
This means we currently cannot do "external identity provider authentication
w/o user id in credentials + create token" in one go. We are using a workaround
in which we create a new token using a new JCR session in the sling
authentication handler after the first login was successful (but did not
provide a ".token" in the attributes).
The only thing to get this issue fixed would be to respect
{{javax.security.auth.login.name}} in the shared state - which is completely
independent on the type of Credentials passed in. Also, to support the .token
creation, the custom Credentials must have a map where you can add the token
to, to return it to the caller of session.login(), and that would require a
common interface like "AttributedCredentials" with set/getAttributes().
was (Author: alexander.klimetschek):
Will this really solve the problem of OAK-3899? Maybe it would, but the
description doesn't make it clear...
The problem over there is that some authentication mechanisms do not have a
user id that is passed into session.login(), but some other credential like a
token, and only in the middle of the login module process the external identity
provider figures out the (local) user id (very much like the TokenLoginModule
itself), which is required for the TokenLoginModule to create a token in
commit().
This means we currently cannot do "external identity provider authentication +
create token" in one go. We are using a workaround in which we create a new
token using a new JCR session in the sling authentication handler after the
first login was successful (but did not provide a ".token" in the attributes).
The only thing to get this issue fixed would be to respect
{{javax.security.auth.login.name}} in the shared state - which is completely
independent on the type of Credentials passed in. Also, to support the .token
creation, the custom Credentials must have a map where you can add the token
to, to return it to the caller of session.login(), and that would require a
common interface like "AttributedCredentials" with set/getAttributes().
> Use CredentialsSupport in TokenConfigurationImpl and TokenProviderImpl
> --
>
> Key: OAK-4129
> URL: https://issues.apache.org/jira/browse/OAK-4129
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core
>Reporter: angela
>Assignee: angela
>Priority: Minor
>
> the default token implementation could make use of the {{CredentialsSupport}}
> thus not limiting the functionality to {{SimpleCredentials}}, which could
> still be used as default.
> in order to do so the {{CredentialsSupport}} would need to be extended with
> the ability to setAttibutes (i.e. an attribute map) to credentials
> corresponding to the getAttributes method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4129) Use CredentialsSupport in TokenConfigurationImpl and TokenProviderImpl
[
https://issues.apache.org/jira/browse/OAK-4129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15263268#comment-15263268
]
Alexander Klimetschek commented on OAK-4129:
Will this really solve the problem of OAK-3899? Maybe it would, but the
description doesn't make it clear...
The problem over there is that some authentication mechanisms do not have a
user id that is passed into session.login(), but some other credential like a
token, and only in the middle of the login module process the external identity
provider figures out the (local) user id (very much like the TokenLoginModule
itself), which is required for the TokenLoginModule to create a token in
commit().
This means we currently cannot do "external identity provider authentication +
create token" in one go. We are using a workaround in which we create a new
token using a new JCR session in the sling authentication handler after the
first login was successful (but did not provide a ".token" in the attributes).
The only thing to get this issue fixed would be to respect
{{javax.security.auth.login.name}} in the shared state - which is completely
independent on the type of Credentials passed in. Also, to support the .token
creation, the custom Credentials must have a map where you can add the token
to, to return it to the caller of session.login(), and that would require a
common interface like "AttributedCredentials" with set/getAttributes().
> Use CredentialsSupport in TokenConfigurationImpl and TokenProviderImpl
> --
>
> Key: OAK-4129
> URL: https://issues.apache.org/jira/browse/OAK-4129
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core
>Reporter: angela
>Assignee: angela
>Priority: Minor
>
> the default token implementation could make use of the {{CredentialsSupport}}
> thus not limiting the functionality to {{SimpleCredentials}}, which could
> still be used as default.
> in order to do so the {{CredentialsSupport}} would need to be extended with
> the ability to setAttibutes (i.e. an attribute map) to credentials
> corresponding to the getAttributes method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4322) Large values of a property should be handled gracefully
[ https://issues.apache.org/jira/browse/OAK-4322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Saurabh updated OAK-4322: --- Description: Sometimes values of a property can be really huge (in an observed case a comment was in the order of MBs). This can lead to document size going over the limit by underlying persistence (like 16MB for mongo). While, of course, such cases should be avoided at application level. But, from storage side, it'd be useful to bear a bit of pain, handle the situation gracefully (and possibly shout loudly in logs) One possible idea is to have a configurable limit on allowed size of values. If the size is more than that, we can potentially offload the actual value as blob and create a proxy value (having some meta information and blob ref) in the document. was: Sometimes values of a property can be really huge (in an observed case a comment was in the order of MBs). This can lead to document size going over the limit by underlying persistence (like 16MB for mongo). While, of course, such cases should be avoided at application level. But, from storage side, it'd be useful to bear a bit of pain, handle the situation gracefully (and possibly shout loudly in logs) > Large values of a property should be handled gracefully > --- > > Key: OAK-4322 > URL: https://issues.apache.org/jira/browse/OAK-4322 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk >Reporter: Vikas Saurabh >Assignee: Vikas Saurabh >Priority: Minor > > Sometimes values of a property can be really huge (in an observed case a > comment was in the order of MBs). This can lead to document size going over > the limit by underlying persistence (like 16MB for mongo). > While, of course, such cases should be avoided at application level. But, > from storage side, it'd be useful to bear a bit of pain, handle the situation > gracefully (and possibly shout loudly in logs) > One possible idea is to have a configurable limit on allowed size of values. > If the size is more than that, we can potentially offload the actual value as > blob and create a proxy value (having some meta information and blob ref) in > the document. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4322) Large values of a property should be handled gracefully
[ https://issues.apache.org/jira/browse/OAK-4322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Saurabh updated OAK-4322: --- Summary: Large values of a property should be handled gracefully (was: Large values of a property should be offloaded as blob) > Large values of a property should be handled gracefully > --- > > Key: OAK-4322 > URL: https://issues.apache.org/jira/browse/OAK-4322 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk >Reporter: Vikas Saurabh >Assignee: Vikas Saurabh >Priority: Minor > > Sometimes values of a property can be really huge (in an observed case a > comment was in the order of MBs). This can lead to document size going over > the limit by underlying persistence (like 16MB for mongo). > While, of course, such cases should be avoided at application level. But, > from storage side, it'd be useful to bear a bit of pain, handle the situation > gracefully (and possibly shout loudly in logs) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-4322) Large values of a property should be offloaded as blob
Vikas Saurabh created OAK-4322: -- Summary: Large values of a property should be offloaded as blob Key: OAK-4322 URL: https://issues.apache.org/jira/browse/OAK-4322 Project: Jackrabbit Oak Issue Type: Improvement Components: documentmk Reporter: Vikas Saurabh Assignee: Vikas Saurabh Priority: Minor Sometimes values of a property can be really huge (in an observed case a comment was in the order of MBs). This can lead to document size going over the limit by underlying persistence (like 16MB for mongo). While, of course, such cases should be avoided at application level. But, from storage side, it'd be useful to bear a bit of pain, handle the situation gracefully (and possibly shout loudly in logs) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4321) Improve conflict exception message to show if conflict is unexpected
[
https://issues.apache.org/jira/browse/OAK-4321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15263232#comment-15263232
]
Vikas Saurabh commented on OAK-4321:
[~mreutegg], probably the minimalist of fixes can be like:
{noformat}
---
a/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/Commit.java
+++
b/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/Commit.java
@@ -557,6 +557,8 @@ public class Commit {
private String formatConflictRevision(Revision r) {
if (nodeStore.getHeadRevision().isRevisionNewer(r)) {
return r + " (not yet visible)";
+} if (baseRevision != null && !baseRevision.isRevisionNewer(r)) {
+return r + " (older than base - " + baseRevision + ")";
} else {
return r.toString();
}
{noformat}
What I'm finding harder is to write test cases to create invalid conflicts -
any pointers?
In the mean time I'm also looking at some code paths in {{checkConflicts}} to
see if we are covering all cases.
> Improve conflict exception message to show if conflict is unexpected
>
>
> Key: OAK-4321
> URL: https://issues.apache.org/jira/browse/OAK-4321
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, documentmk
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
> Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4
> Fix For: 1.6
>
>
> Merge exception (aka OakMerge) are often expected when concurrent
> sessions do conflicting writes. But in some occasions, we've seen bugs in oak
> which also lead to merge exception.
> This creates confusion during investigation to isolate if it's an issue in
> oak or a genuine concurrent conflict.
> It'd be useful if the exception message has information to distinguish that.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-4313) QueryImpl should avoid traversal with queries containing native constraints
[
https://issues.apache.org/jira/browse/OAK-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15263121#comment-15263121
]
Vikas Saurabh edited comment on OAK-4313 at 4/28/16 10:25 PM:
--
Backported to 1.4 branch at [r1741533|https://svn.apache.org/r1741533] and to
1.2 branch at [r1741539|https://svn.apache.org/r1741539].
was (Author: catholicon):
Backported to 1.4 branch at [r1741533|https://svn.apache.org/r1741533].
> QueryImpl should avoid traversal with queries containing native constraints
> ---
>
> Key: OAK-4313
> URL: https://issues.apache.org/jira/browse/OAK-4313
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
> Fix For: 1.6, 1.4.2, 1.5.2, 1.2.15
>
> Attachments: OAK-4313.patch
>
>
> If no index supports suggestion (or spellcheck or similar) query, then a
> query like
> {noformat}
> SELECT * from [nt:base] where SUGGEST('test')
> {noformat}
> shouldn't get traversing index
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4313) QueryImpl should avoid traversal with queries containing native constraints
[
https://issues.apache.org/jira/browse/OAK-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-4313:
---
Fix Version/s: 1.2.15
> QueryImpl should avoid traversal with queries containing native constraints
> ---
>
> Key: OAK-4313
> URL: https://issues.apache.org/jira/browse/OAK-4313
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
> Fix For: 1.6, 1.4.2, 1.5.2, 1.2.15
>
> Attachments: OAK-4313.patch
>
>
> If no index supports suggestion (or spellcheck or similar) query, then a
> query like
> {noformat}
> SELECT * from [nt:base] where SUGGEST('test')
> {noformat}
> shouldn't get traversing index
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4313) QueryImpl should avoid traversal with queries containing native constraints
[
https://issues.apache.org/jira/browse/OAK-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-4313:
---
Labels: (was: candidate_oak_1_2)
> QueryImpl should avoid traversal with queries containing native constraints
> ---
>
> Key: OAK-4313
> URL: https://issues.apache.org/jira/browse/OAK-4313
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
> Fix For: 1.6, 1.4.2, 1.5.2, 1.2.15
>
> Attachments: OAK-4313.patch
>
>
> If no index supports suggestion (or spellcheck or similar) query, then a
> query like
> {noformat}
> SELECT * from [nt:base] where SUGGEST('test')
> {noformat}
> shouldn't get traversing index
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-4317) Similar and Native queries should return no results if no index can handle them
[ https://issues.apache.org/jira/browse/OAK-4317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15260944#comment-15260944 ] Vikas Saurabh edited comment on OAK-4317 at 4/28/16 10:07 PM: -- Fixed in [r1741339|https://svn.apache.org/r1741339] on trunk. Backported on 1.4 branch at [r1741523|https://svn.apache.org/r1741523] and on 1.2 branch at [r1741534|https://svn.apache.org/r1741534]. was (Author: catholicon): Fixed in [r1741339|https://svn.apache.org/r1741339] on trunk. Backported on 1.4 branch at [r1741523|https://svn.apache.org/r1741523]. > Similar and Native queries should return no results if no index can handle > them > --- > > Key: OAK-4317 > URL: https://issues.apache.org/jira/browse/OAK-4317 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Vikas Saurabh >Assignee: Vikas Saurabh >Priority: Minor > Fix For: 1.6, 1.4.2, 1.5.2, 1.2.15 > > > OAK-2548 fixed the same issue for SuggestImpl and SpellcheckImpl. We should > do the same for SimilarImpl and NativeFunctionImpl -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4317) Similar and Native queries should return no results if no index can handle them
[ https://issues.apache.org/jira/browse/OAK-4317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Saurabh updated OAK-4317: --- Fix Version/s: 1.2.15 > Similar and Native queries should return no results if no index can handle > them > --- > > Key: OAK-4317 > URL: https://issues.apache.org/jira/browse/OAK-4317 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Vikas Saurabh >Assignee: Vikas Saurabh >Priority: Minor > Fix For: 1.6, 1.4.2, 1.5.2, 1.2.15 > > > OAK-2548 fixed the same issue for SuggestImpl and SpellcheckImpl. We should > do the same for SimilarImpl and NativeFunctionImpl -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4313) QueryImpl should avoid traversal with queries containing native constraints
[
https://issues.apache.org/jira/browse/OAK-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-4313:
---
Fix Version/s: 1.4.2
> QueryImpl should avoid traversal with queries containing native constraints
> ---
>
> Key: OAK-4313
> URL: https://issues.apache.org/jira/browse/OAK-4313
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
> Labels: candidate_oak_1_2
> Fix For: 1.6, 1.4.2, 1.5.2
>
> Attachments: OAK-4313.patch
>
>
> If no index supports suggestion (or spellcheck or similar) query, then a
> query like
> {noformat}
> SELECT * from [nt:base] where SUGGEST('test')
> {noformat}
> shouldn't get traversing index
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4313) QueryImpl should avoid traversal with queries containing native constraints
[
https://issues.apache.org/jira/browse/OAK-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15263121#comment-15263121
]
Vikas Saurabh commented on OAK-4313:
Backported to 1.4 branch at [r1741533|https://svn.apache.org/r1741533].
> QueryImpl should avoid traversal with queries containing native constraints
> ---
>
> Key: OAK-4313
> URL: https://issues.apache.org/jira/browse/OAK-4313
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
> Labels: candidate_oak_1_2
> Fix For: 1.6, 1.4.2, 1.5.2
>
> Attachments: OAK-4313.patch
>
>
> If no index supports suggestion (or spellcheck or similar) query, then a
> query like
> {noformat}
> SELECT * from [nt:base] where SUGGEST('test')
> {noformat}
> shouldn't get traversing index
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4313) QueryImpl should avoid traversal with queries containing native constraints
[
https://issues.apache.org/jira/browse/OAK-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-4313:
---
Labels: candidate_oak_1_2 (was: candidate_oak_1_2 candidate_oak_1_4)
> QueryImpl should avoid traversal with queries containing native constraints
> ---
>
> Key: OAK-4313
> URL: https://issues.apache.org/jira/browse/OAK-4313
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
> Labels: candidate_oak_1_2
> Fix For: 1.6, 1.4.2, 1.5.2
>
> Attachments: OAK-4313.patch
>
>
> If no index supports suggestion (or spellcheck or similar) query, then a
> query like
> {noformat}
> SELECT * from [nt:base] where SUGGEST('test')
> {noformat}
> shouldn't get traversing index
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-4317) Similar and Native queries should return no results if no index can handle them
[ https://issues.apache.org/jira/browse/OAK-4317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15260944#comment-15260944 ] Vikas Saurabh edited comment on OAK-4317 at 4/28/16 9:46 PM: - Fixed in [r1741339|https://svn.apache.org/r1741339] on trunk. Backported on 1.4 branch at [r1741523|https://svn.apache.org/r1741523]. was (Author: catholicon): Fixed in [r1741339|https://svn.apache.org/r1741339] on trunk. > Similar and Native queries should return no results if no index can handle > them > --- > > Key: OAK-4317 > URL: https://issues.apache.org/jira/browse/OAK-4317 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Vikas Saurabh >Assignee: Vikas Saurabh >Priority: Minor > Fix For: 1.6, 1.4.2, 1.5.2 > > > OAK-2548 fixed the same issue for SuggestImpl and SpellcheckImpl. We should > do the same for SimilarImpl and NativeFunctionImpl -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4317) Similar and Native queries should return no results if no index can handle them
[ https://issues.apache.org/jira/browse/OAK-4317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Saurabh updated OAK-4317: --- Fix Version/s: 1.4.2 > Similar and Native queries should return no results if no index can handle > them > --- > > Key: OAK-4317 > URL: https://issues.apache.org/jira/browse/OAK-4317 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Vikas Saurabh >Assignee: Vikas Saurabh >Priority: Minor > Fix For: 1.6, 1.4.2, 1.5.2 > > > OAK-2548 fixed the same issue for SuggestImpl and SpellcheckImpl. We should > do the same for SimilarImpl and NativeFunctionImpl -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4321) Improve conflict exception message to show if conflict is unexpected
[ https://issues.apache.org/jira/browse/OAK-4321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Saurabh updated OAK-4321: --- Fix Version/s: 1.6 > Improve conflict exception message to show if conflict is unexpected > > > Key: OAK-4321 > URL: https://issues.apache.org/jira/browse/OAK-4321 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, documentmk >Reporter: Vikas Saurabh >Assignee: Vikas Saurabh >Priority: Minor > Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4 > Fix For: 1.6 > > > Merge exception (aka OakMerge) are often expected when concurrent > sessions do conflicting writes. But in some occasions, we've seen bugs in oak > which also lead to merge exception. > This creates confusion during investigation to isolate if it's an issue in > oak or a genuine concurrent conflict. > It'd be useful if the exception message has information to distinguish that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-4321) Improve conflict exception message to show if conflict is unexpected
Vikas Saurabh created OAK-4321: -- Summary: Improve conflict exception message to show if conflict is unexpected Key: OAK-4321 URL: https://issues.apache.org/jira/browse/OAK-4321 Project: Jackrabbit Oak Issue Type: Improvement Components: core, documentmk Reporter: Vikas Saurabh Assignee: Vikas Saurabh Priority: Minor Merge exception (aka OakMerge) are often expected when concurrent sessions do conflicting writes. But in some occasions, we've seen bugs in oak which also lead to merge exception. This creates confusion during investigation to isolate if it's an issue in oak or a genuine concurrent conflict. It'd be useful if the exception message has information to distinguish that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-1823) Expose a method via JMX to sync all external groups
[
https://issues.apache.org/jira/browse/OAK-1823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15262596#comment-15262596
]
angela commented on OAK-1823:
-
to me the {{syncAllUsers}} call looks rather troublesome given the fact that a
given external identity provider may contain a lot more users than need to be
synchronized into the repo... and i would expect the same to be true for
groups. so, i am not sure if additionally adding {{syncAllGroups}} is really
desirable... in fact i'd rather suggest that we reconsider also
{{syncAllUsers}} in the future.
> Expose a method via JMX to sync all external groups
> ---
>
> Key: OAK-1823
> URL: https://issues.apache.org/jira/browse/OAK-1823
> Project: Jackrabbit Oak
> Issue Type: Wish
> Components: auth-external
>Reporter: Konrad Windszus
>
> With OAK-1711 a JMX interface for syncing Users was provided. It would be
> great if that could be extended to sync groups only.
> Usually ACLs are set on groups and with the help of the group.extrafilter
> OSGi attribute from the LdapIdentityProvider OSGi config that would restrict
> easily the groups which are imported.
> Syncing all users is usually too much, as in most of the cases only few users
> will actually leverage Oak.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4112) Replace the query exclusive lock with a cache tracker
[
https://issues.apache.org/jira/browse/OAK-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15262274#comment-15262274
]
Julian Reschke commented on OAK-4112:
-
In the long run, I'd want to see it everywhere. When things go wrong with this,
there'll be hard to debug issues, so at least we'd have the same issues
everywhere :-)
> Replace the query exclusive lock with a cache tracker
> -
>
> Key: OAK-4112
> URL: https://issues.apache.org/jira/browse/OAK-4112
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: documentmk, mongomk
>Reporter: Tomek Rękawek
>Assignee: Tomek Rękawek
> Labels: performance
> Fix For: 1.6, 1.5.2
>
> Attachments: OAK-4112-1.patch, OAK-4112-2.patch, OAK-4112-3.patch,
> OAK-4112-4.patch, OAK-4112.patch
>
>
> The {{MongoDocumentStore#query()}} method uses an expensive
> {{TreeLock#acquireExclusive}} method, introduced in OAK-1897 to avoid caching
> outdated documents.
> It should be possible to avoid acquiring the exclusive lock, by tracking the
> cache changes that occurs during the Mongo find() operation. When the find()
> is done, we can update the cache with the received documents if they haven't
> been invalidated in the meantime.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4112) Replace the query exclusive lock with a cache tracker
[
https://issues.apache.org/jira/browse/OAK-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15262229#comment-15262229
]
Tomek Rękawek commented on OAK-4112:
[~reschke], if you think we need and/or if it'd help with resolving OAK-4320
then yes. Which branches we should target?
> Replace the query exclusive lock with a cache tracker
> -
>
> Key: OAK-4112
> URL: https://issues.apache.org/jira/browse/OAK-4112
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: documentmk, mongomk
>Reporter: Tomek Rękawek
>Assignee: Tomek Rękawek
> Labels: performance
> Fix For: 1.6, 1.5.2
>
> Attachments: OAK-4112-1.patch, OAK-4112-2.patch, OAK-4112-3.patch,
> OAK-4112-4.patch, OAK-4112.patch
>
>
> The {{MongoDocumentStore#query()}} method uses an expensive
> {{TreeLock#acquireExclusive}} method, introduced in OAK-1897 to avoid caching
> outdated documents.
> It should be possible to avoid acquiring the exclusive lock, by tracking the
> cache changes that occurs during the Mongo find() operation. When the find()
> is done, we can update the cache with the received documents if they haven't
> been invalidated in the meantime.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-4315) DefaultSyncHandler shouldn't apply automatic membership on existing users.
[ https://issues.apache.org/jira/browse/OAK-4315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15260701#comment-15260701 ] angela edited comment on OAK-4315 at 4/28/16 2:24 PM: -- [~baedke], not sure if that is really a bug. in particular any changes to the auto-membership configuration would no longer be reflected for existing synced-users. what makes you think that this is a bug? do you want to avoid extra-membership sync operations as long as the automembership hasn't changed? if that was the case, i would rather rephrase the report to something like "don't apply auto-membership if not changed"; this would allow to minimize the sync-effort while at the same time asserting that any modifications to the auto-membership configuration gets reflected upon resync. in general i think something like OAK-4087 would be a better approach on the long run. was (Author: anchela): [~baedke], not sure if that is really a bug. in particular any changes to the auto-membership would no longer be reflected for existing synced-users. what makes you think that this is a bug? do you want to avoid extra-membership sync operations as long as the automembership hasn't changed? if that was the case, i would rather rephrase the report to something like "don't apply auto-membership if not changed"; this would allow to minimize the sync-effort while at the same time asserting that any modifications to the auto-membership configuration gets reflected upon resync. in general i think something like OAK-4087 would be a better approach on the long run. > DefaultSyncHandler shouldn't apply automatic membership on existing users. > -- > > Key: OAK-4315 > URL: https://issues.apache.org/jira/browse/OAK-4315 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-external >Affects Versions: 1.0.30, 1.2.14, 1.5.1 >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > > The DefaultSyncHandler applies automatic group membership on every user sync. > It should only be applied when a new user has been created by the sync > process. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4168) Replace the massive lock acquire with cache tracker in bulk createOrUpdate()
[ https://issues.apache.org/jira/browse/OAK-4168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15262217#comment-15262217 ] Tomek Rękawek commented on OAK-4168: Fixed for trunk in [r1741430|https://svn.apache.org/r1741430]. > Replace the massive lock acquire with cache tracker in bulk createOrUpdate() > > > Key: OAK-4168 > URL: https://issues.apache.org/jira/browse/OAK-4168 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk, mongomk >Reporter: Tomek Rękawek >Assignee: Tomek Rękawek >Priority: Minor > Fix For: 1.6, 1.5.2 > > Attachments: OAK-4168.patch > > > OAK-4112 introduces an experimental cache tracker mechanism, that can be used > instead of bulk Lock.acquire() operation. Investigate whether the same > mechanism may be used in the bulk createOrUpdate() method in MongoMK. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-4168) Replace the massive lock acquire with cache tracker in bulk createOrUpdate()
[ https://issues.apache.org/jira/browse/OAK-4168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomek Rękawek resolved OAK-4168. Resolution: Fixed Fix Version/s: 1.5.2 > Replace the massive lock acquire with cache tracker in bulk createOrUpdate() > > > Key: OAK-4168 > URL: https://issues.apache.org/jira/browse/OAK-4168 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk, mongomk >Reporter: Tomek Rękawek >Assignee: Tomek Rękawek >Priority: Minor > Fix For: 1.6, 1.5.2 > > Attachments: OAK-4168.patch > > > OAK-4112 introduces an experimental cache tracker mechanism, that can be used > instead of bulk Lock.acquire() operation. Investigate whether the same > mechanism may be used in the bulk createOrUpdate() method in MongoMK. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4112) Replace the query exclusive lock with a cache tracker
[
https://issues.apache.org/jira/browse/OAK-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15262166#comment-15262166
]
Julian Reschke commented on OAK-4112:
-
Are we planning to eventually backport this?
> Replace the query exclusive lock with a cache tracker
> -
>
> Key: OAK-4112
> URL: https://issues.apache.org/jira/browse/OAK-4112
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: documentmk, mongomk
>Reporter: Tomek Rękawek
>Assignee: Tomek Rękawek
> Labels: performance
> Fix For: 1.6, 1.5.2
>
> Attachments: OAK-4112-1.patch, OAK-4112-2.patch, OAK-4112-3.patch,
> OAK-4112-4.patch, OAK-4112.patch
>
>
> The {{MongoDocumentStore#query()}} method uses an expensive
> {{TreeLock#acquireExclusive}} method, introduced in OAK-1897 to avoid caching
> outdated documents.
> It should be possible to avoid acquiring the exclusive lock, by tracking the
> cache changes that occurs during the Mongo find() operation. When the find()
> is done, we can update the cache with the received documents if they haven't
> been invalidated in the meantime.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (OAK-4320) Use the cache tracker in the RDB Document Store
[
https://issues.apache.org/jira/browse/OAK-4320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomek Rękawek reassigned OAK-4320:
--
Assignee: Tomek Rękawek
> Use the cache tracker in the RDB Document Store
> ---
>
> Key: OAK-4320
> URL: https://issues.apache.org/jira/browse/OAK-4320
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: documentmk, rdbmk
>Reporter: Tomek Rękawek
>Assignee: Tomek Rękawek
> Fix For: 1.6
>
> Attachments: OAK-4320.patch
>
>
> OAK-4112 introduced {{CacheChangesTracker}} mechanism, inspired by the
> {{QueryContext}} class, already present in the RBD DS.
> The tracker works on the {{NodeDocumentCache}} level, within the methods
> modifying the cache values, using the same {{NodeDocumentLocks}}, which may
> prevent potential concurrency problems, described in the comments to OAK-3566.
> We should synchronise both approaches, so the queries in Mongo and RDB uses
> the same logic to update their caches.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4320) Use the cache tracker in the RDB Document Store
[
https://issues.apache.org/jira/browse/OAK-4320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15262141#comment-15262141
]
Tomek Rękawek commented on OAK-4320:
[~reschke], could you review the OAK-4112 approach and the patch attached to
this issue?
> Use the cache tracker in the RDB Document Store
> ---
>
> Key: OAK-4320
> URL: https://issues.apache.org/jira/browse/OAK-4320
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: documentmk, rdbmk
>Reporter: Tomek Rękawek
> Fix For: 1.6
>
> Attachments: OAK-4320.patch
>
>
> OAK-4112 introduced {{CacheChangesTracker}} mechanism, inspired by the
> {{QueryContext}} class, already present in the RBD DS.
> The tracker works on the {{NodeDocumentCache}} level, within the methods
> modifying the cache values, using the same {{NodeDocumentLocks}}, which may
> prevent potential concurrency problems, described in the comments to OAK-3566.
> We should synchronise both approaches, so the queries in Mongo and RDB uses
> the same logic to update their caches.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4320) Use the cache tracker in the RDB Document Store
[
https://issues.apache.org/jira/browse/OAK-4320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomek Rękawek updated OAK-4320:
---
Attachment: OAK-4320.patch
> Use the cache tracker in the RDB Document Store
> ---
>
> Key: OAK-4320
> URL: https://issues.apache.org/jira/browse/OAK-4320
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: documentmk, rdbmk
>Reporter: Tomek Rękawek
> Fix For: 1.6
>
> Attachments: OAK-4320.patch
>
>
> OAK-4112 introduced {{CacheChangesTracker}} mechanism, inspired by the
> {{QueryContext}} class, already present in the RBD DS.
> The tracker works on the {{NodeDocumentCache}} level, within the methods
> modifying the cache values, using the same {{NodeDocumentLocks}}, which may
> prevent potential concurrency problems, described in the comments to OAK-3566.
> We should synchronise both approaches, so the queries in Mongo and RDB uses
> the same logic to update their caches.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-4320) Use the cache tracker in the RDB Document Store
Tomek Rękawek created OAK-4320:
--
Summary: Use the cache tracker in the RDB Document Store
Key: OAK-4320
URL: https://issues.apache.org/jira/browse/OAK-4320
Project: Jackrabbit Oak
Issue Type: Improvement
Components: documentmk, rdbmk
Reporter: Tomek Rękawek
Fix For: 1.6
OAK-4112 introduced {{CacheChangesTracker}} mechanism, inspired by the
{{QueryContext}} class, already present in the RBD DS.
The tracker works on the {{NodeDocumentCache}} level, within the methods
modifying the cache values, using the same {{NodeDocumentLocks}}, which may
prevent potential concurrency problems, described in the comments to OAK-3566.
We should synchronise both approaches, so the queries in Mongo and RDB uses the
same logic to update their caches.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-4319) TCPBroadcaster somes repeatedly logs "TCPBroadcaster Connected to"
Thomas Mueller created OAK-4319: --- Summary: TCPBroadcaster somes repeatedly logs "TCPBroadcaster Connected to" Key: OAK-4319 URL: https://issues.apache.org/jira/browse/OAK-4319 Project: Jackrabbit Oak Issue Type: Bug Reporter: Thomas Mueller Assignee: Thomas Mueller Fix For: 1.6 Sometimes, the TCPBroadcaster repeatedly (every two seconds) logs "TCPBroadcaster Connected to" messages with info level. There are old (inactive) entries in the clusterNodes collection, but the code should ignore those. Maybe it doesn't always work. I guess I will have to test myself. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-4112) Replace the query exclusive lock with a cache tracker
[
https://issues.apache.org/jira/browse/OAK-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15261905#comment-15261905
]
Tomek Rękawek edited comment on OAK-4112 at 4/28/16 1:17 PM:
-
Fixed for trunk in [r1741403|https://svn.apache.org/r1741403] &
[r1741422|https://svn.apache.org/r1741422].
was (Author: tomek.rekawek):
Fixed for trunk in [r1741403|https://svn.apache.org/r1741403].
> Replace the query exclusive lock with a cache tracker
> -
>
> Key: OAK-4112
> URL: https://issues.apache.org/jira/browse/OAK-4112
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: documentmk, mongomk
>Reporter: Tomek Rękawek
>Assignee: Tomek Rękawek
> Labels: performance
> Fix For: 1.6, 1.5.2
>
> Attachments: OAK-4112-1.patch, OAK-4112-2.patch, OAK-4112-3.patch,
> OAK-4112-4.patch, OAK-4112.patch
>
>
> The {{MongoDocumentStore#query()}} method uses an expensive
> {{TreeLock#acquireExclusive}} method, introduced in OAK-1897 to avoid caching
> outdated documents.
> It should be possible to avoid acquiring the exclusive lock, by tracking the
> cache changes that occurs during the Mongo find() operation. When the find()
> is done, we can update the cache with the received documents if they haven't
> been invalidated in the meantime.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-4318) Upgrade oak-solr to Solr 5.x
Tommaso Teofili created OAK-4318: Summary: Upgrade oak-solr to Solr 5.x Key: OAK-4318 URL: https://issues.apache.org/jira/browse/OAK-4318 Project: Jackrabbit Oak Issue Type: Improvement Components: solr Reporter: Tommaso Teofili Assignee: Tommaso Teofili Fix For: 1.6 Since we support JDK 1.7+ we can upgrade Solr to 5.x versions (not 6.0 as it requires java 8 though). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4165) Too verbose logging during revision gc
[
https://issues.apache.org/jira/browse/OAK-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari updated OAK-4165:
Priority: Blocker (was: Major)
> Too verbose logging during revision gc
> --
>
> Key: OAK-4165
> URL: https://issues.apache.org/jira/browse/OAK-4165
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-next
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Blocker
> Labels: cleanup, gc, logging
> Fix For: 1.4, 1.4.2
>
> Attachments: OAK_4165.patch
>
>
> {{FileStore.cleanup}} logs the segment id of any forward reference found when
> including those in the reference graph. The logged information can amount to
> several MBs impacting normal operation. Furthermore the actually reclaimed
> segments are logged, which also makes the log files explode. Finally the
> processing of the references and individual tar files might be too wordy.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4165) Too verbose logging during revision gc
[
https://issues.apache.org/jira/browse/OAK-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari updated OAK-4165:
Fix Version/s: (was: 1.6)
1.4
1.4.2
> Too verbose logging during revision gc
> --
>
> Key: OAK-4165
> URL: https://issues.apache.org/jira/browse/OAK-4165
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-next
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Blocker
> Labels: cleanup, gc, logging
> Fix For: 1.4, 1.4.2
>
> Attachments: OAK_4165.patch
>
>
> {{FileStore.cleanup}} logs the segment id of any forward reference found when
> including those in the reference graph. The logged information can amount to
> several MBs impacting normal operation. Furthermore the actually reclaimed
> segments are logged, which also makes the log files explode. Finally the
> processing of the references and individual tar files might be too wordy.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (OAK-4165) Too verbose logging during revision gc
[
https://issues.apache.org/jira/browse/OAK-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari reassigned OAK-4165:
---
Assignee: Francesco Mari (was: Michael Dürig)
> Too verbose logging during revision gc
> --
>
> Key: OAK-4165
> URL: https://issues.apache.org/jira/browse/OAK-4165
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-next
>Reporter: Michael Dürig
>Assignee: Francesco Mari
>Priority: Blocker
> Labels: cleanup, gc, logging
> Fix For: 1.4, 1.4.2
>
> Attachments: OAK_4165.patch
>
>
> {{FileStore.cleanup}} logs the segment id of any forward reference found when
> including those in the reference graph. The logged information can amount to
> several MBs impacting normal operation. Furthermore the actually reclaimed
> segments are logged, which also makes the log files explode. Finally the
> processing of the references and individual tar files might be too wordy.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4313) QueryImpl should avoid traversal with queries containing native constraints
[
https://issues.apache.org/jira/browse/OAK-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15261910#comment-15261910
]
Tommaso Teofili commented on OAK-4313:
--
yes, that's ok. Basically I should've changed the behaviour also for
_rep:similar_ back in OAK-2548, but I overlooked that: so thanks for having
spotted it.
> QueryImpl should avoid traversal with queries containing native constraints
> ---
>
> Key: OAK-4313
> URL: https://issues.apache.org/jira/browse/OAK-4313
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
> Labels: candidate_oak_1_2, candidate_oak_1_4
> Fix For: 1.6, 1.5.2
>
> Attachments: OAK-4313.patch
>
>
> If no index supports suggestion (or spellcheck or similar) query, then a
> query like
> {noformat}
> SELECT * from [nt:base] where SUGGEST('test')
> {noformat}
> shouldn't get traversing index
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4313) QueryImpl should avoid traversal with queries containing native constraints
[
https://issues.apache.org/jira/browse/OAK-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15261907#comment-15261907
]
Thomas Mueller commented on OAK-4313:
-
Looks good to me. Now no exception is thrown for the rep:similar() case, if no
(Lucene / Solr) index is available. That simplifies the code, but I'm not
completely sure if this is a problem, [~teofili] is it OK? In OAK-2548, you
didn't change rep:similar(), was there a reason for that, or maybe
rep:similar() was just not available / important back then? I assume you would
have written about that in OAK-2548 if there was a reason to throw an exception.
> QueryImpl should avoid traversal with queries containing native constraints
> ---
>
> Key: OAK-4313
> URL: https://issues.apache.org/jira/browse/OAK-4313
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
> Labels: candidate_oak_1_2, candidate_oak_1_4
> Fix For: 1.6, 1.5.2
>
> Attachments: OAK-4313.patch
>
>
> If no index supports suggestion (or spellcheck or similar) query, then a
> query like
> {noformat}
> SELECT * from [nt:base] where SUGGEST('test')
> {noformat}
> shouldn't get traversing index
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-4112) Replace the query exclusive lock with a cache tracker
[
https://issues.apache.org/jira/browse/OAK-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomek Rękawek resolved OAK-4112.
Resolution: Fixed
Fix Version/s: 1.5.2
> Replace the query exclusive lock with a cache tracker
> -
>
> Key: OAK-4112
> URL: https://issues.apache.org/jira/browse/OAK-4112
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: documentmk, mongomk
>Reporter: Tomek Rękawek
>Assignee: Tomek Rękawek
> Labels: performance
> Fix For: 1.6, 1.5.2
>
> Attachments: OAK-4112-1.patch, OAK-4112-2.patch, OAK-4112-3.patch,
> OAK-4112-4.patch, OAK-4112.patch
>
>
> The {{MongoDocumentStore#query()}} method uses an expensive
> {{TreeLock#acquireExclusive}} method, introduced in OAK-1897 to avoid caching
> outdated documents.
> It should be possible to avoid acquiring the exclusive lock, by tracking the
> cache changes that occurs during the Mongo find() operation. When the find()
> is done, we can update the cache with the received documents if they haven't
> been invalidated in the meantime.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4112) Replace the query exclusive lock with a cache tracker
[
https://issues.apache.org/jira/browse/OAK-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15261905#comment-15261905
]
Tomek Rękawek commented on OAK-4112:
Fixed for trunk in [r1741403|https://svn.apache.org/r1741403].
> Replace the query exclusive lock with a cache tracker
> -
>
> Key: OAK-4112
> URL: https://issues.apache.org/jira/browse/OAK-4112
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: documentmk, mongomk
>Reporter: Tomek Rękawek
>Assignee: Tomek Rękawek
> Labels: performance
> Fix For: 1.6
>
> Attachments: OAK-4112-1.patch, OAK-4112-2.patch, OAK-4112-3.patch,
> OAK-4112-4.patch, OAK-4112.patch
>
>
> The {{MongoDocumentStore#query()}} method uses an expensive
> {{TreeLock#acquireExclusive}} method, introduced in OAK-1897 to avoid caching
> outdated documents.
> It should be possible to avoid acquiring the exclusive lock, by tracking the
> cache changes that occurs during the Mongo find() operation. When the find()
> is done, we can update the cache with the received documents if they haven't
> been invalidated in the meantime.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (OAK-4112) Replace the query exclusive lock with a cache tracker
[
https://issues.apache.org/jira/browse/OAK-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomek Rękawek reassigned OAK-4112:
--
Assignee: Tomek Rękawek
> Replace the query exclusive lock with a cache tracker
> -
>
> Key: OAK-4112
> URL: https://issues.apache.org/jira/browse/OAK-4112
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: documentmk, mongomk
>Reporter: Tomek Rękawek
>Assignee: Tomek Rękawek
> Labels: performance
> Fix For: 1.6
>
> Attachments: OAK-4112-1.patch, OAK-4112-2.patch, OAK-4112-3.patch,
> OAK-4112-4.patch, OAK-4112.patch
>
>
> The {{MongoDocumentStore#query()}} method uses an expensive
> {{TreeLock#acquireExclusive}} method, introduced in OAK-1897 to avoid caching
> outdated documents.
> It should be possible to avoid acquiring the exclusive lock, by tracking the
> cache changes that occurs during the Mongo find() operation. When the find()
> is done, we can update the cache with the received documents if they haven't
> been invalidated in the meantime.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
