[jira] [Commented] (OAK-1481) clarify DS.find caching behavior
[ https://issues.apache.org/jira/browse/OAK-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919122#comment-13919122 ] Marcel Reutegger commented on OAK-1481: --- Agreed. Updated JavaDoc accordingly. clarify DS.find caching behavior Key: OAK-1481 URL: https://issues.apache.org/jira/browse/OAK-1481 Project: Jackrabbit Oak Issue Type: Task Components: core Reporter: Julian Reschke Assignee: Marcel Reutegger Priority: Trivial Fix For: 0.18 The Javadoc for find(CollectionT collection, String key, int maxCacheAge) should be clarified wrt: - maxCacheAge == 0 (mongods seems to invalidate) and for T extends Document T find(CollectionT collection, String key) - what the implied caching behavior is (mongods seems to assume Integer.MAX_VALUE) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (OAK-1488) ConcurrentAddRemoveIT test failures
Michael Dürig created OAK-1488:
--
Summary: ConcurrentAddRemoveIT test failures
Key: OAK-1488
URL: https://issues.apache.org/jira/browse/OAK-1488
Project: Jackrabbit Oak
Issue Type: Bug
Components: jcr
Environment: http://ci.apache.org/builders/oak-trunk
Reporter: Michael Dürig
I quite regularly see this failing now:
{noformat}
concurrent[4](org.apache.jackrabbit.oak.jcr.ConcurrentAddRemoveIT) Time
elapsed: 58.018 sec FAILURE!
java.lang.AssertionError: javax.jcr.RepositoryException: OakMerge0001:
OakMerge0001: Failed to merge changes to the underlying store (retries 4, 4689
ms)
at org.junit.Assert.fail(Assert.java:93)
at
org.apache.jackrabbit.oak.jcr.ConcurrentAddRemoveIT.concurrent(ConcurrentAddRemoveIT.java:64)
{noformat}
Fixture 4 is {{DOCUMENT_JDBC}}. Not sure whether it also fails for other
fixtures.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (OAK-1488) ConcurrentAddRemoveIT test failures
[
https://issues.apache.org/jira/browse/OAK-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-1488:
---
Fix Version/s: 0.18
ConcurrentAddRemoveIT test failures
---
Key: OAK-1488
URL: https://issues.apache.org/jira/browse/OAK-1488
Project: Jackrabbit Oak
Issue Type: Bug
Components: jcr
Environment: http://ci.apache.org/builders/oak-trunk
Reporter: Michael Dürig
Fix For: 0.18
I quite regularly see this failing now:
{noformat}
concurrent[4](org.apache.jackrabbit.oak.jcr.ConcurrentAddRemoveIT) Time
elapsed: 58.018 sec FAILURE!
java.lang.AssertionError: javax.jcr.RepositoryException: OakMerge0001:
OakMerge0001: Failed to merge changes to the underlying store (retries 4,
4689 ms)
at org.junit.Assert.fail(Assert.java:93)
at
org.apache.jackrabbit.oak.jcr.ConcurrentAddRemoveIT.concurrent(ConcurrentAddRemoveIT.java:64)
{noformat}
Fixture 4 is {{DOCUMENT_JDBC}}. Not sure whether it also fails for other
fixtures.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (OAK-1488) ConcurrentAddRemoveIT test failures
[
https://issues.apache.org/jira/browse/OAK-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919129#comment-13919129
]
Michael Dürig commented on OAK-1488:
Disabled the test for the {{DOCUMENT_JDBC}} fixture at
http://svn.apache.org/r1573932.
ConcurrentAddRemoveIT test failures
---
Key: OAK-1488
URL: https://issues.apache.org/jira/browse/OAK-1488
Project: Jackrabbit Oak
Issue Type: Bug
Components: jcr
Environment: http://ci.apache.org/builders/oak-trunk
Reporter: Michael Dürig
Fix For: 0.18
I quite regularly see this failing now:
{noformat}
concurrent[4](org.apache.jackrabbit.oak.jcr.ConcurrentAddRemoveIT) Time
elapsed: 58.018 sec FAILURE!
java.lang.AssertionError: javax.jcr.RepositoryException: OakMerge0001:
OakMerge0001: Failed to merge changes to the underlying store (retries 4,
4689 ms)
at org.junit.Assert.fail(Assert.java:93)
at
org.apache.jackrabbit.oak.jcr.ConcurrentAddRemoveIT.concurrent(ConcurrentAddRemoveIT.java:64)
{noformat}
Fixture 4 is {{DOCUMENT_JDBC}}. Not sure whether it also fails for other
fixtures.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (OAK-1486) BackgroundObserverTest occasionally failing
[
https://issues.apache.org/jira/browse/OAK-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig resolved OAK-1486.
Resolution: Fixed
Fix Version/s: 0.18
Fixed at http://svn.apache.org/r1573682
BackgroundObserverTest occasionally failing
---
Key: OAK-1486
URL: https://issues.apache.org/jira/browse/OAK-1486
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Environment: Windows 7: http://ci.apache.org/builders/oak-trunk-win7
Reporter: Michael Dürig
Assignee: Michael Dürig
Labels: observation
Fix For: 0.18
{{BackgroundObserverTest.concurrentObservers}} occasionally fails for the
Windows 7 CI build:
{noformat}
concurrentObservers(org.apache.jackrabbit.oak.spi.commit.BackgroundObs) Time
elapsed: 5.058 sec FAILURE!
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at
org.apache.jackrabbit.oak.spi.commit.BackgroundObserverTest.concurrentObservers(BackgroundObserverTest.java:62)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (OAK-1263) optimize oak index to support 'fast ORDER BY' queries to support sorting pagination for large set of children
[
https://issues.apache.org/jira/browse/OAK-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919181#comment-13919181
]
Thomas Mueller commented on OAK-1263:
-
Your new patch still has some unnecessary formatting changes, for example the
very first lines of the patch, IndexUtils. getOrCreateOakIndex.
Some more comments:
It looks like you are using 3 spaces indentation, while in Oak we use 4 spaces.
Could you use 4 spaces as well please?
Some lines are over 200 characters long. Could we use a line length of 100
characters (the Eclipse default is 80, and Google uses 80 or 100)? Some if the
long lines are due to formatting changes of existing code.
{noformat}
if(Strings.isNullOrEmpty(value)){
{noformat}
Could you use the following instead (Eclipse and Google code conventions):
{noformat}
if (Strings.isNullOrEmpty(value)) {
{noformat}
Other spacing is inconsistent, for example:
{noformat}
+pns = Collections.singleton(value);
+this.properlyConfigured=true;
{noformat}
Could you use the following:
{noformat}
+pns = Collections.singleton(value);
+this.properlyConfigured = true; // = spaces
{noformat}
Could you use spaces before commas?
{noformat}
+/**
+ * retrieve the type of the index
+ *
+ * @return
+ */
{noformat}
I would prefer the following:
{noformat}
+/**
+ * Retrieve the type of the index.
+ *
+ * @return the type
+ */
{noformat}
optimize oak index to support 'fast ORDER BY' queries to support sorting
pagination for large set of children
---
Key: OAK-1263
URL: https://issues.apache.org/jira/browse/OAK-1263
Project: Jackrabbit Oak
Issue Type: Improvement
Components: query
Affects Versions: 0.12
Reporter: Stefan Egli
Assignee: Alex Parvulescu
Fix For: 0.18
Attachments: OAK-1263-r1.patch, OAK-1263-r1a.patch,
benchmark-20140228112150.log, benchmark-20140228120718.log,
benchmark-20140228125248.log
We have a use case where we'd like to be able to use an index in a
pagination-like fashion. That is, we'd like to be able to have an index on
a subtree on a certain property, and then run a query which does ORDER BY
that property combined with OFFSET. That way, essentially allowing pagination
of child nodes of a particular parent based on 'sorted by a certain property'.
AFAIU currently the oak index is not optimized to support ORDER BY queries in
a fast manner. The index keeps 'the child nodes unsorted', ie to process an
ORDER BY, the child nodes would have to be 'manually sorted' which can result
in bad performance given a large number of child nodes.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (OAK-1263) optimize oak index to support 'fast ORDER BY' queries to support sorting pagination for large set of children
[
https://issues.apache.org/jira/browse/OAK-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919193#comment-13919193
]
Thomas Mueller commented on OAK-1263:
-
Please note my comments are all about formatting, naming conventions, and so
on. The patch itself looks good!
But still, some more comments:
{noformat}
import static org.apache.jackrabbit.oak.plugins.index.property.OrderedIndex.*;
{noformat}
I personally don't like static imports (but this is a matter of taste), but I
think we agreed we don't use star imports.
OrderedPropertyIndexEditor and OrderedPropertyIndexEditorProvider: the license
header is missing.
OrderedPropertyIndexEditorProvider, variable _editor: we don't use the
underline prefix (for anything). Just rename it to editor. The same for other
variables, for example NodeBuilder _key.
{noformat}
/* (non-Javadoc)
* @see
org.apache.jackrabbit.oak.spi.query.QueryIndexProvider#getQueryIndexes(org.apache.jackrabbit.oak.spi.state.NodeState)
*/
{noformat}
I don't see a value in that comment. Could you remove it please?
Could you add class level javadoc comments (for example for for
OrderedContentMirrorStoreStrategy)?
{noformat}
public static final String NEXT = :next;
{noformat}
This is the wrong order, could you use:
{noformat}
public final static String NEXT = :next;
{noformat}
{noformat}
public void firstAndOnlyItem() {
final String PATH = /foo/bar;
{noformat}
The naming convention for variables is to use lowercase. Could you rename the
variable to path please?
{noformat}
assertEquals(Expecting 2 items in the index, 2,
Iterators.size(children.iterator())); // how
// many
// entries
// do
// we
// have?
{noformat}
Could you remove, or move the line comment to _before_ the line please? For
example:
{noformat}
// how many entries do we have?
assertEquals(Expecting 2 items in the index, 2,
Iterators.size(children.iterator()));
{noformat}
optimize oak index to support 'fast ORDER BY' queries to support sorting
pagination for large set of children
---
Key: OAK-1263
URL: https://issues.apache.org/jira/browse/OAK-1263
Project: Jackrabbit Oak
Issue Type: Improvement
Components: query
Affects Versions: 0.12
Reporter: Stefan Egli
Assignee: Alex Parvulescu
Fix For: 0.18
Attachments: OAK-1263-r1.patch, OAK-1263-r1a.patch,
benchmark-20140228112150.log, benchmark-20140228120718.log,
benchmark-20140228125248.log
We have a use case where we'd like to be able to use an index in a
pagination-like fashion. That is, we'd like to be able to have an index on
a subtree on a certain property, and then run a query which does ORDER BY
that property combined with OFFSET. That way, essentially allowing pagination
of child nodes of a particular parent based on 'sorted by a certain property'.
AFAIU currently the oak index is not optimized to support ORDER BY queries in
a fast manner. The index keeps 'the child nodes unsorted', ie to process an
ORDER BY, the child nodes would have to be 'manually sorted' which can result
in bad performance given a large number of child nodes.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (OAK-1263) optimize oak index to support 'fast ORDER BY' queries to support sorting pagination for large set of children
[
https://issues.apache.org/jira/browse/OAK-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919193#comment-13919193
]
Thomas Mueller edited comment on OAK-1263 at 3/4/14 9:47 AM:
-
Please note my comments are all about formatting, naming conventions, and so
on. The patch itself looks good!
But still, some more comments:
{noformat}
import static org.apache.jackrabbit.oak.plugins.index.property.OrderedIndex.*;
{noformat}
I personally don't like static imports (but this is a matter of taste), but I
think we agreed we don't use star imports.
OrderedPropertyIndexEditor and OrderedPropertyIndexEditorProvider: the license
header is missing.
OrderedPropertyIndexEditorProvider, variable _editor: we don't use the
underline prefix (for anything). Just rename it to editor. The same for other
variables, for example NodeBuilder _key.
{noformat}
/* (non-Javadoc)
* @see
org.apache.jackrabbit.oak.spi.query.QueryIndexProvider#getQueryIndexes(org.apache.jackrabbit.oak.spi.state.NodeState)
*/
{noformat}
I don't see a value in that comment. Could you remove it please?
Could you add class level javadoc comments (for example for for
OrderedContentMirrorStoreStrategy)?
{noformat}
public void firstAndOnlyItem() {
final String PATH = /foo/bar;
{noformat}
The naming convention for variables is to use lowercase. Could you rename the
variable to path please?
{noformat}
assertEquals(Expecting 2 items in the index, 2,
Iterators.size(children.iterator())); // how
// many
// entries
// do
// we
// have?
{noformat}
Could you remove, or move the line comment to _before_ the line please? For
example:
{noformat}
// how many entries do we have?
assertEquals(Expecting 2 items in the index, 2,
Iterators.size(children.iterator()));
{noformat}
was (Author: tmueller):
Please note my comments are all about formatting, naming conventions, and so
on. The patch itself looks good!
But still, some more comments:
{noformat}
import static org.apache.jackrabbit.oak.plugins.index.property.OrderedIndex.*;
{noformat}
I personally don't like static imports (but this is a matter of taste), but I
think we agreed we don't use star imports.
OrderedPropertyIndexEditor and OrderedPropertyIndexEditorProvider: the license
header is missing.
OrderedPropertyIndexEditorProvider, variable _editor: we don't use the
underline prefix (for anything). Just rename it to editor. The same for other
variables, for example NodeBuilder _key.
{noformat}
/* (non-Javadoc)
* @see
org.apache.jackrabbit.oak.spi.query.QueryIndexProvider#getQueryIndexes(org.apache.jackrabbit.oak.spi.state.NodeState)
*/
{noformat}
I don't see a value in that comment. Could you remove it please?
Could you add class level javadoc comments (for example for for
OrderedContentMirrorStoreStrategy)?
{noformat}
public static final String NEXT = :next;
{noformat}
This is the wrong order, could you use:
{noformat}
public final static String NEXT = :next;
{noformat}
{noformat}
public void firstAndOnlyItem() {
final String PATH = /foo/bar;
{noformat}
The naming convention for variables is to use lowercase. Could you rename the
variable to path please?
{noformat}
assertEquals(Expecting 2 items in the index, 2,
Iterators.size(children.iterator())); // how
// many
// entries
// do
// we
// have?
{noformat}
Could you remove, or move the line comment to _before_ the line please? For
example:
{noformat}
// how many entries do we have?
assertEquals(Expecting 2 items in the index, 2,
Iterators.size(children.iterator()));
{noformat}
optimize oak index to support 'fast ORDER BY' queries to support sorting
pagination for large set of children
---
Key: OAK-1263
URL:
[jira] [Created] (OAK-1489) ValueImpl should implement JackrabbitValue
Vikas Saurabh created OAK-1489:
--
Summary: ValueImpl should implement JackrabbitValue
Key: OAK-1489
URL: https://issues.apache.org/jira/browse/OAK-1489
Project: Jackrabbit Oak
Issue Type: Wish
Components: core
Reporter: Vikas Saurabh
For some reason, I need to get to datastore id. With JR2 (in sling env) I could
do:
{code}
String id = null;
Value v = resource.adaptTo(Value.class);
if(v instanceof JackrabbitValue) {
id = ((JackrabbitValue)v).getContentIdentity();
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (OAK-1490) Multiple primary types cause ParseException in SolrQueryIndex
Tommaso Teofili created OAK-1490: Summary: Multiple primary types cause ParseException in SolrQueryIndex Key: OAK-1490 URL: https://issues.apache.org/jira/browse/OAK-1490 Project: Jackrabbit Oak Issue Type: Bug Affects Versions: 0.17.1 Reporter: Tommaso Teofili Assignee: Tommaso Teofili Fix For: 0.18 Due to a lack of whitespace if the Filter contains multiple primary types restriction the generated Solr query is not well formed. Also the different primary types should be in OR. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (OAK-1490) Multiple primary types cause ParseException in SolrQueryIndex
[ https://issues.apache.org/jira/browse/OAK-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili resolved OAK-1490. -- Resolution: Fixed fixed in r1574018 Multiple primary types cause ParseException in SolrQueryIndex - Key: OAK-1490 URL: https://issues.apache.org/jira/browse/OAK-1490 Project: Jackrabbit Oak Issue Type: Bug Affects Versions: 0.17.1 Reporter: Tommaso Teofili Assignee: Tommaso Teofili Fix For: 0.18 Due to a lack of whitespace if the Filter contains multiple primary types restriction the generated Solr query is not well formed. Also the different primary types should be in OR. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (OAK-1475) Make Oak Solr bundle a fragment of Oak Lucene
[ https://issues.apache.org/jira/browse/OAK-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919239#comment-13919239 ] Tommaso Teofili commented on OAK-1475: -- I've managed to have the fragment solution up and running (https://github.com/tteofili/jackrabbit-oak/compare/oak-1475a), to me the long term solution would be based on proper semantic versioning support in Lucene / Solr but since we're not there yet (and it doesn't seem it's going to happen shortly) I agree with [~jukkaz] that this one looks a bit less risky than the wrap-bundles one in terms of versioning so to me this approach looks like a good compromise between proper OSGi support and required effort (maintaining our own versioning of Lucene / Solr packages would be quite hard to keep up with). Make Oak Solr bundle a fragment of Oak Lucene - Key: OAK-1475 URL: https://issues.apache.org/jira/browse/OAK-1475 Project: Jackrabbit Oak Issue Type: Wish Components: oak-lucene, oak-solr Affects Versions: 0.16 Reporter: Tommaso Teofili Assignee: Tommaso Teofili Fix For: 0.18 As suggested in OAK-1442 it'd be useful to avoid duplicating Lucene dependencies used by Oak Solr and therefore that should be a fragment of oak-lucene as host. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (OAK-1491) ObservationTest failure on Windows
Michael Dürig created OAK-1491:
--
Summary: ObservationTest failure on Windows
Key: OAK-1491
URL: https://issues.apache.org/jira/browse/OAK-1491
Project: Jackrabbit Oak
Issue Type: Bug
Components: jcr
Environment: http://ci.apache.org/builders/oak-trunk-win7
Reporter: Michael Dürig
{{ObservationTest}} fails often on some Windows machines:
{noformat}
pathFilter[3](org.apache.jackrabbit.oak.jcr.observation.ObservationTest) Time
elapsed: 0.864 sec FAILURE!
java.lang.AssertionError: Missing events: [path = /events/only/here/below/this,
type = 1]
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at
org.apache.jackrabbit.oak.jcr.observation.ObservationTest.pathFilter(ObservationTest.java:315)
{noformat}
and
{noformat}
filterPropertyOfParent[2](org.apache.jackrabbit.oak.jcr.observation.ObservationTest)
Time elapsed: 0.88 sec FAILURE!
java.lang.AssertionError: Missing events: [path = /test_node/a/jcr:primaryType,
type = 4, path = /test_node/a/foo, type = 4, path = /test_node/a/b, type = 1]
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at
org.apache.jackrabbit.oak.jcr.observation.ObservationTest.filterPropertyOfParent(ObservationTest.java:614)
{noformat}
I have the suspicion this is an issue with the test similar to OAK-1486
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (OAK-1491) ObservationTest failure on Windows
[
https://issues.apache.org/jira/browse/OAK-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig reassigned OAK-1491:
--
Assignee: Michael Dürig
ObservationTest failure on Windows
--
Key: OAK-1491
URL: https://issues.apache.org/jira/browse/OAK-1491
Project: Jackrabbit Oak
Issue Type: Bug
Components: jcr
Environment: http://ci.apache.org/builders/oak-trunk-win7
Reporter: Michael Dürig
Assignee: Michael Dürig
{{ObservationTest}} fails often on some Windows machines:
{noformat}
pathFilter[3](org.apache.jackrabbit.oak.jcr.observation.ObservationTest)
Time elapsed: 0.864 sec FAILURE!
java.lang.AssertionError: Missing events: [path =
/events/only/here/below/this, type = 1]
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at
org.apache.jackrabbit.oak.jcr.observation.ObservationTest.pathFilter(ObservationTest.java:315)
{noformat}
and
{noformat}
filterPropertyOfParent[2](org.apache.jackrabbit.oak.jcr.observation.ObservationTest)
Time elapsed: 0.88 sec FAILURE!
java.lang.AssertionError: Missing events: [path =
/test_node/a/jcr:primaryType, type = 4, path = /test_node/a/foo, type = 4,
path = /test_node/a/b, type = 1]
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at
org.apache.jackrabbit.oak.jcr.observation.ObservationTest.filterPropertyOfParent(ObservationTest.java:614)
{noformat}
I have the suspicion this is an issue with the test similar to OAK-1486
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (OAK-1472) ConcurrentAddReferenceTest#addReferences still fails
[
https://issues.apache.org/jira/browse/OAK-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919330#comment-13919330
]
Alex Parvulescu commented on OAK-1472:
--
the test is now enabled and passing except for the {{DOCUMENT_JDBC}} where I've
disabled it.
ConcurrentAddReferenceTest#addReferences still fails
Key: OAK-1472
URL: https://issues.apache.org/jira/browse/OAK-1472
Project: Jackrabbit Oak
Issue Type: Bug
Components: core, jcr
Reporter: angela
Assignee: Alex Parvulescu
Fix For: 0.19
the test ConcurrentAddReferenceTest#addReferences is marked with @Ignore
pointing to OAK-1137 which has been resolved already for release 0.12.
Opening a new issue here in order to keep track of the failing test and get a
resolution for this.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (OAK-1488) ConcurrentAddRemoveIT, ConcurrentAddIT test failures
[
https://issues.apache.org/jira/browse/OAK-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-1488:
---
Summary: ConcurrentAddRemoveIT, ConcurrentAddIT test failures (was:
ConcurrentAddRemoveIT test failures)
ConcurrentAddRemoveIT, ConcurrentAddIT test failures
Key: OAK-1488
URL: https://issues.apache.org/jira/browse/OAK-1488
Project: Jackrabbit Oak
Issue Type: Bug
Components: jcr
Environment: http://ci.apache.org/builders/oak-trunk
Reporter: Michael Dürig
Fix For: 0.18
I quite regularly see this failing now:
{noformat}
concurrent[4](org.apache.jackrabbit.oak.jcr.ConcurrentAddRemoveIT) Time
elapsed: 58.018 sec FAILURE!
java.lang.AssertionError: javax.jcr.RepositoryException: OakMerge0001:
OakMerge0001: Failed to merge changes to the underlying store (retries 4,
4689 ms)
at org.junit.Assert.fail(Assert.java:93)
at
org.apache.jackrabbit.oak.jcr.ConcurrentAddRemoveIT.concurrent(ConcurrentAddRemoveIT.java:64)
{noformat}
Fixture 4 is {{DOCUMENT_JDBC}}. Not sure whether it also fails for other
fixtures.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (OAK-1488) ConcurrentAddRemoveIT, ConcurrentAddIT test failures
[
https://issues.apache.org/jira/browse/OAK-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919356#comment-13919356
]
Michael Dürig commented on OAK-1488:
Also for the {{DOCUMENT_JDBC}} fixture:
{noformat}
addNodes[4](org.apache.jackrabbit.oak.jcr.ConcurrentAddIT) Time elapsed:
10.814 sec FAILURE!
java.lang.AssertionError: expected:100 but was:99
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at
org.apache.jackrabbit.oak.jcr.ConcurrentAddIT.addNodes(ConcurrentAddIT.java:74)
{noformat}
ConcurrentAddRemoveIT, ConcurrentAddIT test failures
Key: OAK-1488
URL: https://issues.apache.org/jira/browse/OAK-1488
Project: Jackrabbit Oak
Issue Type: Bug
Components: jcr
Environment: http://ci.apache.org/builders/oak-trunk
Reporter: Michael Dürig
Fix For: 0.18
I quite regularly see this failing now:
{noformat}
concurrent[4](org.apache.jackrabbit.oak.jcr.ConcurrentAddRemoveIT) Time
elapsed: 58.018 sec FAILURE!
java.lang.AssertionError: javax.jcr.RepositoryException: OakMerge0001:
OakMerge0001: Failed to merge changes to the underlying store (retries 4,
4689 ms)
at org.junit.Assert.fail(Assert.java:93)
at
org.apache.jackrabbit.oak.jcr.ConcurrentAddRemoveIT.concurrent(ConcurrentAddRemoveIT.java:64)
{noformat}
Fixture 4 is {{DOCUMENT_JDBC}}. Not sure whether it also fails for other
fixtures.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (OAK-1488) ConcurrentAddRemoveIT, ConcurrentAddIT test failures
[
https://issues.apache.org/jira/browse/OAK-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919359#comment-13919359
]
Michael Dürig commented on OAK-1488:
Disabled the test for the {{DOCUMENT_JDBC}} fixture at
http://svn.apache.org/r1574083.
[~julian.resc...@greenbytes.de], as this only seems to happen with the said
fixture, could you have a look?
ConcurrentAddRemoveIT, ConcurrentAddIT test failures
Key: OAK-1488
URL: https://issues.apache.org/jira/browse/OAK-1488
Project: Jackrabbit Oak
Issue Type: Bug
Components: jcr
Environment: http://ci.apache.org/builders/oak-trunk
Reporter: Michael Dürig
Fix For: 0.18
I quite regularly see this failing now:
{noformat}
concurrent[4](org.apache.jackrabbit.oak.jcr.ConcurrentAddRemoveIT) Time
elapsed: 58.018 sec FAILURE!
java.lang.AssertionError: javax.jcr.RepositoryException: OakMerge0001:
OakMerge0001: Failed to merge changes to the underlying store (retries 4,
4689 ms)
at org.junit.Assert.fail(Assert.java:93)
at
org.apache.jackrabbit.oak.jcr.ConcurrentAddRemoveIT.concurrent(ConcurrentAddRemoveIT.java:64)
{noformat}
Fixture 4 is {{DOCUMENT_JDBC}}. Not sure whether it also fails for other
fixtures.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (OAK-1488) ConcurrentAddRemoveIT, ConcurrentAddIT test failures
[
https://issues.apache.org/jira/browse/OAK-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919360#comment-13919360
]
Alex Parvulescu commented on OAK-1488:
--
fyi ConcurrentAddReferenceTest (OAK-1472) is also failing on the
{{DOCUMENT_JDBC}} fixture.
ConcurrentAddRemoveIT, ConcurrentAddIT test failures
Key: OAK-1488
URL: https://issues.apache.org/jira/browse/OAK-1488
Project: Jackrabbit Oak
Issue Type: Bug
Components: jcr
Environment: http://ci.apache.org/builders/oak-trunk
Reporter: Michael Dürig
Fix For: 0.18
I quite regularly see this failing now:
{noformat}
concurrent[4](org.apache.jackrabbit.oak.jcr.ConcurrentAddRemoveIT) Time
elapsed: 58.018 sec FAILURE!
java.lang.AssertionError: javax.jcr.RepositoryException: OakMerge0001:
OakMerge0001: Failed to merge changes to the underlying store (retries 4,
4689 ms)
at org.junit.Assert.fail(Assert.java:93)
at
org.apache.jackrabbit.oak.jcr.ConcurrentAddRemoveIT.concurrent(ConcurrentAddRemoveIT.java:64)
{noformat}
Fixture 4 is {{DOCUMENT_JDBC}}. Not sure whether it also fails for other
fixtures.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (OAK-1492) Make the SolrQueryIndex catch all field configurable
[ https://issues.apache.org/jira/browse/OAK-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili resolved OAK-1492. -- Resolution: Fixed fixed in r1574102 and r1574104 Make the SolrQueryIndex catch all field configurable Key: OAK-1492 URL: https://issues.apache.org/jira/browse/OAK-1492 Project: Jackrabbit Oak Issue Type: Improvement Components: oak-solr Reporter: Tommaso Teofili Assignee: Tommaso Teofili Fix For: 0.18 the catch all field for Solr is currently hardcoded while it'd be better to make it configurable as the other fields used by the QueryIndex. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (OAK-1493) Export OSGi headers for o.a.j.o.plugins.segment and segment.http
Alex Parvulescu created OAK-1493: Summary: Export OSGi headers for o.a.j.o.plugins.segment and segment.http Key: OAK-1493 URL: https://issues.apache.org/jira/browse/OAK-1493 Project: Jackrabbit Oak Issue Type: Improvement Components: core, segmentmk Reporter: Alex Parvulescu Assignee: Alex Parvulescu Priority: Minor I'd like to add OSGi headers for the segment packages, to help with the failover code. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (OAK-1493) Export OSGi headers for o.a.j.o.plugins.segment and segment.http
[ https://issues.apache.org/jira/browse/OAK-1493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Parvulescu resolved OAK-1493. -- Resolution: Fixed Fix Version/s: 0.18 fixed with rev http://svn.apache.org/r1574118 Export OSGi headers for o.a.j.o.plugins.segment and segment.http Key: OAK-1493 URL: https://issues.apache.org/jira/browse/OAK-1493 Project: Jackrabbit Oak Issue Type: Improvement Components: core, segmentmk Reporter: Alex Parvulescu Assignee: Alex Parvulescu Priority: Minor Fix For: 0.18 I'd like to add OSGi headers for the segment packages, to help with the failover code. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (OAK-1494) Backup fails on HttpStore
Alex Parvulescu created OAK-1494: Summary: Backup fails on HttpStore Key: OAK-1494 URL: https://issues.apache.org/jira/browse/OAK-1494 Project: Jackrabbit Oak Issue Type: Improvement Components: segmentmk Affects Versions: 0.17.1 Reporter: Alex Parvulescu I'm experiencing some issues with the http failover: the backup of the http store is throwing some errors. The error comes from running the backup a few times on the same directory (much like an incremental backup) and the segment that causes this seems to have a really small length (284 or on a different occasion 388 bytes transferred). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (OAK-1494) Initialization fails on the SegmentStore on HttpStore
[ https://issues.apache.org/jira/browse/OAK-1494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919492#comment-13919492 ] Alex Parvulescu commented on OAK-1494: -- It's worth mentioning that the simple oak-run repo works just fine, a bigger setup (like our Granite one) doesn't. Initialization fails on the SegmentStore on HttpStore -- Key: OAK-1494 URL: https://issues.apache.org/jira/browse/OAK-1494 Project: Jackrabbit Oak Issue Type: Improvement Components: segmentmk Affects Versions: 0.17.1 Reporter: Alex Parvulescu I'm experiencing some issues with the http failover: the backup of the http store is throwing some errors. The error comes from running the backup a few times on the same directory (much like an incremental backup) and the segment that causes this seems to have a really small length (284 or on a different occasion 388 bytes transferred). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (OAK-1161) Simple failover for TarMK-based installations
[ https://issues.apache.org/jira/browse/OAK-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919490#comment-13919490 ] Alex Parvulescu commented on OAK-1161: -- What initially was about the backup, now affect HttpStore's init too. I've created OAK-1494 to track it. Simple failover for TarMK-based installations - Key: OAK-1161 URL: https://issues.apache.org/jira/browse/OAK-1161 Project: Jackrabbit Oak Issue Type: New Feature Components: segmentmk Reporter: Michael Marth Assignee: Alex Parvulescu Fix For: 0.18 At the moment we have a Mongo-based MK impl that Oak users for scalable deployments and TarMK for standalone (performant) deployments. I think it is OK to not implement some sort of scalability into TarMK, even if I realize that the hierarchical journals allow us to do that later if we want to. However, it would even now be great to have a failover option for TarMK (MongoMK implictly offers this through replicas). This would not be about clustering or scalability, but only about reliability. I think there are 2 parts to this: # keeping a standby repository (slave) in sync and # the actual fail over. For the first part there could be a relatively simple way to implement this: Let's consider that there is only one slave and that the slave does not accept writes. Given the MVCC nature of the tar files we could simply sync the (append-only) tar files from the master to the slave on an ongoing basis. This could be similar to an rsync (or even use actual rsync) The slave would keep on receiving and locally persisting these files. Also, the slave would either need to be in a state where it is blocks writes or even in some sort of sleep state. I think this synchronization of files could be done a rather robust way where shaky networks or high latency could be recovered from by choosing a proper way of transfer. This sync to a remote system could be implemented similarly than a tarMK-based incremental backup (OAK-1159). For the failover: Ideally, we would have 2 implementations: a native failover and an external switch (like MBean or via HTTP) that would make the slave stop accepting files from master and start up on the last completely received revision. But simply having the second option would be a good start. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (OAK-1488) ConcurrentAddRemoveIT, ConcurrentAddIT test failures
[
https://issues.apache.org/jira/browse/OAK-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919507#comment-13919507
]
Julian Reschke commented on OAK-1488:
-
[~mduerig] Right now it doesn't fail for me - I'll keep trying.
ConcurrentAddRemoveIT, ConcurrentAddIT test failures
Key: OAK-1488
URL: https://issues.apache.org/jira/browse/OAK-1488
Project: Jackrabbit Oak
Issue Type: Bug
Components: jcr
Environment: http://ci.apache.org/builders/oak-trunk
Reporter: Michael Dürig
Fix For: 0.18
I quite regularly see this failing now:
{noformat}
concurrent[4](org.apache.jackrabbit.oak.jcr.ConcurrentAddRemoveIT) Time
elapsed: 58.018 sec FAILURE!
java.lang.AssertionError: javax.jcr.RepositoryException: OakMerge0001:
OakMerge0001: Failed to merge changes to the underlying store (retries 4,
4689 ms)
at org.junit.Assert.fail(Assert.java:93)
at
org.apache.jackrabbit.oak.jcr.ConcurrentAddRemoveIT.concurrent(ConcurrentAddRemoveIT.java:64)
{noformat}
Fixture 4 is {{DOCUMENT_JDBC}}. Not sure whether it also fails for other
fixtures.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (OAK-1488) ConcurrentAddRemoveIT, ConcurrentAddIT test failures
[
https://issues.apache.org/jira/browse/OAK-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919507#comment-13919507
]
Julian Reschke edited comment on OAK-1488 at 3/4/14 3:17 PM:
-
[~mduerig] Right now it doesn't fail for me - I'll keep trying. If you have
more details please let me know.
was (Author: reschke):
[~mduerig] Right now it doesn't fail for me - I'll keep trying.
ConcurrentAddRemoveIT, ConcurrentAddIT test failures
Key: OAK-1488
URL: https://issues.apache.org/jira/browse/OAK-1488
Project: Jackrabbit Oak
Issue Type: Bug
Components: jcr
Environment: http://ci.apache.org/builders/oak-trunk
Reporter: Michael Dürig
Fix For: 0.18
I quite regularly see this failing now:
{noformat}
concurrent[4](org.apache.jackrabbit.oak.jcr.ConcurrentAddRemoveIT) Time
elapsed: 58.018 sec FAILURE!
java.lang.AssertionError: javax.jcr.RepositoryException: OakMerge0001:
OakMerge0001: Failed to merge changes to the underlying store (retries 4,
4689 ms)
at org.junit.Assert.fail(Assert.java:93)
at
org.apache.jackrabbit.oak.jcr.ConcurrentAddRemoveIT.concurrent(ConcurrentAddRemoveIT.java:64)
{noformat}
Fixture 4 is {{DOCUMENT_JDBC}}. Not sure whether it also fails for other
fixtures.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (OAK-1263) optimize oak index to support 'fast ORDER BY' queries to support sorting pagination for large set of children
[
https://issues.apache.org/jira/browse/OAK-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919513#comment-13919513
]
Davide Giannella edited comment on OAK-1263 at 3/4/14 3:20 PM:
---
Attached a new version of patch {{OAK-1263-r1b.patch}}.
[~tmueller] the headers where already there. Don't want you looked at the old
version of the patch file.
I tried to apply all the suggestions with the reserve of the PATH vs path
(uppercase variable vs lowercase) as in the use case you highlighted it's a
constant (final) and by java conventions it should be uppercase. Anyhow I'm not
strict on those aspect so if you think it should be lowercase tell me and I'll
convert it.
The pull request has been updated as well.
was (Author: edivad):
Attached a new version of patch {OAK-1263-r1b.patch}.
[~tmueller] the headers where already there. Don't want you looked at the old
version of the patch file.
I tried to apply all the suggestions with the reserve of the PATH vs path
(uppercase variable vs lowercase) as in the use case you highlighted it's a
constant (final) and by java conventions it should be uppercase. Anyhow I'm not
strict on those aspect so if you think it should be lowercase tell me and I'll
convert it.
optimize oak index to support 'fast ORDER BY' queries to support sorting
pagination for large set of children
---
Key: OAK-1263
URL: https://issues.apache.org/jira/browse/OAK-1263
Project: Jackrabbit Oak
Issue Type: Improvement
Components: query
Affects Versions: 0.12
Reporter: Stefan Egli
Assignee: Alex Parvulescu
Fix For: 0.18
Attachments: OAK-1263-r1.patch, OAK-1263-r1a.patch,
OAK-1263-r1b.patch, benchmark-20140228112150.log,
benchmark-20140228120718.log, benchmark-20140228125248.log
We have a use case where we'd like to be able to use an index in a
pagination-like fashion. That is, we'd like to be able to have an index on
a subtree on a certain property, and then run a query which does ORDER BY
that property combined with OFFSET. That way, essentially allowing pagination
of child nodes of a particular parent based on 'sorted by a certain property'.
AFAIU currently the oak index is not optimized to support ORDER BY queries in
a fast manner. The index keeps 'the child nodes unsorted', ie to process an
ORDER BY, the child nodes would have to be 'manually sorted' which can result
in bad performance given a large number of child nodes.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (OAK-1263) optimize oak index to support 'fast ORDER BY' queries to support sorting pagination for large set of children
[
https://issues.apache.org/jira/browse/OAK-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-1263:
--
Attachment: OAK-1263-r1b.patch
Attached a new version of patch {OAK-1263-r1b.patch}.
[~tmueller] the headers where already there. Don't want you looked at the old
version of the patch file.
I tried to apply all the suggestions with the reserve of the PATH vs path
(uppercase variable vs lowercase) as in the use case you highlighted it's a
constant (final) and by java conventions it should be uppercase. Anyhow I'm not
strict on those aspect so if you think it should be lowercase tell me and I'll
convert it.
optimize oak index to support 'fast ORDER BY' queries to support sorting
pagination for large set of children
---
Key: OAK-1263
URL: https://issues.apache.org/jira/browse/OAK-1263
Project: Jackrabbit Oak
Issue Type: Improvement
Components: query
Affects Versions: 0.12
Reporter: Stefan Egli
Assignee: Alex Parvulescu
Fix For: 0.18
Attachments: OAK-1263-r1.patch, OAK-1263-r1a.patch,
OAK-1263-r1b.patch, benchmark-20140228112150.log,
benchmark-20140228120718.log, benchmark-20140228125248.log
We have a use case where we'd like to be able to use an index in a
pagination-like fashion. That is, we'd like to be able to have an index on
a subtree on a certain property, and then run a query which does ORDER BY
that property combined with OFFSET. That way, essentially allowing pagination
of child nodes of a particular parent based on 'sorted by a certain property'.
AFAIU currently the oak index is not optimized to support ORDER BY queries in
a fast manner. The index keeps 'the child nodes unsorted', ie to process an
ORDER BY, the child nodes would have to be 'manually sorted' which can result
in bad performance given a large number of child nodes.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (OAK-1495) Unify Root.commit(String) and Root.commit(Map)
Jukka Zitting created OAK-1495: -- Summary: Unify Root.commit(String) and Root.commit(Map) Key: OAK-1495 URL: https://issues.apache.org/jira/browse/OAK-1495 Project: Jackrabbit Oak Issue Type: Improvement Components: core Reporter: Jukka Zitting Assignee: Jukka Zitting Priority: Minor The former is just a convenience wrapper around the latter. And since it's used only in one place, we could just as well construct the info map in the caller. Doing so reduces the API footprint and removes duplicate code. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (OAK-1495) Unify Root.commit(String) and Root.commit(Map)
[ https://issues.apache.org/jira/browse/OAK-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved OAK-1495. Resolution: Fixed Fix Version/s: 0.18 done in revision 1574189 Unify Root.commit(String) and Root.commit(Map) -- Key: OAK-1495 URL: https://issues.apache.org/jira/browse/OAK-1495 Project: Jackrabbit Oak Issue Type: Improvement Components: core Reporter: Jukka Zitting Assignee: Jukka Zitting Priority: Minor Fix For: 0.18 The former is just a convenience wrapper around the latter. And since it's used only in one place, we could just as well construct the info map in the caller. Doing so reduces the API footprint and removes duplicate code. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (OAK-1496) Benchmark for concurrent file writes.
Amit Jain created OAK-1496: -- Summary: Benchmark for concurrent file writes. Key: OAK-1496 URL: https://issues.apache.org/jira/browse/OAK-1496 Project: Jackrabbit Oak Issue Type: Improvement Components: run Affects Versions: 0.17.1 Reporter: Amit Jain Create a benchmark test to monitor performance for concurrent file writes. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (OAK-1496) Benchmark for concurrent file writes.
[ https://issues.apache.org/jira/browse/OAK-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-1496: --- Attachment: OAK-1496.patch Patch for including the concurrent file write benchmark. Benchmark for concurrent file writes. - Key: OAK-1496 URL: https://issues.apache.org/jira/browse/OAK-1496 Project: Jackrabbit Oak Issue Type: Improvement Components: run Affects Versions: 0.17.1 Reporter: Amit Jain Attachments: OAK-1496.patch Create a benchmark test to monitor performance for concurrent file writes. -- This message was sent by Atlassian JIRA (v6.2#6252)
