[jira] [Updated] (OAK-4043) Oak run checkpoints needs to account for multiple index lanes
[
https://issues.apache.org/jira/browse/OAK-4043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Marth updated OAK-4043:
---
Description:
Oak run {{checkpoints rm-unreferenced}} [0] currently is hardcoded on a single
checkpoint reference (the default one). Now is it possible to add multiple
lanes, which we already did in AEM, but the checkpoint tool is blissfully
unaware of this and it might trigger a full reindex following offline
compaction.
fyi [~edivad], [~chetanm]
[0] https://github.com/apache/jackrabbit-oak/tree/trunk/oak-run#checkpoints
was:
Oak run {{checkpoints rm-unreferenced}} [0] currently is hardcoded on a single
checkpoint reference (the default one). Now is it possible to add multiple
lanes, which we already did in AEM, but the checkpoint tool is blissfully
unaware of this and it might trigger a full reindex following offline
compaction.
This needs fixing before the big 1.4 release, so I'm marking it as a blocker.
fyi [~edivad], [~chetanm]
[0] https://github.com/apache/jackrabbit-oak/tree/trunk/oak-run#checkpoints
> Oak run checkpoints needs to account for multiple index lanes
> -
>
> Key: OAK-4043
> URL: https://issues.apache.org/jira/browse/OAK-4043
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, run
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
>Priority: Critical
> Labels: candidate_oak_1_4
> Fix For: 1.6, 1.5.11
>
> Attachments: OAK-4043.patch
>
>
> Oak run {{checkpoints rm-unreferenced}} [0] currently is hardcoded on a
> single checkpoint reference (the default one). Now is it possible to add
> multiple lanes, which we already did in AEM, but the checkpoint tool is
> blissfully unaware of this and it might trigger a full reindex following
> offline compaction.
> fyi [~edivad], [~chetanm]
> [0] https://github.com/apache/jackrabbit-oak/tree/trunk/oak-run#checkpoints
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4043) Oak run checkpoints needs to account for multiple index lanes
[
https://issues.apache.org/jira/browse/OAK-4043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Marth updated OAK-4043:
---
Priority: Critical (was: Blocker)
> Oak run checkpoints needs to account for multiple index lanes
> -
>
> Key: OAK-4043
> URL: https://issues.apache.org/jira/browse/OAK-4043
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, run
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
>Priority: Critical
> Labels: candidate_oak_1_4
> Fix For: 1.6, 1.5.11
>
> Attachments: OAK-4043.patch
>
>
> Oak run {{checkpoints rm-unreferenced}} [0] currently is hardcoded on a
> single checkpoint reference (the default one). Now is it possible to add
> multiple lanes, which we already did in AEM, but the checkpoint tool is
> blissfully unaware of this and it might trigger a full reindex following
> offline compaction.
> This needs fixing before the big 1.4 release, so I'm marking it as a blocker.
> fyi [~edivad], [~chetanm]
> [0] https://github.com/apache/jackrabbit-oak/tree/trunk/oak-run#checkpoints
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4043) Oak run checkpoints needs to account for multiple index lanes
[
https://issues.apache.org/jira/browse/OAK-4043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Marth updated OAK-4043:
---
Issue Type: Improvement (was: Bug)
> Oak run checkpoints needs to account for multiple index lanes
> -
>
> Key: OAK-4043
> URL: https://issues.apache.org/jira/browse/OAK-4043
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, run
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
>Priority: Blocker
> Labels: candidate_oak_1_4
> Fix For: 1.6, 1.5.11
>
> Attachments: OAK-4043.patch
>
>
> Oak run {{checkpoints rm-unreferenced}} [0] currently is hardcoded on a
> single checkpoint reference (the default one). Now is it possible to add
> multiple lanes, which we already did in AEM, but the checkpoint tool is
> blissfully unaware of this and it might trigger a full reindex following
> offline compaction.
> This needs fixing before the big 1.4 release, so I'm marking it as a blocker.
> fyi [~edivad], [~chetanm]
> [0] https://github.com/apache/jackrabbit-oak/tree/trunk/oak-run#checkpoints
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-4794) RDBDocumentStore: update PostgresQL JDBC driver
[ https://issues.apache.org/jira/browse/OAK-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15484224#comment-15484224 ] Julian Reschke edited comment on OAK-4794 at 9/16/16 3:31 PM: -- trunk: [r1760373|http://svn.apache.org/r1760373] 1.4: [r1760386|http://svn.apache.org/r1760386] 1.2: [r1761043|http://svn.apache.org/r1761043] 1.0: [r1761046|http://svn.apache.org/r1761046] was (Author: reschke): trunk: [r1760373|http://svn.apache.org/r1760373] 1.4: [r1760386|http://svn.apache.org/r1760386] 1.2: [r1761043|http://svn.apache.org/r1761043] > RDBDocumentStore: update PostgresQL JDBC driver > --- > > Key: OAK-4794 > URL: https://issues.apache.org/jira/browse/OAK-4794 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Affects Versions: 1.0.33, 1.2.18, 1.4.7, 1.5.9 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Trivial > Fix For: 1.0.34, 1.5.10, 1.4.8, 1.2.20 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4810) FileDataStore: support SHA-2
[ https://issues.apache.org/jira/browse/OAK-4810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15496551#comment-15496551 ] Michael Marth commented on OAK-4810: Re implementation: could this be a special case of OAK-3140? In OAK-3140 several DSs are defined. In this case, the SHA-256 DS would be read-write and the SHA-1 DS would be read-only. > FileDataStore: support SHA-2 > > > Key: OAK-4810 > URL: https://issues.apache.org/jira/browse/OAK-4810 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: blob >Reporter: Thomas Mueller > > The FileDataStore currently uses SHA-1, but that algorithm is deprecated. We > should support other algorithms as well (mainly SHA-256). > Migration should be painless (no long downtime). I think default for writing > (if not configured explicitly) could still be SHA-1. But when reading, > SHA-256 should also be supported (depending on the identifier). That way, the > new Oak version for all repositories (in a cluster + shared datastore) can be > installed "slowly". > After all repositories are running with the new Oak version, the > configuration for SHA-256 can be enabled. That way, SHA-256 is used for new > binaries. Both SHA-1 and SHA-256 are supported for reading. > One potential downside is deduplication would suffer a bit if a new Blob with > same content is added again as digest based match would fail. That can be > mitigated by computing 2 types of digest if need arises. The downsides are > some additional file operations and CPU, and slower migration to SHA-256. > Some other open questions: > * While we are at it, it might makes senses to additionally support SHA-3 and > other algorithms (make it configurable). But the length of the identifier > alone might then not be enough information to know what algorithm is used, so > maybe add a prefix. > * The number of subdirectory levels: should we keep it as is, or should we > reduce it (for example one level less). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4794) RDBDocumentStore: update PostgresQL JDBC driver
[ https://issues.apache.org/jira/browse/OAK-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-4794: Fix Version/s: 1.0.34 > RDBDocumentStore: update PostgresQL JDBC driver > --- > > Key: OAK-4794 > URL: https://issues.apache.org/jira/browse/OAK-4794 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Affects Versions: 1.0.33, 1.2.18, 1.4.7, 1.5.9 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Trivial > Fix For: 1.0.34, 1.5.10, 1.4.8, 1.2.20 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4794) RDBDocumentStore: update PostgresQL JDBC driver
[ https://issues.apache.org/jira/browse/OAK-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-4794: Labels: (was: candidate_oak_1_0) > RDBDocumentStore: update PostgresQL JDBC driver > --- > > Key: OAK-4794 > URL: https://issues.apache.org/jira/browse/OAK-4794 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Affects Versions: 1.0.33, 1.2.18, 1.4.7, 1.5.9 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Trivial > Fix For: 1.0.34, 1.5.10, 1.4.8, 1.2.20 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4794) RDBDocumentStore: update PostgresQL JDBC driver
[ https://issues.apache.org/jira/browse/OAK-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-4794: Fix Version/s: 1.2.20 > RDBDocumentStore: update PostgresQL JDBC driver > --- > > Key: OAK-4794 > URL: https://issues.apache.org/jira/browse/OAK-4794 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Affects Versions: 1.0.33, 1.2.18, 1.4.7, 1.5.9 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Trivial > Labels: candidate_oak_1_0 > Fix For: 1.5.10, 1.4.8, 1.2.20 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-4794) RDBDocumentStore: update PostgresQL JDBC driver
[ https://issues.apache.org/jira/browse/OAK-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15484224#comment-15484224 ] Julian Reschke edited comment on OAK-4794 at 9/16/16 2:51 PM: -- trunk: [r1760373|http://svn.apache.org/r1760373] 1.4: [r1760386|http://svn.apache.org/r1760386] 1.2: [r1761043|http://svn.apache.org/r1761043] was (Author: reschke): trunk: [r1760373|http://svn.apache.org/r1760373] 1.4: [r1760386|http://svn.apache.org/r1760386] > RDBDocumentStore: update PostgresQL JDBC driver > --- > > Key: OAK-4794 > URL: https://issues.apache.org/jira/browse/OAK-4794 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Affects Versions: 1.0.33, 1.2.18, 1.4.7, 1.5.9 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Trivial > Labels: candidate_oak_1_0 > Fix For: 1.5.10, 1.4.8, 1.2.20 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4794) RDBDocumentStore: update PostgresQL JDBC driver
[ https://issues.apache.org/jira/browse/OAK-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-4794: Labels: candidate_oak_1_0 (was: candidate_oak_1_0 candidate_oak_1_2) > RDBDocumentStore: update PostgresQL JDBC driver > --- > > Key: OAK-4794 > URL: https://issues.apache.org/jira/browse/OAK-4794 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Affects Versions: 1.0.33, 1.2.18, 1.4.7, 1.5.9 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Trivial > Labels: candidate_oak_1_0 > Fix For: 1.5.10, 1.4.8 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4794) RDBDocumentStore: update PostgresQL JDBC driver
[ https://issues.apache.org/jira/browse/OAK-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-4794: Labels: candidate_oak_1_0 candidate_oak_1_2 (was: ) > RDBDocumentStore: update PostgresQL JDBC driver > --- > > Key: OAK-4794 > URL: https://issues.apache.org/jira/browse/OAK-4794 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Affects Versions: 1.0.33, 1.2.18, 1.4.7, 1.5.9 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Trivial > Labels: candidate_oak_1_0, candidate_oak_1_2 > Fix For: 1.5.10, 1.4.8 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4815) ReferenceIndex slowdown due to OAK-3403
[ https://issues.apache.org/jira/browse/OAK-4815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15496338#comment-15496338 ] Thomas Mueller commented on OAK-4815: - I agree, I created OAK-4817 to track this. > ReferenceIndex slowdown due to OAK-3403 > --- > > Key: OAK-4815 > URL: https://issues.apache.org/jira/browse/OAK-4815 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.5.11 > > > In OAK-3403, a lookup using the ReferenceIndex now uses "new FilterImpl()", > which in turn uses "new QueryEngineSettings()". And this is slow, because it > is an AnnotatedStandardMBean, and instantiating such an object is quite slow. > (Actually it is also wrong, because the configured query engine settings are > not used in that case.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-4817) QueryEngineSettings without MBean
Thomas Mueller created OAK-4817: --- Summary: QueryEngineSettings without MBean Key: OAK-4817 URL: https://issues.apache.org/jira/browse/OAK-4817 Project: Jackrabbit Oak Issue Type: Improvement Components: query Reporter: Thomas Mueller Assignee: Thomas Mueller Fix For: 1.6 QueryEngineSettings is currently an MBean, and constructing a new instance is expensive. This is seem in some oak-core security components. The MBean functionality should be decoupled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4788) Fulltext parser sorts and unique-s parsed terms
[
https://issues.apache.org/jira/browse/OAK-4788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-4788:
Fix Version/s: 1.6
> Fulltext parser sorts and unique-s parsed terms
> ---
>
> Key: OAK-4788
> URL: https://issues.apache.org/jira/browse/OAK-4788
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Vikas Saurabh
>Assignee: Thomas Mueller
>Priority: Minor
> Fix For: 1.6
>
>
> Pasting a bit of discussion from OAK-4705:
> {quote}
> bq. whether it's a good idea to sort entries ("hello - world" becomes "-
> hello world") and make them unique ("test test" becomes "test").
> I think parser shouldn't play with ordering .. but I can see the rational
> that it allows consumer of parsed output to potentially have forward seeks in
> their dictionaries. Otoh, I think making unique or not shouldn't be parsers's
> concern at all.
> I'd open a new issue to follow up on these aspects.
> {quote}
> /cc [~tmueller]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4043) Oak run checkpoints needs to account for multiple index lanes
[
https://issues.apache.org/jira/browse/OAK-4043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu updated OAK-4043:
-
Attachment: OAK-4043.patch
proposed patch. [~chetanm] please review, especially the documentmk parts.
I kept the existing naming convention. {{name.endsWith("async") &&
ps.getType().equals(Type.STRING)}} should cover all existing values, plus one
can add anything ending in 'async' and it will be considered a reference.
> Oak run checkpoints needs to account for multiple index lanes
> -
>
> Key: OAK-4043
> URL: https://issues.apache.org/jira/browse/OAK-4043
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, run
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
>Priority: Blocker
> Labels: candidate_oak_1_4
> Fix For: 1.6, 1.5.11
>
> Attachments: OAK-4043.patch
>
>
> Oak run {{checkpoints rm-unreferenced}} [0] currently is hardcoded on a
> single checkpoint reference (the default one). Now is it possible to add
> multiple lanes, which we already did in AEM, but the checkpoint tool is
> blissfully unaware of this and it might trigger a full reindex following
> offline compaction.
> This needs fixing before the big 1.4 release, so I'm marking it as a blocker.
> fyi [~edivad], [~chetanm]
> [0] https://github.com/apache/jackrabbit-oak/tree/trunk/oak-run#checkpoints
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (OAK-4043) Oak run checkpoints needs to account for multiple index lanes
[
https://issues.apache.org/jira/browse/OAK-4043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu reassigned OAK-4043:
Assignee: Alex Parvulescu (was: Davide Giannella)
> Oak run checkpoints needs to account for multiple index lanes
> -
>
> Key: OAK-4043
> URL: https://issues.apache.org/jira/browse/OAK-4043
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, run
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
>Priority: Blocker
> Labels: candidate_oak_1_4
> Fix For: 1.6, 1.5.11
>
>
> Oak run {{checkpoints rm-unreferenced}} [0] currently is hardcoded on a
> single checkpoint reference (the default one). Now is it possible to add
> multiple lanes, which we already did in AEM, but the checkpoint tool is
> blissfully unaware of this and it might trigger a full reindex following
> offline compaction.
> This needs fixing before the big 1.4 release, so I'm marking it as a blocker.
> fyi [~edivad], [~chetanm]
> [0] https://github.com/apache/jackrabbit-oak/tree/trunk/oak-run#checkpoints
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4637) Property index: include/exclude pattern list
[ https://issues.apache.org/jira/browse/OAK-4637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15496215#comment-15496215 ] Thomas Mueller commented on OAK-4637: - Even more general would be to use an expression, similar to how function-based indexes work. So you could add a condition "[@productType='shoe' and @size <= 30]" for an index "kid-shoes" that would only index small shoes. The indexed property could be (for example) "color". Such an index would be used for queries with the condition "[@productType = 'shoe' and @size <= 30 and @color = 'green']". Sure, it's probably more than what is needed in most cases, but we could re-use the function-based index processing we already have in oak-lucene (probably move it to oak-core). > Property index: include/exclude pattern list > > > Key: OAK-4637 > URL: https://issues.apache.org/jira/browse/OAK-4637 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.6 > > > In some cases, property indexes contain many nodes, and updating them can be > slow. Right now we have filters for node and mixin types, path (include and > exclude). > An include and exclude list of values (patterns) would be useful. For example > the property "status", if we only ever run queries with the condition "status > = 'ACTIVE'", then nodes with status INACTIVE and DONE don't need to be > indexed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4816) Property index: cost estimate with path restriction is too optimistic
[
https://issues.apache.org/jira/browse/OAK-4816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-4816:
Component/s: query
> Property index: cost estimate with path restriction is too optimistic
> -
>
> Key: OAK-4816
> URL: https://issues.apache.org/jira/browse/OAK-4816
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
> Fix For: 1.6
>
>
> The property index cost estimation is too optimistic in case there is a
> property restriction plus a path restriction. The current algorithm, as
> documented in
> http://jackrabbit.apache.org/oak/docs/query/property-index.html#Cost_Estimation
> , assumes that matching entries are evenly distributed over the whole
> repository. In many cases, this is not the case. In extreme cases, _all_
> entries that match the property restriction are in the subtree that matches
> the path restriction. Example:
> * 10'000 nodes with property color "red".
> * 1 million nodes in the repository
> * 10'000 nodes in the subtree /content
> * query {{/jcr:root/content//\*[@color = 'red']}}
> Currently, the cost estimate is about 100, there are about 10'000 entries for
> "red", and "/content" contains 1% of all nodes. But in reality, there might
> be 10'000 entries with color "red" in that subtree (that is, all of them).
> The cost estimation should take that into account, and assume that at least
> 80% of the matching nodes are in that subtree (if the subtree contains that
> many nodes).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-4816) Property index: cost estimate with path restriction is too optimistic
Thomas Mueller created OAK-4816:
---
Summary: Property index: cost estimate with path restriction is
too optimistic
Key: OAK-4816
URL: https://issues.apache.org/jira/browse/OAK-4816
Project: Jackrabbit Oak
Issue Type: Improvement
Reporter: Thomas Mueller
Assignee: Thomas Mueller
Fix For: 1.6
The property index cost estimation is too optimistic in case there is a
property restriction plus a path restriction. The current algorithm, as
documented in
http://jackrabbit.apache.org/oak/docs/query/property-index.html#Cost_Estimation
, assumes that matching entries are evenly distributed over the whole
repository. In many cases, this is not the case. In extreme cases, _all_
entries that match the property restriction are in the subtree that matches the
path restriction. Example:
* 10'000 nodes with property color "red".
* 1 million nodes in the repository
* 10'000 nodes in the subtree /content
* query {{/jcr:root/content//\*[@color = 'red']}}
Currently, the cost estimate is about 100, there are about 10'000 entries for
"red", and "/content" contains 1% of all nodes. But in reality, there might be
10'000 entries with color "red" in that subtree (that is, all of them).
The cost estimation should take that into account, and assume that at least 80%
of the matching nodes are in that subtree (if the subtree contains that many
nodes).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-3574) Query engine: support p=lowercase('x') and other function-based indexes
[
https://issues.apache.org/jira/browse/OAK-3574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller resolved OAK-3574.
-
Resolution: Fixed
> Query engine: support p=lowercase('x') and other function-based indexes
> ---
>
> Key: OAK-3574
> URL: https://issues.apache.org/jira/browse/OAK-3574
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core, lucene, query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
> Fix For: 1.5.11
>
> Attachments: OAK-3574-lucene-2.patch, OAK-3574-lucene.patch
>
>
> Currently, the query engine and indexes don't support function-based indexes
> for conditions of the form lowercase(property) = 'x'. This needs to be
> supported, specially for the Lucene property index.
> Also important is lowercase(name()).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3574) Query engine: support p=lowercase('x') and other function-based indexes
[
https://issues.apache.org/jira/browse/OAK-3574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-3574:
Component/s: lucene
> Query engine: support p=lowercase('x') and other function-based indexes
> ---
>
> Key: OAK-3574
> URL: https://issues.apache.org/jira/browse/OAK-3574
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core, lucene, query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
> Fix For: 1.5.11
>
> Attachments: OAK-3574-lucene-2.patch, OAK-3574-lucene.patch
>
>
> Currently, the query engine and indexes don't support function-based indexes
> for conditions of the form lowercase(property) = 'x'. This needs to be
> supported, specially for the Lucene property index.
> Also important is lowercase(name()).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3574) Query engine: support p=lowercase('x') and other function-based indexes
[
https://issues.apache.org/jira/browse/OAK-3574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-3574:
Fix Version/s: 1.5.11
> Query engine: support p=lowercase('x') and other function-based indexes
> ---
>
> Key: OAK-3574
> URL: https://issues.apache.org/jira/browse/OAK-3574
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core, lucene, query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
> Fix For: 1.5.11
>
> Attachments: OAK-3574-lucene-2.patch, OAK-3574-lucene.patch
>
>
> Currently, the query engine and indexes don't support function-based indexes
> for conditions of the form lowercase(property) = 'x'. This needs to be
> supported, specially for the Lucene property index.
> Also important is lowercase(name()).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3574) Query engine: support p=lowercase('x') and other function-based indexes
[
https://issues.apache.org/jira/browse/OAK-3574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15496131#comment-15496131
]
Thomas Mueller commented on OAK-3574:
-
http://svn.apache.org/r1761025 (trunk) - committing the current patch, please
revert if there is a problem
> Query engine: support p=lowercase('x') and other function-based indexes
> ---
>
> Key: OAK-3574
> URL: https://issues.apache.org/jira/browse/OAK-3574
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core, query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
> Attachments: OAK-3574-lucene-2.patch, OAK-3574-lucene.patch
>
>
> Currently, the query engine and indexes don't support function-based indexes
> for conditions of the form lowercase(property) = 'x'. This needs to be
> supported, specially for the Lucene property index.
> Also important is lowercase(name()).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4815) ReferenceIndex slowdown due to OAK-3403
[ https://issues.apache.org/jira/browse/OAK-4815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15495950#comment-15495950 ] Chetan Mehrotra commented on OAK-4815: -- We should also look into decoupling the QueryEngineSettings from MBean aspect. This causes issue for me in [oakutils|https://github.com/chetanmeh/oakutils/blob/master/src/main/java/org/apache/jackrabbit/oak/query/QueryEngineSettings.java] as Google App Engine env does not allow access to jmx api > ReferenceIndex slowdown due to OAK-3403 > --- > > Key: OAK-4815 > URL: https://issues.apache.org/jira/browse/OAK-4815 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.5.11 > > > In OAK-3403, a lookup using the ReferenceIndex now uses "new FilterImpl()", > which in turn uses "new QueryEngineSettings()". And this is slow, because it > is an AnnotatedStandardMBean, and instantiating such an object is quite slow. > (Actually it is also wrong, because the configured query engine settings are > not used in that case.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-4815) ReferenceIndex slowdown due to OAK-3403
[ https://issues.apache.org/jira/browse/OAK-4815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller resolved OAK-4815. - Resolution: Fixed > ReferenceIndex slowdown due to OAK-3403 > --- > > Key: OAK-4815 > URL: https://issues.apache.org/jira/browse/OAK-4815 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.5.11 > > > In OAK-3403, a lookup using the ReferenceIndex now uses "new FilterImpl()", > which in turn uses "new QueryEngineSettings()". And this is slow, because it > is an AnnotatedStandardMBean, and instantiating such an object is quite slow. > (Actually it is also wrong, because the configured query engine settings are > not used in that case.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4815) ReferenceIndex slowdown due to OAK-3403
[ https://issues.apache.org/jira/browse/OAK-4815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15495897#comment-15495897 ] Thomas Mueller commented on OAK-4815: - http://svn.apache.org/r1761018 (trunk) prevent this to happen in the future > ReferenceIndex slowdown due to OAK-3403 > --- > > Key: OAK-4815 > URL: https://issues.apache.org/jira/browse/OAK-4815 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.5.11 > > > In OAK-3403, a lookup using the ReferenceIndex now uses "new FilterImpl()", > which in turn uses "new QueryEngineSettings()". And this is slow, because it > is an AnnotatedStandardMBean, and instantiating such an object is quite slow. > (Actually it is also wrong, because the configured query engine settings are > not used in that case.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4815) ReferenceIndex slowdown due to OAK-3403
[ https://issues.apache.org/jira/browse/OAK-4815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15495892#comment-15495892 ] Thomas Mueller commented on OAK-4815: - http://svn.apache.org/r1761016 (trunk) fixes the immediate problem. > ReferenceIndex slowdown due to OAK-3403 > --- > > Key: OAK-4815 > URL: https://issues.apache.org/jira/browse/OAK-4815 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.5.11 > > > In OAK-3403, a lookup using the ReferenceIndex now uses "new FilterImpl()", > which in turn uses "new QueryEngineSettings()". And this is slow, because it > is an AnnotatedStandardMBean, and instantiating such an object is quite slow. > (Actually it is also wrong, because the configured query engine settings are > not used in that case.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-4798) Share request encoders and decoders across the server and the client
[ https://issues.apache.org/jira/browse/OAK-4798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Mari resolved OAK-4798. - Resolution: Fixed Resolved as part of OAK-4803. > Share request encoders and decoders across the server and the client > > > Key: OAK-4798 > URL: https://issues.apache.org/jira/browse/OAK-4798 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar >Reporter: Francesco Mari >Assignee: Francesco Mari > Fix For: Segment Tar 0.0.12 > > > The encoders and decoders for the request and response objects used by the > server are currently private to the server implementation. These classes > should be made available to the client for further reuse. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-4003) Add support for Group-Membership actions
[
https://issues.apache.org/jira/browse/OAK-4003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amit Jain closed OAK-4003.
--
Close for 1.2.19
> Add support for Group-Membership actions
>
>
> Key: OAK-4003
> URL: https://issues.apache.org/jira/browse/OAK-4003
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core
>Reporter: angela
>Assignee: Dominique Jäggi
> Fix For: 1.6, 1.2.19
>
>
> [~djaeggi], as discussed today it would be cool to provide an extension for
> the user/group actions that allowed to hook in additional
> processing/verification upon update of group membership.
> initial thoughts to be discussed and verified for feasibilty:
> - create {{GroupAction}} interface extending {{AuthorizableAction}} (to not
> blow up the original interface with operations that only affect groups)
> - add 2 methods for addMember(s) and removeMember(s) each to cover both the
> add/removal by {{Authorizable}} and by multiple {{memberIds}}
> The actions should be called _after_ having successfully processed the
> modification and (in case on manipulation by ID) should only report those
> members that have been added/removed (see API contract of membership-update
> by ids).
> Methods could e.g. look something like
> {code}
> void onMemberAdded(Group group, Authorizable member, Root root,
> NamePathMapper namePathMapper) throws RepositoryException;
>
> void onMembersAdded(Group group, Iterable memberIds,
> Iterable failedIds, Root root, NamePathMapper namePathMapper) throws
> RepositoryException;
>void onMemberRemoved(Group group, Authorizable member, Root root,
> NamePathMapper namePathMapper) throws RepositoryException;
>
> void onMembersRemoved(Group group, Iterable memberIds,
> Iterable failedIds, Root root, NamePathMapper namePathMapper) throws
> RepositoryException;
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-4790) Compilation error with JDK 6 in FileIOUtils
[ https://issues.apache.org/jira/browse/OAK-4790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain closed OAK-4790. -- Close for 1.2.19 > Compilation error with JDK 6 in FileIOUtils > --- > > Key: OAK-4790 > URL: https://issues.apache.org/jira/browse/OAK-4790 > Project: Jackrabbit Oak > Issue Type: Bug > Components: commons >Affects Versions: 1.2.18, 1.4.7 >Reporter: Amit Jain >Assignee: Amit Jain > Fix For: 1.2.19, 1.4.8 > > > FIleIOUtils uses StandardCharsets which is available only from Java 1.7 and > thus fails compilation on Java 1.6 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-4791) Enable animal sniffer plugin
[ https://issues.apache.org/jira/browse/OAK-4791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain closed OAK-4791. -- Close for 1.2.19 > Enable animal sniffer plugin > > > Key: OAK-4791 > URL: https://issues.apache.org/jira/browse/OAK-4791 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.6, 1.2.19, 1.0.34, 1.5.10, 1.4.8 > > > I would like to use the animal sniffer plugin to enforce usage of the > advertised minimal Java version. For trunk this is currently Java 7, while > the 1.0, 1.2 and 1.4 branches are on Java 6. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-4615) RDBDocumentStore: in 1.0, cache invalidation is slightly different from 1.2
[
https://issues.apache.org/jira/browse/OAK-4615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amit Jain closed OAK-4615.
--
Close for 1.2.19
> RDBDocumentStore: in 1.0, cache invalidation is slightly different from 1.2
> ---
>
> Key: OAK-4615
> URL: https://issues.apache.org/jira/browse/OAK-4615
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: rdbmk
>Affects Versions: 1.2.18
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Fix For: 1.2.19
>
> Attachments: OAK-4615.diff
>
>
> The difference is:
> {noformat}
> ***
> *** 1128,1140
> String appendData = ser.asString(update);
> for (List chunkedIds : Lists.partition(ids, CHUNKSIZE))
> {
> Set seenQueryContext = Collections.emptySet();
> if (collection == Collection.NODES) {
> - for (String id : chunkedIds) {
> - nodesCache.invalidate(id);
> - }
> -
> // keep concurrently running queries from updating
> // the cache entry for this key
> seenQueryContext = new HashSet();
> --- 1128,1137
> String appendData = ser.asString(update);
> for (List chunkedIds : Lists.partition(ids, CHUNKSIZE))
> {
> +
> Set seenQueryContext = Collections.emptySet();
> if (collection == Collection.NODES) {
> // keep concurrently running queries from updating
> // the cache entry for this key
> seenQueryContext = new HashSet();
> ***
> *** 1142,1147
> --- 1139,1147
> qc.addKeys(chunkedIds);
> seenQueryContext.add(qc);
> }
> + for (String id : chunkedIds) {
> + nodesCache.invalidate(id);
> + }
> }
> {noformat}
> and seems to be caused by the change for OAK-3657.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-4707) Fix cold standby integration tests
[ https://issues.apache.org/jira/browse/OAK-4707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Mari resolved OAK-4707. - Resolution: Fixed Assignee: Francesco Mari (was: Andrei Dulceanu) Fix Version/s: (was: Segment Tar 0.0.20) Segment Tar 0.0.12 Resolving this issue as every sub-task and blocker issue is resolved. > Fix cold standby integration tests > -- > > Key: OAK-4707 > URL: https://issues.apache.org/jira/browse/OAK-4707 > Project: Jackrabbit Oak > Issue Type: Task > Components: segment-tar >Reporter: Francesco Mari >Assignee: Francesco Mari > Fix For: Segment Tar 0.0.12 > > > Cold standby integration tests should be passing against the code in > oak-segment-tar. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-4735) Fix unit tests in DataStoreTestBase
[
https://issues.apache.org/jira/browse/OAK-4735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu resolved OAK-4735.
--
Resolution: Fixed
Marking this as fixed, since there was only 1 failure in ~ 25 builds on Jenkins
> Fix unit tests in DataStoreTestBase
> ---
>
> Key: OAK-4735
> URL: https://issues.apache.org/jira/browse/OAK-4735
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
> Fix For: Segment Tar 0.0.12
>
> Attachments: OAK-4735-01.patch
>
>
> Currently failing tests (8/8):
> * {{testSync()}}
> * {{testProxySkippedBytes()}}
> * {{testProxySkippedBytesIntermediateChange()}}
> * {{testProxyFlippedStartByte()}}
> * {{testProxyFlippedIntermediateByte()}}
> * {{testProxyFlippedIntermediateByte2()}}
> * {{testProxyFlippedIntermediateByteChange()}}
> * {{testProxyFlippedIntermediateByteChange2()}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4815) ReferenceIndex slowdown due to OAK-3403
[ https://issues.apache.org/jira/browse/OAK-4815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-4815: Component/s: query > ReferenceIndex slowdown due to OAK-3403 > --- > > Key: OAK-4815 > URL: https://issues.apache.org/jira/browse/OAK-4815 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.5.11 > > > In OAK-3403, a lookup using the ReferenceIndex now uses "new FilterImpl()", > which in turn uses "new QueryEngineSettings()". And this is slow, because it > is an AnnotatedStandardMBean, and instantiating such an object is quite slow. > (Actually it is also wrong, because the configured query engine settings are > not used in that case.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4815) ReferenceIndex slowdown due to OAK-3403
[ https://issues.apache.org/jira/browse/OAK-4815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-4815: Fix Version/s: 1.5.11 > ReferenceIndex slowdown due to OAK-3403 > --- > > Key: OAK-4815 > URL: https://issues.apache.org/jira/browse/OAK-4815 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.5.11 > > > In OAK-3403, a lookup using the ReferenceIndex now uses "new FilterImpl()", > which in turn uses "new QueryEngineSettings()". And this is slow, because it > is an AnnotatedStandardMBean, and instantiating such an object is quite slow. > (Actually it is also wrong, because the configured query engine settings are > not used in that case.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-4815) ReferenceIndex slowdown due to OAK-3403
Thomas Mueller created OAK-4815: --- Summary: ReferenceIndex slowdown due to OAK-3403 Key: OAK-4815 URL: https://issues.apache.org/jira/browse/OAK-4815 Project: Jackrabbit Oak Issue Type: Improvement Reporter: Thomas Mueller Assignee: Thomas Mueller In OAK-3403, a lookup using the ReferenceIndex now uses "new FilterImpl()", which in turn uses "new QueryEngineSettings()". And this is slow, because it is an AnnotatedStandardMBean, and instantiating such an object is quite slow. (Actually it is also wrong, because the configured query engine settings are not used in that case.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4774) Check usage of DocumentStoreException in MongoDocumentStore
[ https://issues.apache.org/jira/browse/OAK-4774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-4774: Labels: candidate_oak_1_0 candidate_oak_1_2 candidate_oak_1_4 resilience (was: resilience) > Check usage of DocumentStoreException in MongoDocumentStore > --- > > Key: OAK-4774 > URL: https://issues.apache.org/jira/browse/OAK-4774 > Project: Jackrabbit Oak > Issue Type: Task > Components: core, mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4, > resilience > Fix For: 1.6, 1.5.11 > > > With OAK-4771 the usage of DocumentStoreException was clarified in the > DocumentStore interface. The purpose of this task is to check usage of the > DocumentStoreException in MongoDocumentStore and make sure MongoDB Java > driver specific exceptions are handled consistently and wrapped in a > DocumentStoreException. At the same time, cache consistency needs to be > checked as well in case of a driver exception. E.g. invalidate if necessary. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-4806) Remove usage of Tree in LuceneIndexEditor
[
https://issues.apache.org/jira/browse/OAK-4806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved OAK-4806.
--
Resolution: Fixed
Done with 1761003
> Remove usage of Tree in LuceneIndexEditor
> -
>
> Key: OAK-4806
> URL: https://issues.apache.org/jira/browse/OAK-4806
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Labels: performance
> Fix For: 1.6
>
>
> {{LuceneIndexEditor}} currently creates 2 tree instances for determining
> IndexRule. [~ianeboston] highlighted this on list [1] and this is something
> which we should avoid and remove usage of Tree api
> This was earlier done so as to simplify future support for conditional rules
> (OAK-2281) which might need access to ancestor which is not possible with
> NodeState api. As that is not going to be done so we can get rid of Tree
> construction in the editor.
> [1]
> https://lists.apache.org/thread.html/7d51b45296f5801c3b510a30a4847ce297707fb4e0d4c2cefe19be62@%3Coak-dev.jackrabbit.apache.org%3E
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4806) Remove usage of Tree in LuceneIndexEditor
[
https://issues.apache.org/jira/browse/OAK-4806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-4806:
-
Fix Version/s: 1.5.11
> Remove usage of Tree in LuceneIndexEditor
> -
>
> Key: OAK-4806
> URL: https://issues.apache.org/jira/browse/OAK-4806
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Labels: performance
> Fix For: 1.6, 1.5.11
>
>
> {{LuceneIndexEditor}} currently creates 2 tree instances for determining
> IndexRule. [~ianeboston] highlighted this on list [1] and this is something
> which we should avoid and remove usage of Tree api
> This was earlier done so as to simplify future support for conditional rules
> (OAK-2281) which might need access to ancestor which is not possible with
> NodeState api. As that is not going to be done so we can get rid of Tree
> construction in the editor.
> [1]
> https://lists.apache.org/thread.html/7d51b45296f5801c3b510a30a4847ce297707fb4e0d4c2cefe19be62@%3Coak-dev.jackrabbit.apache.org%3E
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
