[jira] [Updated] (OAK-5025) Speed up ACE node name generation
[
https://issues.apache.org/jira/browse/OAK-5025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex COLLIGNON updated OAK-5025:
Attachment: OAK-5025-ACE-random-nodename-generation.patch
OAK-5025-ACE-name-generation-benchmarks.patch
Attaching a patch using a (pseudo-)random generator to create the ACE nodename.
This strategy avoids the children traversal.
I am also attaching a new benchmark.
> Speed up ACE node name generation
> -
>
> Key: OAK-5025
> URL: https://issues.apache.org/jira/browse/OAK-5025
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.5.12
>Reporter: Alex COLLIGNON
>Assignee: angela
>Priority: Minor
> Labels: performance
> Fix For: 1.6
>
> Attachments: OAK-5025-ACE-name-generation-benchmarks.patch,
> OAK-5025-ACE-random-nodename-generation.patch
>
>
> Currently,
> {{o.a.j.oak.security.authorization.accesscontrol.Util#generateAceName}} is
> traversing all the existing ACE of a certain node in order to generate
> continuous numbering (allow0, allow1, allow2).
> While that certainly helps to produce human readable names, it represents
> quite a performance bottleneck when the number of existing ACE starts to grow.
> Since the naming is a pure implementation detail, my proposal is to keep the
> continuous numbering for the first hundreds of nodes and then use a random
> number to generate unique names in a faster fashion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2906) test failures for oak-auth-ldap on Windows
[ https://issues.apache.org/jira/browse/OAK-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-2906: Labels: test (was: ) > test failures for oak-auth-ldap on Windows > -- > > Key: OAK-2906 > URL: https://issues.apache.org/jira/browse/OAK-2906 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-ldap >Affects Versions: 1.5.13 >Reporter: Julian Reschke > Labels: test > Fix For: 1.8 > > > testAuthenticateValidateTrueFalse(org.apache.jackrabbit.oak.security.authentication.ldap.LdapProviderTest) > Time elapsed: 0.01 sec <<< ERROR! > java.io.IOException: Unable to delete file: > target\apacheds\cache\5c3940f5-2ddb-4d47-8254-8b2266c1a684\ou=system.data > at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:2279) > at org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:1653) > at > org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1535) > at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:2270) > at org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:1653) > at > org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1535) > at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:2270) > at org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:1653) > at > org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1535) > at > org.apache.jackrabbit.oak.security.authentication.ldap.AbstractServer.doDelete(AbstractServer.java:264) > at > org.apache.jackrabbit.oak.security.authentication.ldap.AbstractServer.setUp(AbstractServer.java:183) > at > org.apache.jackrabbit.oak.security.authentication.ldap.InternalLdapServer.setUp(InternalLdapServer.java:33) > etc... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2906) test failures for oak-auth-ldap on Windows
[ https://issues.apache.org/jira/browse/OAK-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15674380#comment-15674380 ] angela commented on OAK-2906: - thanks for checking again. so, let's keep it open and investigate after 1.6 > test failures for oak-auth-ldap on Windows > -- > > Key: OAK-2906 > URL: https://issues.apache.org/jira/browse/OAK-2906 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-ldap >Affects Versions: 1.5.13 >Reporter: Julian Reschke > Labels: test > Fix For: 1.8 > > > testAuthenticateValidateTrueFalse(org.apache.jackrabbit.oak.security.authentication.ldap.LdapProviderTest) > Time elapsed: 0.01 sec <<< ERROR! > java.io.IOException: Unable to delete file: > target\apacheds\cache\5c3940f5-2ddb-4d47-8254-8b2266c1a684\ou=system.data > at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:2279) > at org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:1653) > at > org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1535) > at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:2270) > at org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:1653) > at > org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1535) > at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:2270) > at org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:1653) > at > org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1535) > at > org.apache.jackrabbit.oak.security.authentication.ldap.AbstractServer.doDelete(AbstractServer.java:264) > at > org.apache.jackrabbit.oak.security.authentication.ldap.AbstractServer.setUp(AbstractServer.java:183) > at > org.apache.jackrabbit.oak.security.authentication.ldap.InternalLdapServer.setUp(InternalLdapServer.java:33) > etc... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2906) test failures for oak-auth-ldap on Windows
[ https://issues.apache.org/jira/browse/OAK-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-2906: Fix Version/s: 1.8 > test failures for oak-auth-ldap on Windows > -- > > Key: OAK-2906 > URL: https://issues.apache.org/jira/browse/OAK-2906 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-ldap >Affects Versions: 1.5.13 >Reporter: Julian Reschke > Labels: test > Fix For: 1.8 > > > testAuthenticateValidateTrueFalse(org.apache.jackrabbit.oak.security.authentication.ldap.LdapProviderTest) > Time elapsed: 0.01 sec <<< ERROR! > java.io.IOException: Unable to delete file: > target\apacheds\cache\5c3940f5-2ddb-4d47-8254-8b2266c1a684\ou=system.data > at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:2279) > at org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:1653) > at > org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1535) > at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:2270) > at org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:1653) > at > org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1535) > at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:2270) > at org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:1653) > at > org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1535) > at > org.apache.jackrabbit.oak.security.authentication.ldap.AbstractServer.doDelete(AbstractServer.java:264) > at > org.apache.jackrabbit.oak.security.authentication.ldap.AbstractServer.setUp(AbstractServer.java:183) > at > org.apache.jackrabbit.oak.security.authentication.ldap.InternalLdapServer.setUp(InternalLdapServer.java:33) > etc... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3328) checked-in state should only affect properties with OPV!=IGNORE
[
https://issues.apache.org/jira/browse/OAK-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15674325#comment-15674325
]
Marco Piovesana commented on OAK-3328:
--
Hi Marcel,
thanks for the hint. I did try to look at the patch and modify
_checkPrecondition_ method. I was able to modify the property but i still get
an error when trying to save the session.
It fails inside the class _VersionEditor_ because of this check:
{code:java}
public void propertyChanged(PropertyState before, PropertyState after)
throws CommitFailedException {
if(!this.isVersionable()) {
if(!this.isVersionProperty(after) && this.isReadOnly) {
throwCheckedIn("Cannot change property " + after.getName() + "
on checked in node");
}
{code}
do you know how can i check the OPV settings of this property (or its parent
node) to see if is set to "IGNORE"? Is that the right thing to do?
Marco.
> checked-in state should only affect properties with OPV!=IGNORE
> ---
>
> Key: OAK-3328
> URL: https://issues.apache.org/jira/browse/OAK-3328
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Reporter: Julian Reschke
>
> We currently (as of OAK-3310) protect all properties from changes when the
> node is checked-in. According to the spec
> (http://www.day.com/specs/jcr/2.0/15_Versioning.html#15.2.2%20Read-Only%20on%20Check-In),
> this should only be the case when on-parent-version is != "IGNORE".
> (It seems this doesn't have TCK coverage)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4940) Consider collecting grand-parent changes in ChangeSet
[
https://issues.apache.org/jira/browse/OAK-4940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated OAK-4940:
-
Attachment: OAK-4940.patch
Attaching [^OAK-4940.patch] which implements the following:
* adds a {{allNodeTypes}} set to the ChangeSet
* fixes {{parentNodeType}} to include before *and* after node types should the
node type ever changed (imv this is more correct than just taking the after).
* adjusted test cases
[~chetanm], can you pls have a quick look if this looks fine for you? I've now
chosen two separate sets (parent and all) as that allows for slightly more
precise filtering (and the set should still be small, so no large overhead
expected) - but if we want to accept the filtering-hit we could also have only
one set there.
> Consider collecting grand-parent changes in ChangeSet
> -
>
> Key: OAK-4940
> URL: https://issues.apache.org/jira/browse/OAK-4940
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: 1.6, 1.5.14
>
> Attachments: OAK-4940.patch
>
>
> At the moment the ChangeSet, which is populated by ChangeCollectorProvider (a
> Validator) during a commit, collects changed property names, as well as node
> name, node type and path of the parent (whereas _parent_ for a property
> change is its node, while for a node change is actually its parent).
> For improvements such as SLING-6163 it might be valuable to collect
> grand-parent changes (node name, node type and perhaps path) too. We could
> extend the ChangeSet with additional, explicit grand-parent sets (ie we
> should not mix them with the parent changes as that would lessen filtering
> rate)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3626) Provide bind credentials callback
[ https://issues.apache.org/jira/browse/OAK-3626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15674096#comment-15674096 ] Alex COLLIGNON commented on OAK-3626: - The implementation of RFC227 requires to upgrade a bunch of dependencies. AFAIK, we would need at least to handle internal builds of Felix Configadmin and SCR. That might already be troublesome. > Provide bind credentials callback > - > > Key: OAK-3626 > URL: https://issues.apache.org/jira/browse/OAK-3626 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: auth-ldap >Reporter: Tobias Bocanegra > > The ldap identity provider reads the admin bind credentials from the given > config which might originate from a un-encrypted source (eg. osgi config). > in order to facilitate secure provisioning of the bind credentials, the ldap > idp should offer some sort of credentials provider callback. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3328) checked-in state should only affect properties with OPV!=IGNORE
[ https://issues.apache.org/jira/browse/OAK-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15674072#comment-15674072 ] Marcel Reutegger commented on OAK-3328: --- So far there was no pressing need to fix this. The patch in OAK-3310 should give you a pretty good indication where the check would have to consider the OPV setting as well. > checked-in state should only affect properties with OPV!=IGNORE > --- > > Key: OAK-3328 > URL: https://issues.apache.org/jira/browse/OAK-3328 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Julian Reschke > > We currently (as of OAK-3310) protect all properties from changes when the > node is checked-in. According to the spec > (http://www.day.com/specs/jcr/2.0/15_Versioning.html#15.2.2%20Read-Only%20on%20Check-In), > this should only be the case when on-parent-version is != "IGNORE". > (It seems this doesn't have TCK coverage) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-3328) checked-in state should only affect properties with OPV!=IGNORE
[ https://issues.apache.org/jira/browse/OAK-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15674020#comment-15674020 ] Marco Piovesana edited comment on OAK-3328 at 11/17/16 3:44 PM: Hi all, i'm using oak to implement a functionality that relies on this behaviour. Is there any plan to resolve this bug in the near future? I also tried to find where to fix it, but I haven't been able to find a complete solution.. thanks, Marco. was (Author: iosonomarco): Hi all, i'm using oak to implement a functionality that relies on this behaviour. Is there any plan to resolve this bug in the near future? thanks, Marco. > checked-in state should only affect properties with OPV!=IGNORE > --- > > Key: OAK-3328 > URL: https://issues.apache.org/jira/browse/OAK-3328 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Julian Reschke > > We currently (as of OAK-3310) protect all properties from changes when the > node is checked-in. According to the spec > (http://www.day.com/specs/jcr/2.0/15_Versioning.html#15.2.2%20Read-Only%20on%20Check-In), > this should only be the case when on-parent-version is != "IGNORE". > (It seems this doesn't have TCK coverage) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-3328) checked-in state should only affect properties with OPV!=IGNORE
[ https://issues.apache.org/jira/browse/OAK-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15674020#comment-15674020 ] Marco Piovesana edited comment on OAK-3328 at 11/17/16 3:44 PM: Hi all, i'm using oak to implement a functionality that relies on this behaviour. Is there any plan to resolve this bug in the near future? I also tried to find how to fix it, but I haven't been able to find a complete solution.. thanks, Marco. was (Author: iosonomarco): Hi all, i'm using oak to implement a functionality that relies on this behaviour. Is there any plan to resolve this bug in the near future? I also tried to find where to fix it, but I haven't been able to find a complete solution.. thanks, Marco. > checked-in state should only affect properties with OPV!=IGNORE > --- > > Key: OAK-3328 > URL: https://issues.apache.org/jira/browse/OAK-3328 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Julian Reschke > > We currently (as of OAK-3310) protect all properties from changes when the > node is checked-in. According to the spec > (http://www.day.com/specs/jcr/2.0/15_Versioning.html#15.2.2%20Read-Only%20on%20Check-In), > this should only be the case when on-parent-version is != "IGNORE". > (It seems this doesn't have TCK coverage) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3328) checked-in state should only affect properties with OPV!=IGNORE
[ https://issues.apache.org/jira/browse/OAK-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15674020#comment-15674020 ] Marco Piovesana commented on OAK-3328: -- Hi all, i'm using oak to implement a functionality that relies on this behaviour. Is there any plan to resolve this bug in the near future? thanks, Marco. > checked-in state should only affect properties with OPV!=IGNORE > --- > > Key: OAK-3328 > URL: https://issues.apache.org/jira/browse/OAK-3328 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Julian Reschke > > We currently (as of OAK-3310) protect all properties from changes when the > node is checked-in. According to the spec > (http://www.day.com/specs/jcr/2.0/15_Versioning.html#15.2.2%20Read-Only%20on%20Check-In), > this should only be the case when on-parent-version is != "IGNORE". > (It seems this doesn't have TCK coverage) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (OAK-5125) The interface CacheValue.getMemory() should return long instead of int
[ https://issues.apache.org/jira/browse/OAK-5125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke reassigned OAK-5125: --- Assignee: Manfred Baedke > The interface CacheValue.getMemory() should return long instead of int > -- > > Key: OAK-5125 > URL: https://issues.apache.org/jira/browse/OAK-5125 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.0.34, 1.2.21, 1.5.13, 1.4.10 >Reporter: Manfred Baedke >Assignee: Manfred Baedke > > The interface method org.apache.jackrabbit.oak.cache.CacheValue.getMemory() > returns an int value. Obviously it should return a long value. This actually > breaks in real life when testing with huge repos and machines, since it's > used to measure the size of local diffs (e.g. a reindexing may diff the whole > repo against an empty root). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4096) Limit the number of times a LuceneResultRow based iterator get reset
[
https://issues.apache.org/jira/browse/OAK-4096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15673865#comment-15673865
]
Thomas Mueller commented on OAK-4096:
-
Not quite sure if I understand the requirement, should the query throw an
exception or simply stop returning results if the limit is reached? Proposed
patch (untested):
{noformat}
### Eclipse Workspace Patch 1.0
#P oak-lucene
Index:
src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LuceneIndex.java
===
---
src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LuceneIndex.java
(revision 1770130)
+++
src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LuceneIndex.java
(working copy)
@@ -164,6 +164,8 @@
static final int LUCENE_QUERY_BATCH_SIZE = 50;
static final boolean USE_PATH_RESTRICTION =
Boolean.getBoolean("oak.luceneUsePath");
+
+static final int MAX_RELOAD_COUNT =
Integer.getInteger("oak.luceneMaxReloadCount", 16);
protected final IndexTracker tracker;
@@ -289,6 +291,7 @@
private int nextBatchSize = LUCENE_QUERY_BATCH_SIZE;
private boolean noDocs = false;
private long lastSearchIndexerVersion;
+private int reloadCount;
@Override
protected LuceneResultRow computeNext() {
@@ -351,7 +354,7 @@
TopDocs docs;
long time = System.currentTimeMillis();
checkForIndexVersionChange(searcher);
-while (true) {
+while (reloadCount < MAX_RELOAD_COUNT) {
if (lastDoc != null) {
LOG.debug("loading the next {} entries for
query {}", nextBatchSize, query);
docs = searcher.searchAfter(lastDoc, query,
nextBatchSize);
@@ -457,9 +460,10 @@
private void checkForIndexVersionChange(IndexSearcher searcher) {
long currentVersion = LucenePropertyIndex.getVersion(searcher);
if (currentVersion != lastSearchIndexerVersion && lastDoc !=
null){
+reloadCount++;
lastDoc = null;
LOG.debug("Change in index version detected {} => {}.
Query would be performed without " +
-"offset", currentVersion,
lastSearchIndexerVersion);
+"offset; reload {}", currentVersion,
lastSearchIndexerVersion, reloadCount);
}
this.lastSearchIndexerVersion = currentVersion;
}
{noformat}
> Limit the number of times a LuceneResultRow based iterator get reset
>
>
> Key: OAK-4096
> URL: https://issues.apache.org/jira/browse/OAK-4096
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Thomas Mueller
>Priority: Minor
> Fix For: 1.6
>
>
> With changes done in OAK-2569 it can happen that the cursor returned by
> {{LucenePropertyIndex}} gets reset multiple times as the index gets updated
> for a long running query
> {noformat}
> 11697: 26.02.2016 16:12:16.296 *DEBUG* [qtp567069427-14229]
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndex ... took 3690 ms
> 47507: 26.02.2016 16:13:26.744 *DEBUG* [qtp567069427-14229]
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndex loading the next
> 12800 entries for query :fulltext:foo
> 47513: 26.02.2016 16:13:30.486 *DEBUG* [qtp567069427-14229]
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndex ... took 3742 ms
> 55832: 26.02.2016 16:15:43.693 *DEBUG* [qtp567069427-14229]
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndex loading the next
> 25600 entries for query :fulltext:foo
> 55835: 26.02.2016 16:15:51.261 *DEBUG* [qtp567069427-14229]
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndex ... took 7568 ms
> 59383: 26.02.2016 16:21:12.355 *DEBUG* [qtp567069427-14229]
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndex Change in index
> version detected 4186634 => 4186631. Query would be performed without offset
> 59384: 26.02.2016 16:21:12.355 *DEBUG* [qtp567069427-14229]
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndex loading the first
> 51200 entries for query :fulltext:foo
> {noformat}
> If the index continuously gets updated then such a query would never finish
> and would consume system resources. For such case we should enforce some
> limit
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5125) The interface CacheValue.getMemory() should return long instead of int
[ https://issues.apache.org/jira/browse/OAK-5125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-5125: Description: The interface method org.apache.jackrabbit.oak.cache.CacheValue.getMemory() returns an int value. Obviously it should return a long value. This actually breaks in real life when testing with huge repos and machines, since it's used to measure the size of local diffs (e.g. a reindexing may diff the whole repo against an empty root). > The interface CacheValue.getMemory() should return long instead of int > -- > > Key: OAK-5125 > URL: https://issues.apache.org/jira/browse/OAK-5125 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.0.34, 1.2.21, 1.5.13, 1.4.10 >Reporter: Manfred Baedke > > The interface method org.apache.jackrabbit.oak.cache.CacheValue.getMemory() > returns an int value. Obviously it should return a long value. This actually > breaks in real life when testing with huge repos and machines, since it's > used to measure the size of local diffs (e.g. a reindexing may diff the whole > repo against an empty root). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-4742) Improve FileStoreStatsMBean
[
https://issues.apache.org/jira/browse/OAK-4742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15673841#comment-15673841
]
Andrei Dulceanu edited comment on OAK-4742 at 11/17/16 2:19 PM:
I decided to move everything into a new {{SegmentNodeStoreStats}} which
implements both {{SegmentNodeStoreStatsMBean}} and {{SegmentNodeStoreMonitor}}
interfaces, similarly to what we already have for {{FileStore}}.
[~frm], could you take a look at the attached patch?
/cc [~mduerig], [~alexparvulescu]
was (Author: dulceanu):
I decided to move everything into a new {{SegmentNodeStoreStats}} which
implements both {{SegmentNodeStoreStatsMBean}} and {{SegmentNodeStoreMonitor}}
interfaces, similarly to what we already have for {{FileStore}}.
[~frm], could you take a look at the attached patch?
/cc [~mduerig]
> Improve FileStoreStatsMBean
> ---
>
> Key: OAK-4742
> URL: https://issues.apache.org/jira/browse/OAK-4742
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Andrei Dulceanu
> Labels: monitoring
> Fix For: 1.6, 1.5.14
>
> Attachments: CommitTime.png, OAK-4742-01.patch
>
>
> We should add further data to that MBean (if feasible):
> * Number of commits
> * Number of commits queuing (blocked on the commit semaphore)
> * Percentiles of commit times (exclude queueing time)
> * Percentiles of commit queueing times
> * Last gc run / size before gc and after gc / time gc took broken down into
> the various phases
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (OAK-4742) Improve FileStoreStatsMBean
[ https://issues.apache.org/jira/browse/OAK-4742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Mari reassigned OAK-4742: --- Assignee: Francesco Mari (was: Andrei Dulceanu) > Improve FileStoreStatsMBean > --- > > Key: OAK-4742 > URL: https://issues.apache.org/jira/browse/OAK-4742 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar >Reporter: Michael Dürig >Assignee: Francesco Mari > Labels: monitoring > Fix For: 1.6, 1.5.14 > > Attachments: CommitTime.png, OAK-4742-01.patch > > > We should add further data to that MBean (if feasible): > * Number of commits > * Number of commits queuing (blocked on the commit semaphore) > * Percentiles of commit times (exclude queueing time) > * Percentiles of commit queueing times > * Last gc run / size before gc and after gc / time gc took broken down into > the various phases -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4742) Improve FileStoreStatsMBean
[
https://issues.apache.org/jira/browse/OAK-4742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-4742:
-
Attachment: OAK-4742-01.patch
I decided to move everything into a new {{SegmentNodeStoreStats}} which
implements both {{SegmentNodeStoreStatsMBean}} and {{SegmentNodeStoreMonitor}}
interfaces, similarly to what we already have for {{FileStore}}.
[~frm], could you take a look at the attached patch?
/cc [~mduerig]
> Improve FileStoreStatsMBean
> ---
>
> Key: OAK-4742
> URL: https://issues.apache.org/jira/browse/OAK-4742
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Andrei Dulceanu
> Labels: monitoring
> Fix For: 1.6, 1.5.14
>
> Attachments: CommitTime.png, OAK-4742-01.patch
>
>
> We should add further data to that MBean (if feasible):
> * Number of commits
> * Number of commits queuing (blocked on the commit semaphore)
> * Percentiles of commit times (exclude queueing time)
> * Percentiles of commit queueing times
> * Last gc run / size before gc and after gc / time gc took broken down into
> the various phases
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-4742) Improve FileStoreStatsMBean
[
https://issues.apache.org/jira/browse/OAK-4742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15673561#comment-15673561
]
Andrei Dulceanu edited comment on OAK-4742 at 11/17/16 2:16 PM:
[~mduerig], looking at the {{COMMIT_TIME}} metric, does it still make sense to
have the percentiles stuff? I guess it provides by default most of the things,
unless one doesn't need something very special. If that is the case, it's easy
to come up with a solution. Let me know.
was (Author: dulceanu):
[~mduerig]rig, looking at the {{COMMIT_TIME}} metric, does it still make sense
to have the percentiles stuff? I guess it provides by default most of the
things, unless one doesn't need something very special. If that is the case,
it's easy to come up with a solution. Let me know.
> Improve FileStoreStatsMBean
> ---
>
> Key: OAK-4742
> URL: https://issues.apache.org/jira/browse/OAK-4742
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Andrei Dulceanu
> Labels: monitoring
> Fix For: 1.6, 1.5.14
>
> Attachments: CommitTime.png
>
>
> We should add further data to that MBean (if feasible):
> * Number of commits
> * Number of commits queuing (blocked on the commit semaphore)
> * Percentiles of commit times (exclude queueing time)
> * Percentiles of commit queueing times
> * Last gc run / size before gc and after gc / time gc took broken down into
> the various phases
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-5125) The interface CacheValue.getMemory() should return long instead of int
Manfred Baedke created OAK-5125: --- Summary: The interface CacheValue.getMemory() should return long instead of int Key: OAK-5125 URL: https://issues.apache.org/jira/browse/OAK-5125 Project: Jackrabbit Oak Issue Type: Bug Components: core Affects Versions: 1.4.10, 1.5.13, 1.2.21, 1.0.34 Reporter: Manfred Baedke -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-5124) How do i include jackrabbit oak as a dependency inside a build.gradle file? And then use it in your project?
Charles Grossman created OAK-5124:
-
Summary: How do i include jackrabbit oak as a dependency inside a
build.gradle file? And then use it in your project?
Key: OAK-5124
URL: https://issues.apache.org/jira/browse/OAK-5124
Project: Jackrabbit Oak
Issue Type: Documentation
Components: examples
Affects Versions: 1.4.10
Reporter: Charles Grossman
Priority: Minor
I've tried a few different things like
buildscript {
repositories {
jcenter()
mavenCentral()
}
dependencies {
classpath 'org.apache.jackrabbit:oak-jcr:1.0.0'
classpath 'javax.jcr:jcr:2.0'
}
}
//these fail
apply plugin: 'org.apache.jackrabbit:oak-jcr:1.0.0'
apply plugin: 'javax.jcr:jcr:2.0'
repositories {
jcenter()
mavenCentral()
}
but not really sure if this is the right idea at all.
Does anyone have some github examples or have done any work with Gradle and
jackrabbit Oak?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3219) Lucene IndexPlanner should also account for number of property constraints evaluated while giving cost estimation
[
https://issues.apache.org/jira/browse/OAK-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-3219:
Description:
Currently the cost returned by Lucene index is a function of number of indexed
documents present in the index. If the number of indexed entries are high then
it might reduce chances of this index getting selected if some property index
also support of the property constraint.
{noformat}
/jcr:root/content/freestyle-cms/customers//element(*, cq:Page)
[(jcr:content/@title = 'm' or jcr:like(jcr:content/@title, 'm%'))
and jcr:content/@sling:resourceType = '/components/page/customer’]
{noformat}
Consider above query with following index definition
* A property index on resourceType
* A Lucene index for cq:Page with properties {{jcr:content/title}},
{{jcr:content/sling:resourceType}} indexed and also path restriction evaluation
enabled
Now what the two indexes can help in
# Property index
## Path restriction
## Property restriction on {{sling:resourceType}}
# Lucene index
## NodeType restriction
## Property restriction on {{sling:resourceType}}
## Property restriction on {{title}}
## Path restriction
Now cost estimate currently works like this
* Property index - {{f(indexedValueEstimate, estimateOfNodesUnderGivenPath)}}
** indexedValueEstimate - For 'sling:resourceType=foo' its the approximate
count for nodes having that as 'foo'
** estimateOfNodesUnderGivenPath - Its derived from an approximate estimation
of nodes present under given path
* Lucene Index - {{f(totalIndexedEntries)}}
As cost of Lucene is too simple it does not reflect the reality. Following 2
changes can be done to make it better
* Given that Lucene index can handle multiple constraints compared (4) to
property index (2), the cost estimate returned by it should also reflect this
state. This can be done by setting costPerEntry to 1/(no of property
restriction evaluated)
* Get the count for queried property value - This is similar to what
PropertyIndex does and assumes that Lucene can provide that information in O(1)
cost. In case of multiple supported property restriction this can be minima of
all
was:
Currently the cost returned by Lucene index is a function of number of indexed
documents present in the index. If the number of indexed entries are high then
it might reduce chances of this index getting selected if some property index
also support of the property constraint.
{noformat}
/jcr:root/content/freestyle-cms/customers//element(*,
cq:Page)[(jcr:content/@title = 'm' or jcr:like(jcr:content/@title, 'm%')) and
jcr:content/@sling:resourceType = '/components/page/customer’]
{noformat}
Consider above query with following index definition
* A property index on resourceType
* A Lucene index for cq:Page with properties {{jcr:content/title}},
{{jcr:content/sling:resourceType}} indexed and also path restriction evaluation
enabled
Now what the two indexes can help in
# Property index
## Path restriction
## Property restriction on {{sling:resourceType}}
# Lucene index
## NodeType restriction
## Property restriction on {{sling:resourceType}}
## Property restriction on {{title}}
## Path restriction
Now cost estimate currently works like this
* Property index - {{f(indexedValueEstimate, estimateOfNodesUnderGivenPath)}}
** indexedValueEstimate - For 'sling:resourceType=foo' its the approximate
count for nodes having that as 'foo'
** estimateOfNodesUnderGivenPath - Its derived from an approximate estimation
of nodes present under given path
* Lucene Index - {{f(totalIndexedEntries)}}
As cost of Lucene is too simple it does not reflect the reality. Following 2
changes can be done to make it better
* Given that Lucene index can handle multiple constraints compared (4) to
property index (2), the cost estimate returned by it should also reflect this
state. This can be done by setting costPerEntry to 1/(no of property
restriction evaluated)
* Get the count for queried property value - This is similar to what
PropertyIndex does and assumes that Lucene can provide that information in O(1)
cost. In case of multiple supported property restriction this can be minima of
all
> Lucene IndexPlanner should also account for number of property constraints
> evaluated while giving cost estimation
> -
>
> Key: OAK-3219
> URL: https://issues.apache.org/jira/browse/OAK-3219
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Thomas Mueller
>Priority: Minor
> Labels: performance
> Fix For: 1.6
>
>
> Currently the cost returned by Lucene index is a function of number of
> indexed documents present in the index. If the number of
[jira] [Commented] (OAK-4602) IndexOutOfBoundsException when sorting by jcr:score + field
[
https://issues.apache.org/jira/browse/OAK-4602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15673816#comment-15673816
]
Thomas Mueller commented on OAK-4602:
-
It only happens if the sort order includes "jcr:score", plus at least one field
that has an ordered index on that field.
> IndexOutOfBoundsException when sorting by jcr:score + field
> ---
>
> Key: OAK-4602
> URL: https://issues.apache.org/jira/browse/OAK-4602
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.4.1
> Environment: AEM 6.1, 6.2
>Reporter: Sham
>Assignee: Thomas Mueller
> Fix For: 1.6, 1.5.14
>
>
> The quert written in jackrabbit sort by not working with oak. Samples order
> by which fails is [0] & stack trace at [2]. If I change the sort [1] it
> works & issue reproducible on any oak branch also, Additional This happens
> only with custom index definition. The exact query & index definition at
> [3].
> [0]
> {noformat}
> order by @jcr:score descending, post/@pubDate descending
> order by @jcr:score,post/@pubDate descending
> {noformat}
> [1]
> {noformat}
> order by post/@pubDate descending,@jcr:score descending
> {noformat}
> [2]
> {noformat}
> java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
> at java.util.ArrayList.rangeCheck(ArrayList.java:653)
> at java.util.ArrayList.get(ArrayList.java:429)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexPlanner$PlanResult.getOrderedProperty(IndexPlanner.java:540)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.getSort(LucenePropertyIndex.java:605)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.query(LucenePropertyIndex.java:281)
> at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.execute(SelectorImpl.java:329)
> at
> org.apache.jackrabbit.oak.query.QueryImpl$RowIterator.fetchNext(QueryImpl.java:769)
> at
> org.apache.jackrabbit.oak.query.QueryImpl$RowIterator.hasNext(QueryImpl.java:798)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.init(FilterIterators.java:203)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.hasNext(FilterIterators.java:237)
> at com.google.common.collect.Iterators$5.hasNext(Iterators.java:542)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.fetchNext(FilterIterators.java:137)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.hasNext(FilterIterators.java:151)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.init(FilterIterators.java:203)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.hasNext(FilterIterators.java:237)
> at com.google.common.collect.Iterators$5.hasNext(Iterators.java:542)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.fetchNext(FilterIterators.java:137)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.hasNext(FilterIterators.java:151)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.init(FilterIterators.java:203)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.hasNext(FilterIterators.java:237)
> at com.google.common.collect.Iterators$5.hasNext(Iterators.java:542)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.fetchNext(FilterIterators.java:137)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.hasNext(FilterIterators.java:151)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.init(FilterIterators.java:203)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.hasNext(FilterIterators.java:237)
> at com.google.common.collect.Iterators$5.hasNext(Iterators.java:542)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.fetchNext(FilterIterators.java:137)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.hasNext(FilterIterators.java:151)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.init(FilterIterators.java:203)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.hasNext(FilterIterators.java:237)
> at com.google.common.collect.Iterators$5.hasNext(Iterators.java:542)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.fetchNext(FilterIterators.java:137)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.hasNext(FilterIterators.java:151)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.init(FilterIterators.java:203)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.hasNext(FilterIterators.java:237)
> at com.google.common.collect.Iterators$5.hasNext(Iterators.java:542)
> at
>
[jira] [Resolved] (OAK-4602) IndexOutOfBoundsException when sorting by jcr:score + field
[
https://issues.apache.org/jira/browse/OAK-4602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller resolved OAK-4602.
-
Resolution: Fixed
http://svn.apache.org/r1770195 (trunk)
> IndexOutOfBoundsException when sorting by jcr:score + field
> ---
>
> Key: OAK-4602
> URL: https://issues.apache.org/jira/browse/OAK-4602
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.4.1
> Environment: AEM 6.1, 6.2
>Reporter: Sham
>Assignee: Thomas Mueller
> Fix For: 1.6, 1.5.14
>
>
> The quert written in jackrabbit sort by not working with oak. Samples order
> by which fails is [0] & stack trace at [2]. If I change the sort [1] it
> works & issue reproducible on any oak branch also, Additional This happens
> only with custom index definition. The exact query & index definition at
> [3].
> [0]
> {noformat}
> order by @jcr:score descending, post/@pubDate descending
> order by @jcr:score,post/@pubDate descending
> {noformat}
> [1]
> {noformat}
> order by post/@pubDate descending,@jcr:score descending
> {noformat}
> [2]
> {noformat}
> java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
> at java.util.ArrayList.rangeCheck(ArrayList.java:653)
> at java.util.ArrayList.get(ArrayList.java:429)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexPlanner$PlanResult.getOrderedProperty(IndexPlanner.java:540)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.getSort(LucenePropertyIndex.java:605)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.query(LucenePropertyIndex.java:281)
> at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.execute(SelectorImpl.java:329)
> at
> org.apache.jackrabbit.oak.query.QueryImpl$RowIterator.fetchNext(QueryImpl.java:769)
> at
> org.apache.jackrabbit.oak.query.QueryImpl$RowIterator.hasNext(QueryImpl.java:798)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.init(FilterIterators.java:203)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.hasNext(FilterIterators.java:237)
> at com.google.common.collect.Iterators$5.hasNext(Iterators.java:542)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.fetchNext(FilterIterators.java:137)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.hasNext(FilterIterators.java:151)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.init(FilterIterators.java:203)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.hasNext(FilterIterators.java:237)
> at com.google.common.collect.Iterators$5.hasNext(Iterators.java:542)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.fetchNext(FilterIterators.java:137)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.hasNext(FilterIterators.java:151)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.init(FilterIterators.java:203)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.hasNext(FilterIterators.java:237)
> at com.google.common.collect.Iterators$5.hasNext(Iterators.java:542)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.fetchNext(FilterIterators.java:137)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.hasNext(FilterIterators.java:151)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.init(FilterIterators.java:203)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.hasNext(FilterIterators.java:237)
> at com.google.common.collect.Iterators$5.hasNext(Iterators.java:542)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.fetchNext(FilterIterators.java:137)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.hasNext(FilterIterators.java:151)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.init(FilterIterators.java:203)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.hasNext(FilterIterators.java:237)
> at com.google.common.collect.Iterators$5.hasNext(Iterators.java:542)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.fetchNext(FilterIterators.java:137)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.hasNext(FilterIterators.java:151)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.init(FilterIterators.java:203)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.hasNext(FilterIterators.java:237)
> at com.google.common.collect.Iterators$5.hasNext(Iterators.java:542)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.fetchNext(FilterIterators.java:137)
> at
>
[jira] [Updated] (OAK-4602) IndexOutOfBoundsException when sorting by jcr:score + field
[
https://issues.apache.org/jira/browse/OAK-4602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-4602:
Fix Version/s: 1.5.14
> IndexOutOfBoundsException when sorting by jcr:score + field
> ---
>
> Key: OAK-4602
> URL: https://issues.apache.org/jira/browse/OAK-4602
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.4.1
> Environment: AEM 6.1, 6.2
>Reporter: Sham
>Assignee: Thomas Mueller
> Fix For: 1.6, 1.5.14
>
>
> The quert written in jackrabbit sort by not working with oak. Samples order
> by which fails is [0] & stack trace at [2]. If I change the sort [1] it
> works & issue reproducible on any oak branch also, Additional This happens
> only with custom index definition. The exact query & index definition at
> [3].
> [0]
> {noformat}
> order by @jcr:score descending, post/@pubDate descending
> order by @jcr:score,post/@pubDate descending
> {noformat}
> [1]
> {noformat}
> order by post/@pubDate descending,@jcr:score descending
> {noformat}
> [2]
> {noformat}
> java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
> at java.util.ArrayList.rangeCheck(ArrayList.java:653)
> at java.util.ArrayList.get(ArrayList.java:429)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexPlanner$PlanResult.getOrderedProperty(IndexPlanner.java:540)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.getSort(LucenePropertyIndex.java:605)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.query(LucenePropertyIndex.java:281)
> at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.execute(SelectorImpl.java:329)
> at
> org.apache.jackrabbit.oak.query.QueryImpl$RowIterator.fetchNext(QueryImpl.java:769)
> at
> org.apache.jackrabbit.oak.query.QueryImpl$RowIterator.hasNext(QueryImpl.java:798)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.init(FilterIterators.java:203)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.hasNext(FilterIterators.java:237)
> at com.google.common.collect.Iterators$5.hasNext(Iterators.java:542)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.fetchNext(FilterIterators.java:137)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.hasNext(FilterIterators.java:151)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.init(FilterIterators.java:203)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.hasNext(FilterIterators.java:237)
> at com.google.common.collect.Iterators$5.hasNext(Iterators.java:542)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.fetchNext(FilterIterators.java:137)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.hasNext(FilterIterators.java:151)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.init(FilterIterators.java:203)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.hasNext(FilterIterators.java:237)
> at com.google.common.collect.Iterators$5.hasNext(Iterators.java:542)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.fetchNext(FilterIterators.java:137)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.hasNext(FilterIterators.java:151)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.init(FilterIterators.java:203)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.hasNext(FilterIterators.java:237)
> at com.google.common.collect.Iterators$5.hasNext(Iterators.java:542)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.fetchNext(FilterIterators.java:137)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.hasNext(FilterIterators.java:151)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.init(FilterIterators.java:203)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.hasNext(FilterIterators.java:237)
> at com.google.common.collect.Iterators$5.hasNext(Iterators.java:542)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.fetchNext(FilterIterators.java:137)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.hasNext(FilterIterators.java:151)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.init(FilterIterators.java:203)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.hasNext(FilterIterators.java:237)
> at com.google.common.collect.Iterators$5.hasNext(Iterators.java:542)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.fetchNext(FilterIterators.java:137)
> at
>
[jira] [Updated] (OAK-4602) IndexOutOfBoundsException when sorting by jcr:score + field
[
https://issues.apache.org/jira/browse/OAK-4602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-4602:
Summary: IndexOutOfBoundsException when sorting by jcr:score + field (was:
IndexOutOfBoundsException while sorting by multiple fields which has function
and property)
> IndexOutOfBoundsException when sorting by jcr:score + field
> ---
>
> Key: OAK-4602
> URL: https://issues.apache.org/jira/browse/OAK-4602
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.4.1
> Environment: AEM 6.1, 6.2
>Reporter: Sham
>Assignee: Thomas Mueller
> Fix For: 1.6
>
>
> The quert written in jackrabbit sort by not working with oak. Samples order
> by which fails is [0] & stack trace at [2]. If I change the sort [1] it
> works & issue reproducible on any oak branch also, Additional This happens
> only with custom index definition. The exact query & index definition at
> [3].
> [0]
> {noformat}
> order by @jcr:score descending, post/@pubDate descending
> order by @jcr:score,post/@pubDate descending
> {noformat}
> [1]
> {noformat}
> order by post/@pubDate descending,@jcr:score descending
> {noformat}
> [2]
> {noformat}
> java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
> at java.util.ArrayList.rangeCheck(ArrayList.java:653)
> at java.util.ArrayList.get(ArrayList.java:429)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexPlanner$PlanResult.getOrderedProperty(IndexPlanner.java:540)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.getSort(LucenePropertyIndex.java:605)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.query(LucenePropertyIndex.java:281)
> at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.execute(SelectorImpl.java:329)
> at
> org.apache.jackrabbit.oak.query.QueryImpl$RowIterator.fetchNext(QueryImpl.java:769)
> at
> org.apache.jackrabbit.oak.query.QueryImpl$RowIterator.hasNext(QueryImpl.java:798)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.init(FilterIterators.java:203)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.hasNext(FilterIterators.java:237)
> at com.google.common.collect.Iterators$5.hasNext(Iterators.java:542)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.fetchNext(FilterIterators.java:137)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.hasNext(FilterIterators.java:151)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.init(FilterIterators.java:203)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.hasNext(FilterIterators.java:237)
> at com.google.common.collect.Iterators$5.hasNext(Iterators.java:542)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.fetchNext(FilterIterators.java:137)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.hasNext(FilterIterators.java:151)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.init(FilterIterators.java:203)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.hasNext(FilterIterators.java:237)
> at com.google.common.collect.Iterators$5.hasNext(Iterators.java:542)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.fetchNext(FilterIterators.java:137)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.hasNext(FilterIterators.java:151)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.init(FilterIterators.java:203)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.hasNext(FilterIterators.java:237)
> at com.google.common.collect.Iterators$5.hasNext(Iterators.java:542)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.fetchNext(FilterIterators.java:137)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.hasNext(FilterIterators.java:151)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.init(FilterIterators.java:203)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.hasNext(FilterIterators.java:237)
> at com.google.common.collect.Iterators$5.hasNext(Iterators.java:542)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.fetchNext(FilterIterators.java:137)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.hasNext(FilterIterators.java:151)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.init(FilterIterators.java:203)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.hasNext(FilterIterators.java:237)
> at com.google.common.collect.Iterators$5.hasNext(Iterators.java:542)
> at
>
[jira] [Resolved] (OAK-5123) Catch any exception in ChangeSetFilterImpl.excludes - and warn.
[ https://issues.apache.org/jira/browse/OAK-5123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Egli resolved OAK-5123. -- Resolution: Fixed Fix Version/s: 1.6 fixed in http://svn.apache.org/viewvc?rev=1770192=rev > Catch any exception in ChangeSetFilterImpl.excludes - and warn. > --- > > Key: OAK-5123 > URL: https://issues.apache.org/jira/browse/OAK-5123 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Affects Versions: 1.5.13 >Reporter: Stefan Egli >Assignee: Stefan Egli >Priority: Minor > Fix For: 1.6, 1.5.14 > > > OAK-5107 has unveiled a NPE in ChangeSetFilterImpl.excludes and has been > fixed. > To avoid running into any other such problem in ChangeSetFilterImpl.excludes > we should catch any type of exception there and warn. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-5123) Catch any exception in ChangeSetFilterImpl.excludes - and warn.
Stefan Egli created OAK-5123: Summary: Catch any exception in ChangeSetFilterImpl.excludes - and warn. Key: OAK-5123 URL: https://issues.apache.org/jira/browse/OAK-5123 Project: Jackrabbit Oak Issue Type: Improvement Components: core Affects Versions: 1.5.13 Reporter: Stefan Egli Assignee: Stefan Egli Priority: Minor Fix For: 1.5.14 OAK-5107 has unveiled a NPE in ChangeSetFilterImpl.excludes and has been fixed. To avoid running into any other such problem in ChangeSetFilterImpl.excludes we should catch any type of exception there and warn. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-5114) oak-segment-tar should declare embedded dependencies using compile scope
[
https://issues.apache.org/jira/browse/OAK-5114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu resolved OAK-5114.
--
Resolution: Fixed
Assignee: Alex Parvulescu (was: Francesco Mari)
Fix Version/s: 1.5.14
1.6
thanks for the patch Alex!
fixed with http://svn.apache.org/viewvc?rev=1770189=rev
> oak-segment-tar should declare embedded dependencies using compile scope
>
>
> Key: OAK-5114
> URL: https://issues.apache.org/jira/browse/OAK-5114
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: 1.5.13
>Reporter: Alexander Klimetschek
>Assignee: Alex Parvulescu
>Priority: Minor
> Fix For: 1.6, 1.5.14
>
> Attachments: OAK-5114.patch
>
>
> *Problem:* {{commons-math3}} and the {{netty-*}} dependencies in
> [oak-segment-tar are
> embedded|https://github.com/apache/jackrabbit-oak/blob/00c3caf8c359472d73857b325ab831b129d83511/oak-segment-tar/pom.xml#L48-L49]
> in the osgi bundle, but still declared with {{provided}}.
> This makes non-osgi downstream dependencies (such as a maven project using
> this for local tests) fail with
> {noformat}
> java.lang.NoClassDefFoundError:
> org/apache/commons/math3/stat/descriptive/DescriptiveStatistics
> at
> org.apache.jackrabbit.oak.segment.SegmentWriterBuilder.build(SegmentWriterBuilder.java:146)
> {noformat}
> because maven does not include transitive dependencies with provided scope in
> the (test) classpath, nor can it read embedded bundles in jar.
> *Solution:* They should get the default {{compile}} scope.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3626) Provide bind credentials callback
[ https://issues.apache.org/jira/browse/OAK-3626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15673715#comment-15673715 ] angela commented on OAK-3626: - my understanding based on the discussion with you and [~asanso] is that there is no need for extra code or internal releases within Oak. however, it might be worth updating the documentation and optionally adding some example stub to the exercise section in order to augment understanding of the holistic approach as possible with RFC 227 compared to an attempt to address the same type of issues with every single module defining some sort of sensitive OSGi configuration properties. > Provide bind credentials callback > - > > Key: OAK-3626 > URL: https://issues.apache.org/jira/browse/OAK-3626 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: auth-ldap >Reporter: Tobias Bocanegra > > The ldap identity provider reads the admin bind credentials from the given > config which might originate from a un-encrypted source (eg. osgi config). > in order to facilitate secure provisioning of the bind credentials, the ldap > idp should offer some sort of credentials provider callback. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4614) Collection of observation resilience issues
[ https://issues.apache.org/jira/browse/OAK-4614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15673604#comment-15673604 ] Marcel Reutegger commented on OAK-4614: --- I would move this one to 1.8. Splitting this epic up just scatters the information. > Collection of observation resilience issues > --- > > Key: OAK-4614 > URL: https://issues.apache.org/jira/browse/OAK-4614 > Project: Jackrabbit Oak > Issue Type: Epic > Components: core, documentmk, jcr >Reporter: Marcel Reutegger > Fix For: 1.6 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4742) Improve FileStoreStatsMBean
[
https://issues.apache.org/jira/browse/OAK-4742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-4742:
-
Attachment: CommitTime.png
[~mduerig]rig, looking at the {{COMMIT_TIME}} metric, does it still make sense
to have the percentiles stuff? I guess it provides by default most of the
things, unless one doesn't need something very special. If that is the case,
it's easy to come up with a solution. Let me know.
> Improve FileStoreStatsMBean
> ---
>
> Key: OAK-4742
> URL: https://issues.apache.org/jira/browse/OAK-4742
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Andrei Dulceanu
> Labels: monitoring
> Fix For: 1.6, 1.5.14
>
> Attachments: CommitTime.png
>
>
> We should add further data to that MBean (if feasible):
> * Number of commits
> * Number of commits queuing (blocked on the commit semaphore)
> * Percentiles of commit times (exclude queueing time)
> * Percentiles of commit queueing times
> * Last gc run / size before gc and after gc / time gc took broken down into
> the various phases
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4742) Improve FileStoreStatsMBean
[
https://issues.apache.org/jira/browse/OAK-4742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15673555#comment-15673555
]
Andrei Dulceanu commented on OAK-4742:
--
Another thing here, do you think it makes sense to have {{Number of commits
queuing}} as a {{MeterStats}} or {{CounterStats}} instance? For me the latter
seems more natural, but most of the time that would be zero, I guess, unless
there's some unnatural load.
> Improve FileStoreStatsMBean
> ---
>
> Key: OAK-4742
> URL: https://issues.apache.org/jira/browse/OAK-4742
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Andrei Dulceanu
> Labels: monitoring
> Fix For: 1.6, 1.5.14
>
>
> We should add further data to that MBean (if feasible):
> * Number of commits
> * Number of commits queuing (blocked on the commit semaphore)
> * Percentiles of commit times (exclude queueing time)
> * Percentiles of commit queueing times
> * Last gc run / size before gc and after gc / time gc took broken down into
> the various phases
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-5122) Exercise for Custom PermissionProvider
angela created OAK-5122: --- Summary: Exercise for Custom PermissionProvider Key: OAK-5122 URL: https://issues.apache.org/jira/browse/OAK-5122 Project: Jackrabbit Oak Issue Type: Technical task Components: exercise Reporter: angela Assignee: angela Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4602) IndexOutOfBoundsException while sorting by multiple fields which has function and property
[
https://issues.apache.org/jira/browse/OAK-4602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15673415#comment-15673415
]
Thomas Mueller commented on OAK-4602:
-
The problem seems to be that jcr:score is skipped, but the loop index doesn't
account for that. See LucenePropertyIndex: there are less sortedProperties than
sortOrder entries.
{noformat}
private static Sort getSort(IndexPlan plan) {
List sortOrder = plan.getSortOrder();
..
PlanResult planResult = getPlanResult(plan);
for (int i = 0; i < sortOrder.size(); i++) { <= loop over sortOrder
OrderEntry oe = sortOrder.get(i);
if (!isNativeSort(oe)) { <= jcr:score is skipped
PropertyDefinition pd = planResult.getOrderedProperty(i); <=
sortedProperties.get(index);
{noformat}
The best fix is probably to implement "isNativeSort" in a different way.
> IndexOutOfBoundsException while sorting by multiple fields which has function
> and property
> --
>
> Key: OAK-4602
> URL: https://issues.apache.org/jira/browse/OAK-4602
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.4.1
> Environment: AEM 6.1, 6.2
>Reporter: Sham
>Assignee: Thomas Mueller
> Fix For: 1.6
>
>
> The quert written in jackrabbit sort by not working with oak. Samples order
> by which fails is [0] & stack trace at [2]. If I change the sort [1] it
> works & issue reproducible on any oak branch also, Additional This happens
> only with custom index definition. The exact query & index definition at
> [3].
> [0]
> {noformat}
> order by @jcr:score descending, post/@pubDate descending
> order by @jcr:score,post/@pubDate descending
> {noformat}
> [1]
> {noformat}
> order by post/@pubDate descending,@jcr:score descending
> {noformat}
> [2]
> {noformat}
> java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
> at java.util.ArrayList.rangeCheck(ArrayList.java:653)
> at java.util.ArrayList.get(ArrayList.java:429)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexPlanner$PlanResult.getOrderedProperty(IndexPlanner.java:540)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.getSort(LucenePropertyIndex.java:605)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.query(LucenePropertyIndex.java:281)
> at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.execute(SelectorImpl.java:329)
> at
> org.apache.jackrabbit.oak.query.QueryImpl$RowIterator.fetchNext(QueryImpl.java:769)
> at
> org.apache.jackrabbit.oak.query.QueryImpl$RowIterator.hasNext(QueryImpl.java:798)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.init(FilterIterators.java:203)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.hasNext(FilterIterators.java:237)
> at com.google.common.collect.Iterators$5.hasNext(Iterators.java:542)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.fetchNext(FilterIterators.java:137)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.hasNext(FilterIterators.java:151)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.init(FilterIterators.java:203)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.hasNext(FilterIterators.java:237)
> at com.google.common.collect.Iterators$5.hasNext(Iterators.java:542)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.fetchNext(FilterIterators.java:137)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.hasNext(FilterIterators.java:151)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.init(FilterIterators.java:203)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.hasNext(FilterIterators.java:237)
> at com.google.common.collect.Iterators$5.hasNext(Iterators.java:542)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.fetchNext(FilterIterators.java:137)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.hasNext(FilterIterators.java:151)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.init(FilterIterators.java:203)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.hasNext(FilterIterators.java:237)
> at com.google.common.collect.Iterators$5.hasNext(Iterators.java:542)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.fetchNext(FilterIterators.java:137)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.hasNext(FilterIterators.java:151)
> at
> org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.init(FilterIterators.java:203)
> at
>
[jira] [Assigned] (OAK-3159) Extend documentation for SegmentNodeStoreService in http://jackrabbit.apache.org/oak/docs/osgi_config.html#SegmentNodeStore
[ https://issues.apache.org/jira/browse/OAK-3159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Mari reassigned OAK-3159: --- Assignee: Francesco Mari (was: Michael Dürig) > Extend documentation for SegmentNodeStoreService in > http://jackrabbit.apache.org/oak/docs/osgi_config.html#SegmentNodeStore > --- > > Key: OAK-3159 > URL: https://issues.apache.org/jira/browse/OAK-3159 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: doc, segment-tar >Reporter: Konrad Windszus >Assignee: Francesco Mari > Labels: documentation > Fix For: 1.6, 1.5.17 > > > Currently the documentation at > http://jackrabbit.apache.org/oak/docs/osgi_config.html#SegmentNodeStore only > documents the properties > # repository.home and > # tarmk.size > All the other properties like customBlobStore, tarmk.mode, are not > documented. Please extend that. Also it would be good, if the table could be > extended with what type is supported for the individual properties. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4602) IndexOutOfBoundsException while sorting by multiple fields which has function and property
[
https://issues.apache.org/jira/browse/OAK-4602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-4602:
Description:
The quert written in jackrabbit sort by not working with oak. Samples order
by which fails is [0] & stack trace at [2]. If I change the sort [1] it
works & issue reproducible on any oak branch also, Additional This happens
only with custom index definition. The exact query & index definition at [3].
[0]
{noformat}
order by @jcr:score descending, post/@pubDate descending
order by @jcr:score,post/@pubDate descending
{noformat}
[1]
{noformat}
order by post/@pubDate descending,@jcr:score descending
{noformat}
[2]
{noformat}
java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
at java.util.ArrayList.rangeCheck(ArrayList.java:653)
at java.util.ArrayList.get(ArrayList.java:429)
at
org.apache.jackrabbit.oak.plugins.index.lucene.IndexPlanner$PlanResult.getOrderedProperty(IndexPlanner.java:540)
at
org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.getSort(LucenePropertyIndex.java:605)
at
org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.query(LucenePropertyIndex.java:281)
at
org.apache.jackrabbit.oak.query.ast.SelectorImpl.execute(SelectorImpl.java:329)
at
org.apache.jackrabbit.oak.query.QueryImpl$RowIterator.fetchNext(QueryImpl.java:769)
at
org.apache.jackrabbit.oak.query.QueryImpl$RowIterator.hasNext(QueryImpl.java:798)
at
org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.init(FilterIterators.java:203)
at
org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.hasNext(FilterIterators.java:237)
at com.google.common.collect.Iterators$5.hasNext(Iterators.java:542)
at
org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.fetchNext(FilterIterators.java:137)
at
org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.hasNext(FilterIterators.java:151)
at
org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.init(FilterIterators.java:203)
at
org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.hasNext(FilterIterators.java:237)
at com.google.common.collect.Iterators$5.hasNext(Iterators.java:542)
at
org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.fetchNext(FilterIterators.java:137)
at
org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.hasNext(FilterIterators.java:151)
at
org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.init(FilterIterators.java:203)
at
org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.hasNext(FilterIterators.java:237)
at com.google.common.collect.Iterators$5.hasNext(Iterators.java:542)
at
org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.fetchNext(FilterIterators.java:137)
at
org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.hasNext(FilterIterators.java:151)
at
org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.init(FilterIterators.java:203)
at
org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.hasNext(FilterIterators.java:237)
at com.google.common.collect.Iterators$5.hasNext(Iterators.java:542)
at
org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.fetchNext(FilterIterators.java:137)
at
org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.hasNext(FilterIterators.java:151)
at
org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.init(FilterIterators.java:203)
at
org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.hasNext(FilterIterators.java:237)
at com.google.common.collect.Iterators$5.hasNext(Iterators.java:542)
at
org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.fetchNext(FilterIterators.java:137)
at
org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.hasNext(FilterIterators.java:151)
at
org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.init(FilterIterators.java:203)
at
org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.hasNext(FilterIterators.java:237)
at com.google.common.collect.Iterators$5.hasNext(Iterators.java:542)
at
org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.fetchNext(FilterIterators.java:137)
at
org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.hasNext(FilterIterators.java:151)
at
org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.init(FilterIterators.java:203)
at
org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.hasNext(FilterIterators.java:237)
at com.google.common.collect.Iterators$5.hasNext(Iterators.java:542)
at
org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.fetchNext(FilterIterators.java:137)
at
org.apache.jackrabbit.oak.query.FilterIterators$DistinctIterator.hasNext(FilterIterators.java:151)
at
org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.init(FilterIterators.java:203)
at
org.apache.jackrabbit.oak.query.FilterIterators$SortIterator.hasNext(FilterIterators.java:237)
[jira] [Commented] (OAK-5062) Test failure in DocumentNodeStoreConfigTest.testRDBDocumentStore_CustomBlobDataSource
[
https://issues.apache.org/jira/browse/OAK-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15673316#comment-15673316
]
Thomas Mueller commented on OAK-5062:
-
I can't reproduce either. The error message contains two statements, the first
one without the ending "$$". I don't know how this could happen; kind of like
the string was changed during parsing or so.
What about we solve this now as "can't reproduce", and if it happens again we
reopen the issue?
> Test failure in
> DocumentNodeStoreConfigTest.testRDBDocumentStore_CustomBlobDataSource
> -
>
> Key: OAK-5062
> URL: https://issues.apache.org/jira/browse/OAK-5062
> Project: Jackrabbit Oak
> Issue Type: Test
> Components: documentmk
>Reporter: Chetan Mehrotra
>Assignee: Thomas Mueller
>Priority: Minor
> Labels: test
> Fix For: 1.6
>
> Attachments: unit-tests.log
>
>
> Saw a test failure
> [here|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1262/jdk=JDK%201.7%20(latest),label=Ubuntu,nsfixtures=DOCUMENT_NS,profile=unittesting/testReport/junit/org.apache.jackrabbit.oak.run.osgi/DocumentNodeStoreConfigTest/testRDBDocumentStore_CustomBlobDataSource/]
> In the logs following can be seen
> {noformat}
> Caused by: org.h2.jdbc.JdbcSQLException: Syntax error in SQL statement
> "create alias if not exists unix_timestamp as [*]$$ long unix_timestamp() {
> return System.currentTimeMillis()/1000L; }"; SQL statement:
> create alias if not exists unix_timestamp as $$ long unix_timestamp() {
> return System.currentTimeMillis()/1000L; } $$; [42000-193]
> at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
> ~[h2-1.4.193.jar:1.4.193]
> at org.h2.message.DbException.get(DbException.java:179)
> ~[h2-1.4.193.jar:1.4.193]
> at org.h2.message.DbException.get(DbException.java:155)
> ~[h2-1.4.193.jar:1.4.193]
> at org.h2.message.DbException.getSyntaxError(DbException.java:191)
> ~[h2-1.4.193.jar:1.4.193]
> at org.h2.command.Parser.getSyntaxError(Parser.java:530)
> ~[h2-1.4.193.jar:1.4.193]
> at org.h2.command.Parser.checkRunOver(Parser.java:3694)
> ~[h2-1.4.193.jar:1.4.193]
> at org.h2.command.Parser.initialize(Parser.java:3559)
> ~[h2-1.4.193.jar:1.4.193]
> at org.h2.command.Parser.parse(Parser.java:304)
> ~[h2-1.4.193.jar:1.4.193]
> at org.h2.command.Parser.parse(Parser.java:293)
> ~[h2-1.4.193.jar:1.4.193]
> at
> org.h2.command.CommandContainer.recompileIfRequired(CommandContainer.java:73)
> ~[h2-1.4.193.jar:1.4.193]
> at org.h2.command.CommandContainer.update(CommandContainer.java:93)
> ~[h2-1.4.193.jar:1.4.193]
> at org.h2.command.Command.executeUpdate(Command.java:258)
> ~[h2-1.4.193.jar:1.4.193]
> at org.h2.jdbc.JdbcStatement.executeInternal(JdbcStatement.java:184)
> ~[h2-1.4.193.jar:1.4.193]
> at org.h2.jdbc.JdbcStatement.execute(JdbcStatement.java:158)
> ~[h2-1.4.193.jar:1.4.193]
> at
> org.apache.jackrabbit.oak.plugins.document.rdb.RDBDocumentStore.initialize(RDBDocumentStore.java:802)
> ~[oak-core-1.6-SNAPSHOT.jar:1.6-SNAPSHOT]
> at
> org.apache.jackrabbit.oak.plugins.document.rdb.RDBDocumentStore.(RDBDocumentStore.java:209)
> ~[oak-core-1.6-SNAPSHOT.jar:1.6-SNAPSHOT]
> ... 26 common frames omitted
> 03.11.2016 14:52:10.662 *ERROR* [CM Event Dispatcher (Fire
> ConfigurationEvent:
> pid=org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService)]
> org.apache.jackrabbit.oak-core
> [org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService(23)]
> Failed creating the component instance; see log for reason
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-5085) XPath: union bugfix
[
https://issues.apache.org/jira/browse/OAK-5085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15673263#comment-15673263
]
Thomas Mueller commented on OAK-5085:
-
http://svn.apache.org/r1770139 (trunk; more tests)
> XPath: union bugfix
> ---
>
> Key: OAK-5085
> URL: https://issues.apache.org/jira/browse/OAK-5085
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
> Fix For: 1.6, 1.5.14
>
>
> The following query does not work:
> {noformat}
> //*[jcr:contains(., 'x')] | //*[jcr:contains(., 'y')])
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-5120) Automatically convert *all* "or" queries to "union" for SQL-2, take 2
[
https://issues.apache.org/jira/browse/OAK-5120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller resolved OAK-5120.
-
Resolution: Fixed
https://svn.apache.org/r1770136
> Automatically convert *all* "or" queries to "union" for SQL-2, take 2
> -
>
> Key: OAK-5120
> URL: https://issues.apache.org/jira/browse/OAK-5120
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
> Fix For: 1.5.14
>
>
> OAK-4681 is trying to convert "or" SQL-2 queries to union (if that's faster).
> However, the following nested case is not yet converted fully to a union (one
> "or" is converted, but the other one is not):
> {noformat}
> select * from [nt:unstructured] as [c]
> where isdescendantnode('/tmp')
> and ([a]=1 or [b]=2) and ([c]=3 or [d]=4)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4857) Support space chars common in CJK inside node names
[
https://issues.apache.org/jira/browse/OAK-4857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15673244#comment-15673244
]
Julian Reschke commented on OAK-4857:
-
I don't believe that there's any automatic escaping/unescaping.
> Support space chars common in CJK inside node names
> ---
>
> Key: OAK-4857
> URL: https://issues.apache.org/jira/browse/OAK-4857
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.4.7, 1.5.10
>Reporter: Alexander Klimetschek
>Assignee: Julian Reschke
> Fix For: 1.8
>
> Attachments: OAK-4857-tests.patch
>
>
> Oak (like Jackrabbit) does not allow spaces commonly used in CJK like
> {{u3000}} (ideographic space) or {{u00A0}} (no-break space) _inside_ a node
> name, while allowing some of them (the non breaking spaces) at the _beginning
> or end_.
> They should be supported for better globalization readiness, and filesystems
> allow them, making common filesystem to JCR mappings unnecessarily hard.
> Escaping would be an option for applications, but there is currently no
> utility method for it
> ([Text.escapeIllegalJcrChars|https://jackrabbit.apache.org/api/2.8/org/apache/jackrabbit/util/Text.html#escapeIllegalJcrChars(java.lang.String)]
> will not escape these spaces), nor is it documented for applications how to
> do so.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4614) Collection of observation resilience issues
[ https://issues.apache.org/jira/browse/OAK-4614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15673226#comment-15673226 ] Stefan Egli commented on OAK-4614: -- [~mreutegg], should we split this epic into one we aim to finish in 1.6 and one for later? Some tasks are already deferred to 1.8. > Collection of observation resilience issues > --- > > Key: OAK-4614 > URL: https://issues.apache.org/jira/browse/OAK-4614 > Project: Jackrabbit Oak > Issue Type: Epic > Components: core, documentmk, jcr >Reporter: Marcel Reutegger > Fix For: 1.6 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
