[jira] [Created] (OAK-6849) Avoid creating empty properties node under indexRules
Chetan Mehrotra created OAK-6849: Summary: Avoid creating empty properties node under indexRules Key: OAK-6849 URL: https://issues.apache.org/jira/browse/OAK-6849 Project: Jackrabbit Oak Issue Type: Improvement Components: lucene Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Priority: Minor Fix For: 1.8 IndexDefinitionBuilder currently creates an empty properties node under indexRule. With OAK-6832 we would be creating empty indexRules for nodetype index we should avoid this empty properties node -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6575) Provide a secure external URL to a DataStore binary.
[
https://issues.apache.org/jira/browse/OAK-6575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amit Jain updated OAK-6575:
---
Fix Version/s: (was: 1.7.10)
> Provide a secure external URL to a DataStore binary.
>
>
> Key: OAK-6575
> URL: https://issues.apache.org/jira/browse/OAK-6575
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: blob, core, jcr, security
>Reporter: Ian Boston
>Assignee: Amit Jain
> Fix For: 1.8
>
>
> Where the DataStore is a DataStore that may be accessed over an independent
> API it would be advantageous for Oak to provide a secure URL to allow direct,
> read only access to the current immutable instance of that binary. The term
> "secure" needs to be defined, but typically it would a URL that is valid for
> a appropriately short length of time to ensure that the risk of the URL being
> used by a user that it was not intended for, is minimised. It should also
> ensure that anyone in possession of the URL could not use the information in
> the url to create a valid URL or a valid URL to a different binary.
> One example of such a URL might be a AWS Signed URL as used by AWS CloudFront
> to access private content. The signed url being signed by a private key known
> only to the Oak instance and the the CloudFront or S3 instance. The signed
> url having a significantly low ttl so that a redirect by the same client
> would work.
> Oak should only emit these URLs to sessions that could otherwise read the
> binary directly from Oak, and Oak should be in complete control of the nature
> of the url and the security mechanisms applied to the URL.
> The viability of the approach has been investigated showing that given a JCR
> Binary it is possible to get the Oak Blob Content Identifier using
> ValueImpl.getBlob((Value)jcrBinary).getContentIentifier() and form there,
> knowing the way in which the DataStore implementation transforms that into a
> pointer into the datastore implementation form a URL to be made secure.
> To achieve the above, internal implementation details specific to the Oak
> DataStore implementation are required, hence this request to implement as a
> part of Oak rather than to reverse engineer in some external project.
> Since API changes are often significant using the Sling AdapaterFactory
> approach would allow a ServletFilter to selectively use the URL in a
> redirect, avoiding any new API methods to existing Oak APIs. A new interface
> might be required, in the example below that interface is SignedBinaryURL.
> {code}
> public void doFilter(ServletRequest servletRequest, ServletResponse
> servletResponse, FilterChain filterChain) throws IOException,
> ServletException {
> if ( servletRequest instanceof SlingHttpServletRequest &&
> servletResponse instanceof SlingHttpServletResponse) {
> if ("GET".equals(((SlingHttpServletRequest)
> servletRequest).getMethod())){
> Resource resource = ((SlingHttpServletRequest)
> servletRequest).getResource();
> SignedBinaryURL url = resource.adaptTo(SignedBinaryURL.class);
> if (url != null) {
> ((SlingHttpServletResponse)
> servletResponse).sendRedirect(url.getURL());
> return;
> }
> }
> }
> filterChain.doFilter(servletRequest, servletResponse);
> }
> {code}
> If the AdapterFactory to go from Binary to SingedBinaryURL is not present
> then url will always be null, and no-op. If it is present, and Oak decides no
> URL is appropriate, then no-op.
> Only if the Oak DS implementation being used supports the external URL and
> Oak decides it is appropriate, will a url be available and a redirect
> performed.
> I have used AWS S3 URLs as an example, however the approach should be
> applicable (and pluggable) to most REST based APIs to private binary content.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (OAK-6841) Revert Changes made in OAK-6575 before 1.7.10 is released.
[ https://issues.apache.org/jira/browse/OAK-6841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain resolved OAK-6841. Resolution: Fixed Reverted changes with r1812702, r1812703, r1812704 > Revert Changes made in OAK-6575 before 1.7.10 is released. > -- > > Key: OAK-6841 > URL: https://issues.apache.org/jira/browse/OAK-6841 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: blob, core, jcr >Affects Versions: 1.7.10 >Reporter: Ian Boston >Assignee: Amit Jain >Priority: Blocker > Fix For: 1.8, 1.7.10 > > > Please revert the following commits to avoid the changes made in OAK-6575 > already released reaching 1.7.10 or a stable release while alternative > approaches are being investigated. > The reasons are documented in OAK-6575. > https://github.com/apache/jackrabbit-oak/commit/4870129e21352cef6f075ce26e09b743883a3214 > ( https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1811184) > https://github.com/apache/jackrabbit-oak/commit/8275b9baf1065d2cb977d23c5c64ec77fa6615ee > ( https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1811183 ) > https://github.com/apache/jackrabbit-oak/commit/9a77e0785b1177b33f9d72dfbb9d1d369becc914 > ( https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1811179) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6848) Improve ObservationQueueFullWarnTest.testQueueFullThenFlushing to not sleep arbitrarily when not required
[
https://issues.apache.org/jira/browse/OAK-6848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-6848:
---
Fix Version/s: 1.8
> Improve ObservationQueueFullWarnTest.testQueueFullThenFlushing to not sleep
> arbitrarily when not required
> -
>
> Key: OAK-6848
> URL: https://issues.apache.org/jira/browse/OAK-6848
> Project: Jackrabbit Oak
> Issue Type: Test
> Components: jcr
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
> Fix For: 1.8, 1.7.10
>
>
> Due to OAK-6639, {{ObservationQueueFullWarnTest.testQueueFullThenFlushing}}
> now has a hard-coded sleep to let the test pass on systems which are unable
> to process init message on observation soon enough.
> As proposed there, we should avoid hard-coded sleep and simply wait for
> our-own-init message for some time - faster system would get it faster,
> slower systems can wait for it a bit more.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (OAK-6848) Improve ObservationQueueFullWarnTest.testQueueFullThenFlushing to not sleep arbitrarily when not required
[
https://issues.apache.org/jira/browse/OAK-6848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh resolved OAK-6848.
Resolution: Fixed
Fix Version/s: 1.7.10
Done on trunk at [r1812699|https://svn.apache.org/r1812699].
> Improve ObservationQueueFullWarnTest.testQueueFullThenFlushing to not sleep
> arbitrarily when not required
> -
>
> Key: OAK-6848
> URL: https://issues.apache.org/jira/browse/OAK-6848
> Project: Jackrabbit Oak
> Issue Type: Test
> Components: jcr
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
> Fix For: 1.7.10
>
>
> Due to OAK-6639, {{ObservationQueueFullWarnTest.testQueueFullThenFlushing}}
> now has a hard-coded sleep to let the test pass on systems which are unable
> to process init message on observation soon enough.
> As proposed there, we should avoid hard-coded sleep and simply wait for
> our-own-init message for some time - faster system would get it faster,
> slower systems can wait for it a bit more.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (OAK-6848) Improve ObservationQueueFullWarnTest.testQueueFullThenFlushing to not sleep arbitrarily when not required
Vikas Saurabh created OAK-6848:
--
Summary: Improve
ObservationQueueFullWarnTest.testQueueFullThenFlushing to not sleep arbitrarily
when not required
Key: OAK-6848
URL: https://issues.apache.org/jira/browse/OAK-6848
Project: Jackrabbit Oak
Issue Type: Test
Components: jcr
Reporter: Vikas Saurabh
Assignee: Vikas Saurabh
Priority: Minor
Due to OAK-6639, {{ObservationQueueFullWarnTest.testQueueFullThenFlushing}} now
has a hard-coded sleep to let the test pass on systems which are unable to
process init message on observation soon enough.
As proposed there, we should avoid hard-coded sleep and simply wait for
our-own-init message for some time - faster system would get it faster, slower
systems can wait for it a bit more.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (OAK-6727) Oak should compile & test on Java 9
[ https://issues.apache.org/jira/browse/OAK-6727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved OAK-6727. - Resolution: Fixed Fix Version/s: 1.7.10 1.8 > Oak should compile & test on Java 9 > --- > > Key: OAK-6727 > URL: https://issues.apache.org/jira/browse/OAK-6727 > Project: Jackrabbit Oak > Issue Type: Epic >Reporter: Julian Reschke > Fix For: 1.8, 1.7.10 > > > (umbrella issue for tracking changes) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-1819) oak-solr-core test failures on Java 8
[
https://issues.apache.org/jira/browse/OAK-1819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-1819:
Labels: java8 java9 jenkins test (was: java8 jenkins test)
> oak-solr-core test failures on Java 8
> -
>
> Key: OAK-1819
> URL: https://issues.apache.org/jira/browse/OAK-1819
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: solr
>Affects Versions: 1.0
> Environment: {noformat}
> Apache Maven 3.1.0 (893ca28a1da9d5f51ac03827af98bb730128f9f2; 2013-06-27
> 22:15:32-0400)
> Maven home: c:\Program Files\apache-maven-3.1.0
> Java version: 1.8.0, vendor: Oracle Corporation
> Java home: c:\Program Files\Java\jdk1.8.0\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
> {noformat}
>Reporter: Jukka Zitting
>Assignee: Tommaso Teofili
>Priority: Minor
> Labels: java8, java9, jenkins, test
> Fix For: 1.8
>
>
> The following {{oak-solr-core}} test failures occur when building Oak with
> Java 8:
> {noformat}
> Failed tests:
>
> testNativeMLTQuery(org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexQueryTest):
> expected: but was:
>
> testNativeMLTQueryWithStream(org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexQueryTest):
> expected: but was:
> {noformat}
> The cause of this might well be something as simple as the test case
> incorrectly expecting a specific ordering of search results.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-1819) oak-solr-core test failures on Java 8 and later
[
https://issues.apache.org/jira/browse/OAK-1819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-1819:
Summary: oak-solr-core test failures on Java 8 and later (was:
oak-solr-core test failures on Java 8)
> oak-solr-core test failures on Java 8 and later
> ---
>
> Key: OAK-1819
> URL: https://issues.apache.org/jira/browse/OAK-1819
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: solr
>Affects Versions: 1.0
> Environment: {noformat}
> Apache Maven 3.1.0 (893ca28a1da9d5f51ac03827af98bb730128f9f2; 2013-06-27
> 22:15:32-0400)
> Maven home: c:\Program Files\apache-maven-3.1.0
> Java version: 1.8.0, vendor: Oracle Corporation
> Java home: c:\Program Files\Java\jdk1.8.0\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
> {noformat}
>Reporter: Jukka Zitting
>Assignee: Tommaso Teofili
>Priority: Minor
> Labels: java8, java9, jenkins, test
> Fix For: 1.8
>
>
> The following {{oak-solr-core}} test failures occur when building Oak with
> Java 8:
> {noformat}
> Failed tests:
>
> testNativeMLTQuery(org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexQueryTest):
> expected: but was:
>
> testNativeMLTQueryWithStream(org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexQueryTest):
> expected: but was:
> {noformat}
> The cause of this might well be something as simple as the test case
> incorrectly expecting a specific ordering of search results.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (OAK-6847) oak-solr-core test failures with java 9
[
https://issues.apache.org/jira/browse/OAK-6847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke resolved OAK-6847.
-
Resolution: Duplicate
> oak-solr-core test failures with java 9
> ---
>
> Key: OAK-6847
> URL: https://issues.apache.org/jira/browse/OAK-6847
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: solr
>Reporter: Julian Reschke
>Assignee: Tommaso Teofili
> Attachments:
> TEST-org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexIT.xml,
> org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexIT.txt,
> unit-tests.log
>
>
> {noformat}
> [ERROR] Tests run: 29, Failures: 2, Errors: 0, Skipped: 2, Time elapsed:
> 156.134 s <<< FAILURE! - in
> org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexIT
> [ERROR]
> testNativeMLTQueryWithStream(org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexIT)
> Time elapsed: 5.501 s <<< FAILURE!
> org.junit.ComparisonFailure: expected: but was:
> at
> org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexIT.testNativeMLTQueryWithStream(SolrIndexIT.java:281)
> [ERROR]
> testNativeMLTQuery(org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexIT)
> Time elapsed: 5.523 s <<< FAILURE!
> org.junit.ComparisonFailure: expected: but was:
> at
> org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexIT.testNativeMLTQuery(SolrIndexIT.java:259)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6833) LuceneIndex*Test failures
[
https://issues.apache.org/jira/browse/OAK-6833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16211404#comment-16211404
]
Julian Reschke commented on OAK-6833:
-
Disable LuceneIndexAugmentTest.nullBehavior on Windows in
[r1812662|http://svn.apache.org/r1812662]
> LuceneIndex*Test failures
> -
>
> Key: OAK-6833
> URL: https://issues.apache.org/jira/browse/OAK-6833
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Julian Reschke
>Assignee: Vikas Saurabh
> Fix For: 1.8
>
> Attachments:
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexAugmentTest.xml,
>
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexAugmentTest.xml,
>
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexAugmentTest.xml,
>
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexAugmentTest.xml,
>
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexAugmentTest.xml,
>
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.xml,
>
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.xml,
>
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.xml,
>
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.xml,
>
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.xml,
>
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.xml,
>
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.xml,
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexAugmentTest.txt,
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexAugmentTest.txt,
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexAugmentTest.txt,
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexAugmentTest.txt,
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexAugmentTest.txt,
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.txt,
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.txt,
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.txt,
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.txt,
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.txt,
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.txt,
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.txt,
> unit-tests.log, unit-tests.log, unit-tests.log
>
>
> {noformat}
> [ERROR] testLuceneWithRelativeProperty[1: useBlobStore
> (false)](org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest)
> Time elapsed: 0.063 s <<< FAILURE!
> java.lang.AssertionError: expected: but was:
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.testLuceneWithRelativeProperty(LuceneIndexEditorTest.java:341)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (OAK-6847) oak-solr-core test failures with java 9
[
https://issues.apache.org/jira/browse/OAK-6847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16211393#comment-16211393
]
Julian Reschke edited comment on OAK-6847 at 10/19/17 5:29 PM:
---
trunk: [r1812660|http://svn.apache.org/r1812660] (tests disabled under Java 9)
was (Author: reschke):
trunk: [r1812660|http://svn.apache.org/r1812660]
> oak-solr-core test failures with java 9
> ---
>
> Key: OAK-6847
> URL: https://issues.apache.org/jira/browse/OAK-6847
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: solr
>Reporter: Julian Reschke
>Assignee: Tommaso Teofili
> Attachments:
> TEST-org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexIT.xml,
> org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexIT.txt,
> unit-tests.log
>
>
> {noformat}
> [ERROR] Tests run: 29, Failures: 2, Errors: 0, Skipped: 2, Time elapsed:
> 156.134 s <<< FAILURE! - in
> org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexIT
> [ERROR]
> testNativeMLTQueryWithStream(org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexIT)
> Time elapsed: 5.501 s <<< FAILURE!
> org.junit.ComparisonFailure: expected: but was:
> at
> org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexIT.testNativeMLTQueryWithStream(SolrIndexIT.java:281)
> [ERROR]
> testNativeMLTQuery(org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexIT)
> Time elapsed: 5.523 s <<< FAILURE!
> org.junit.ComparisonFailure: expected: but was:
> at
> org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexIT.testNativeMLTQuery(SolrIndexIT.java:259)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6847) oak-solr-core test failures with java 9
[
https://issues.apache.org/jira/browse/OAK-6847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16211393#comment-16211393
]
Julian Reschke commented on OAK-6847:
-
trunk: [r1812660|http://svn.apache.org/r1812660]
> oak-solr-core test failures with java 9
> ---
>
> Key: OAK-6847
> URL: https://issues.apache.org/jira/browse/OAK-6847
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: solr
>Reporter: Julian Reschke
>Assignee: Tommaso Teofili
> Attachments:
> TEST-org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexIT.xml,
> org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexIT.txt,
> unit-tests.log
>
>
> {noformat}
> [ERROR] Tests run: 29, Failures: 2, Errors: 0, Skipped: 2, Time elapsed:
> 156.134 s <<< FAILURE! - in
> org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexIT
> [ERROR]
> testNativeMLTQueryWithStream(org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexIT)
> Time elapsed: 5.501 s <<< FAILURE!
> org.junit.ComparisonFailure: expected: but was:
> at
> org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexIT.testNativeMLTQueryWithStream(SolrIndexIT.java:281)
> [ERROR]
> testNativeMLTQuery(org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexIT)
> Time elapsed: 5.523 s <<< FAILURE!
> org.junit.ComparisonFailure: expected: but was:
> at
> org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexIT.testNativeMLTQuery(SolrIndexIT.java:259)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6847) oak-solr-core test failures with java 9
[
https://issues.apache.org/jira/browse/OAK-6847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16211157#comment-16211157
]
Julian Reschke commented on OAK-6847:
-
See OAK-1819: the tests are actually skipped under Java 8. We probably should
skip them for now under Java 9 as well.
> oak-solr-core test failures with java 9
> ---
>
> Key: OAK-6847
> URL: https://issues.apache.org/jira/browse/OAK-6847
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: solr
>Reporter: Julian Reschke
>Assignee: Tommaso Teofili
> Attachments:
> TEST-org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexIT.xml,
> org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexIT.txt,
> unit-tests.log
>
>
> {noformat}
> [ERROR] Tests run: 29, Failures: 2, Errors: 0, Skipped: 2, Time elapsed:
> 156.134 s <<< FAILURE! - in
> org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexIT
> [ERROR]
> testNativeMLTQueryWithStream(org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexIT)
> Time elapsed: 5.501 s <<< FAILURE!
> org.junit.ComparisonFailure: expected: but was:
> at
> org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexIT.testNativeMLTQueryWithStream(SolrIndexIT.java:281)
> [ERROR]
> testNativeMLTQuery(org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexIT)
> Time elapsed: 5.523 s <<< FAILURE!
> org.junit.ComparisonFailure: expected: but was:
> at
> org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexIT.testNativeMLTQuery(SolrIndexIT.java:259)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6834) Make TypeEditor publically accessible and allow pluggable constraint violation handling
[
https://issues.apache.org/jira/browse/OAK-6834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16211027#comment-16211027
]
Alex Deparvu commented on OAK-6834:
---
fixed some javadocs in http://svn.apache.org/viewvc?rev=1812639=rev
> Make TypeEditor publically accessible and allow pluggable constraint
> violation handling
> ---
>
> Key: OAK-6834
> URL: https://issues.apache.org/jira/browse/OAK-6834
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: 1.8, 1.7.10
>
>
> For OAK-6580 we need to validate node types at mount time. The logic to
> perform the validation is properly encapsulated in the
> {{org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor}} class. There are
> two issues which we need to work around:
> - the type is not accessible
> - the constraint violation handling is not pluggable - it either fails or log
> a WARN
> My proposal is to:
> - make the TypeEditor public and add a factory method for accesing it
> - add a {{ConstraintViolationCallback}} interface which must be passed in to
> the TypeEditor
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6639) ObservationQueueFullWarnTest.testQueueFullThenFlushing fails sometimes
[
https://issues.apache.org/jira/browse/OAK-6639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16210971#comment-16210971
]
Stefan Egli commented on OAK-6639:
--
[~catholicon], good idea! +1
> ObservationQueueFullWarnTest.testQueueFullThenFlushing fails sometimes
> --
>
> Key: OAK-6639
> URL: https://issues.apache.org/jira/browse/OAK-6639
> Project: Jackrabbit Oak
> Issue Type: Test
> Components: jcr
>Reporter: Vikas Saurabh
>Assignee: Stefan Egli
>Priority: Minor
> Fix For: 1.8, 1.7.8
>
> Attachments: OAK-6639.patch, archive.zip, console.txt
>
>
> Very intermittently,
> {{ObservationQueueFullWarnTest.testQueueFullThenFlushing}} fails. It had
> failed once in one of our internal CI setups. And recently (thankfully??) on
> apache setup \[0] \[1] \[2].
> Description from Apache failure:
>
> h4. Error Message
> Just filled queue must not convert local->external expected:<6> but was:<4>
> h4. Stacktrace
> {noformat}
> java.lang.AssertionError: Just filled queue must not convert local->external
> expected:<6> but was:<4>
> at
> org.apache.jackrabbit.oak.jcr.observation.ObservationQueueFullWarnTest.testQueueFullThenFlushing(ObservationQueueFullWarnTest.java:312)
> {noformat}
> h4. Standard Output
> {noformat}
> storing: /testNode/local0
> storing: /testNode/local1
> storing: /testNode/local2
> storing: /testNode/local3
> storing: /testNode/local4
> storing: /testNode/local5
> GOT: 1 - COUNTER: 1
> - Event{type=4, path=/testNode/local0, identifier=/testNode,
> info={jcr:primaryType=nt:unstructured, afterValue=0}, userID=admin,
> userData=null, date=1504862948917, external=false}
> GOT: 1 - COUNTER: 2
> - Event{type=4, path=/testNode/local1, identifier=/testNode,
> info={jcr:primaryType=nt:unstructured, afterValue=1}, userID=admin,
> userData=null, date=1504862948918, external=false}
> GOT: 1 - COUNTER: 3
> - Event{type=4, path=/testNode/local2, identifier=/testNode,
> info={jcr:primaryType=nt:unstructured, afterValue=2}, userID=admin,
> userData=null, date=1504862948919, external=false}
> GOT: 1 - COUNTER: 4
> - Event{type=4, path=/testNode/local3, identifier=/testNode,
> info={jcr:primaryType=nt:unstructured, afterValue=3}, userID=admin,
> userData=null, date=1504862948919, external=false}
> GOT: 2 - COUNTER: 6
> - Event{type=4, path=/testNode/local4, identifier=/testNode,
> info={jcr:primaryType=nt:unstructured, afterValue=4}, userID=oak:unknown,
> userData=null, date=1504862873156, external=true}
> - Event{type=4, path=/testNode/local5, identifier=/testNode,
> info={jcr:primaryType=nt:unstructured, afterValue=5}, userID=oak:unknown,
> userData=null, date=1504862873156, external=true}
> {noformat}
>
> \[0]:
> https://lists.apache.org/thread.html/9c952201c132e2c6dce67b2d4fb13d9b0040d9874514885a9ed5bc9f@%3Coak-dev.jackrabbit.apache.org%3E
> \[1]: https://builds.apache.org/job/Jackrabbit%20Oak/722/
> \[2]:
> https://builds.apache.org/job/Jackrabbit%20Oak/722/org.apache.jackrabbit$oak-jcr/testReport/junit/org.apache.jackrabbit.oak.jcr.observation/ObservationQueueFullWarnTest/testQueueFullThenFlushing_SegmentTar_/
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-6639) ObservationQueueFullWarnTest.testQueueFullThenFlushing fails sometimes
[
https://issues.apache.org/jira/browse/OAK-6639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-6639:
---
Attachment: OAK-6639.patch
[~egli], how about doing it like [^OAK-6639.patch]? That way even with
exaggerated wait for init message of 20s, faster systems are free to execute
the test faster. Of course, if this seems ok, I'd open up a new issue instead
to put that in.
> ObservationQueueFullWarnTest.testQueueFullThenFlushing fails sometimes
> --
>
> Key: OAK-6639
> URL: https://issues.apache.org/jira/browse/OAK-6639
> Project: Jackrabbit Oak
> Issue Type: Test
> Components: jcr
>Reporter: Vikas Saurabh
>Assignee: Stefan Egli
>Priority: Minor
> Fix For: 1.8, 1.7.8
>
> Attachments: OAK-6639.patch, archive.zip, console.txt
>
>
> Very intermittently,
> {{ObservationQueueFullWarnTest.testQueueFullThenFlushing}} fails. It had
> failed once in one of our internal CI setups. And recently (thankfully??) on
> apache setup \[0] \[1] \[2].
> Description from Apache failure:
>
> h4. Error Message
> Just filled queue must not convert local->external expected:<6> but was:<4>
> h4. Stacktrace
> {noformat}
> java.lang.AssertionError: Just filled queue must not convert local->external
> expected:<6> but was:<4>
> at
> org.apache.jackrabbit.oak.jcr.observation.ObservationQueueFullWarnTest.testQueueFullThenFlushing(ObservationQueueFullWarnTest.java:312)
> {noformat}
> h4. Standard Output
> {noformat}
> storing: /testNode/local0
> storing: /testNode/local1
> storing: /testNode/local2
> storing: /testNode/local3
> storing: /testNode/local4
> storing: /testNode/local5
> GOT: 1 - COUNTER: 1
> - Event{type=4, path=/testNode/local0, identifier=/testNode,
> info={jcr:primaryType=nt:unstructured, afterValue=0}, userID=admin,
> userData=null, date=1504862948917, external=false}
> GOT: 1 - COUNTER: 2
> - Event{type=4, path=/testNode/local1, identifier=/testNode,
> info={jcr:primaryType=nt:unstructured, afterValue=1}, userID=admin,
> userData=null, date=1504862948918, external=false}
> GOT: 1 - COUNTER: 3
> - Event{type=4, path=/testNode/local2, identifier=/testNode,
> info={jcr:primaryType=nt:unstructured, afterValue=2}, userID=admin,
> userData=null, date=1504862948919, external=false}
> GOT: 1 - COUNTER: 4
> - Event{type=4, path=/testNode/local3, identifier=/testNode,
> info={jcr:primaryType=nt:unstructured, afterValue=3}, userID=admin,
> userData=null, date=1504862948919, external=false}
> GOT: 2 - COUNTER: 6
> - Event{type=4, path=/testNode/local4, identifier=/testNode,
> info={jcr:primaryType=nt:unstructured, afterValue=4}, userID=oak:unknown,
> userData=null, date=1504862873156, external=true}
> - Event{type=4, path=/testNode/local5, identifier=/testNode,
> info={jcr:primaryType=nt:unstructured, afterValue=5}, userID=oak:unknown,
> userData=null, date=1504862873156, external=true}
> {noformat}
>
> \[0]:
> https://lists.apache.org/thread.html/9c952201c132e2c6dce67b2d4fb13d9b0040d9874514885a9ed5bc9f@%3Coak-dev.jackrabbit.apache.org%3E
> \[1]: https://builds.apache.org/job/Jackrabbit%20Oak/722/
> \[2]:
> https://builds.apache.org/job/Jackrabbit%20Oak/722/org.apache.jackrabbit$oak-jcr/testReport/junit/org.apache.jackrabbit.oak.jcr.observation/ObservationQueueFullWarnTest/testQueueFullThenFlushing_SegmentTar_/
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (OAK-6735) Lucene Index: improved cost estimation by using document count per field
[ https://issues.apache.org/jira/browse/OAK-6735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Saurabh reassigned OAK-6735: -- Assignee: Vikas Saurabh > Lucene Index: improved cost estimation by using document count per field > > > Key: OAK-6735 > URL: https://issues.apache.org/jira/browse/OAK-6735 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene, query >Affects Versions: 1.7.4 >Reporter: Thomas Mueller >Assignee: Vikas Saurabh > Fix For: 1.8 > > Attachments: IndexReadPattern.txt, LuceneIndexReadPattern.java > > > The cost estimation of the Lucene index is somewhat inaccurate because (by > default) it just used the number of documents in the index (as of Oak 1.7.4 > by default, due to OAK-6333). > Instead, it should use the number of documents for the given fields (the > minimum, if there are multiple fields with restrictions). > Plus divided by the number of restrictions (as we do now already). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6735) Lucene Index: improved cost estimation by using document count per field
[ https://issues.apache.org/jira/browse/OAK-6735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Saurabh updated OAK-6735: --- Attachment: (was: LuceneIndexReadPattern.java) > Lucene Index: improved cost estimation by using document count per field > > > Key: OAK-6735 > URL: https://issues.apache.org/jira/browse/OAK-6735 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene, query >Affects Versions: 1.7.4 >Reporter: Thomas Mueller > Fix For: 1.8 > > Attachments: IndexReadPattern.txt, LuceneIndexReadPattern.java > > > The cost estimation of the Lucene index is somewhat inaccurate because (by > default) it just used the number of documents in the index (as of Oak 1.7.4 > by default, due to OAK-6333). > Instead, it should use the number of documents for the given fields (the > minimum, if there are multiple fields with restrictions). > Plus divided by the number of restrictions (as we do now already). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6735) Lucene Index: improved cost estimation by using document count per field
[ https://issues.apache.org/jira/browse/OAK-6735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Saurabh updated OAK-6735: --- Attachment: LuceneIndexReadPattern.java > Lucene Index: improved cost estimation by using document count per field > > > Key: OAK-6735 > URL: https://issues.apache.org/jira/browse/OAK-6735 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene, query >Affects Versions: 1.7.4 >Reporter: Thomas Mueller > Fix For: 1.8 > > Attachments: IndexReadPattern.txt, LuceneIndexReadPattern.java, > LuceneIndexReadPattern.java > > > The cost estimation of the Lucene index is somewhat inaccurate because (by > default) it just used the number of documents in the index (as of Oak 1.7.4 > by default, due to OAK-6333). > Instead, it should use the number of documents for the given fields (the > minimum, if there are multiple fields with restrictions). > Plus divided by the number of restrictions (as we do now already). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-6710) CommitMitigated merge policy should not reduce performance significantly
[
https://issues.apache.org/jira/browse/OAK-6710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16210806#comment-16210806
]
Tommaso Teofili commented on OAK-6710:
--
in r1812608 I've committed a first auto tuning algorithm which works like this:
* the commit rate (docs and MB per second) time series is described using
[single exponential
smoothing|http://www.itl.nist.gov/div898/handbook/pmc/section4/pmc431.htm]
* when the no. of segments exceeds the maximum (currently set to 20) the
averaged and maximum commit rates are compared, if the average exceeds the
maximum the latter is increased again using SES
Currently each merge policy resets the averages (commit rates and no. of
segments) every 50 merge attempts (hence the time series has no more than 50
points).
> CommitMitigated merge policy should not reduce performance significantly
>
>
> Key: OAK-6710
> URL: https://issues.apache.org/jira/browse/OAK-6710
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Affects Versions: 1.7.7
>Reporter: Vikas Saurabh
>Assignee: Tommaso Teofili
> Labels: performance, scalability
> Fix For: 1.8
>
>
> While running performance tests (internally) using latest unstable releases
> having {{CommitMitigatedTieredMergePolicy}} we observed significant drop in
> performance (OAK-6704).
> The policy, although bad for performance, showed dramatic drop in churn
> created in data store size. So, clearly, OAK-5192 did what it intended to do.
> Opening this issue to factor in drop in performance and then set the default
> back to {{CommitMitigatedTieredMergePolicy}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6639) ObservationQueueFullWarnTest.testQueueFullThenFlushing fails sometimes
[
https://issues.apache.org/jira/browse/OAK-6639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16210753#comment-16210753
]
Stefan Egli commented on OAK-6639:
--
[~reschke], sounds good to me - increased to 5sec in rev 1812607
> ObservationQueueFullWarnTest.testQueueFullThenFlushing fails sometimes
> --
>
> Key: OAK-6639
> URL: https://issues.apache.org/jira/browse/OAK-6639
> Project: Jackrabbit Oak
> Issue Type: Test
> Components: jcr
>Reporter: Vikas Saurabh
>Assignee: Stefan Egli
>Priority: Minor
> Fix For: 1.8, 1.7.8
>
> Attachments: archive.zip, console.txt
>
>
> Very intermittently,
> {{ObservationQueueFullWarnTest.testQueueFullThenFlushing}} fails. It had
> failed once in one of our internal CI setups. And recently (thankfully??) on
> apache setup \[0] \[1] \[2].
> Description from Apache failure:
>
> h4. Error Message
> Just filled queue must not convert local->external expected:<6> but was:<4>
> h4. Stacktrace
> {noformat}
> java.lang.AssertionError: Just filled queue must not convert local->external
> expected:<6> but was:<4>
> at
> org.apache.jackrabbit.oak.jcr.observation.ObservationQueueFullWarnTest.testQueueFullThenFlushing(ObservationQueueFullWarnTest.java:312)
> {noformat}
> h4. Standard Output
> {noformat}
> storing: /testNode/local0
> storing: /testNode/local1
> storing: /testNode/local2
> storing: /testNode/local3
> storing: /testNode/local4
> storing: /testNode/local5
> GOT: 1 - COUNTER: 1
> - Event{type=4, path=/testNode/local0, identifier=/testNode,
> info={jcr:primaryType=nt:unstructured, afterValue=0}, userID=admin,
> userData=null, date=1504862948917, external=false}
> GOT: 1 - COUNTER: 2
> - Event{type=4, path=/testNode/local1, identifier=/testNode,
> info={jcr:primaryType=nt:unstructured, afterValue=1}, userID=admin,
> userData=null, date=1504862948918, external=false}
> GOT: 1 - COUNTER: 3
> - Event{type=4, path=/testNode/local2, identifier=/testNode,
> info={jcr:primaryType=nt:unstructured, afterValue=2}, userID=admin,
> userData=null, date=1504862948919, external=false}
> GOT: 1 - COUNTER: 4
> - Event{type=4, path=/testNode/local3, identifier=/testNode,
> info={jcr:primaryType=nt:unstructured, afterValue=3}, userID=admin,
> userData=null, date=1504862948919, external=false}
> GOT: 2 - COUNTER: 6
> - Event{type=4, path=/testNode/local4, identifier=/testNode,
> info={jcr:primaryType=nt:unstructured, afterValue=4}, userID=oak:unknown,
> userData=null, date=1504862873156, external=true}
> - Event{type=4, path=/testNode/local5, identifier=/testNode,
> info={jcr:primaryType=nt:unstructured, afterValue=5}, userID=oak:unknown,
> userData=null, date=1504862873156, external=true}
> {noformat}
>
> \[0]:
> https://lists.apache.org/thread.html/9c952201c132e2c6dce67b2d4fb13d9b0040d9874514885a9ed5bc9f@%3Coak-dev.jackrabbit.apache.org%3E
> \[1]: https://builds.apache.org/job/Jackrabbit%20Oak/722/
> \[2]:
> https://builds.apache.org/job/Jackrabbit%20Oak/722/org.apache.jackrabbit$oak-jcr/testReport/junit/org.apache.jackrabbit.oak.jcr.observation/ObservationQueueFullWarnTest/testQueueFullThenFlushing_SegmentTar_/
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (OAK-3878) Avoid caching of NodeDocument while iterating in BlobReferenceIterator
[
https://issues.apache.org/jira/browse/OAK-3878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16210708#comment-16210708
]
Vikas Saurabh edited comment on OAK-3878 at 10/19/17 8:03 AM:
--
I feel Julian's concern is valid in the sense that declarative javadoc should
come into play only when there's no other way to safe-guard.
I think refresh-cache-if-already-cached could be a good enough mitigating
strategy (as [~reschke]'s patch in OAK-6839 does).
That said, I was also wondering if DocumentStore could have an API which
iterates all documents and takes a tranformation method so that
BlobReferenceIterator could just ask document store to scan all documents and
map those with a method like {{Iterator> map(NodeDocument
doc);}}. Btw, I understand this is going in the direction of "we need to
re-look at DocumentStore API". I'm ok with refresh-cache strategy - just
putting the thought here for the record.
was (Author: catholicon):
I feel Julian's concern is valid in the sense that declarative javadoc should
come into play only when there's no other way to safe-guard.
I think refresh-cache-if-already-cached could be a good enough mitigating
strategy (as [~reschke]'s patch in OAK-6839 does).
That said, I was also wondering if DocumentStore could have an API which
iterates all documents and takes a tranformation method so that
BlobReferenceIterator could just ask document store to scan all documents and
map those with a method like {{ map(NodeDocument doc);}}. Btw, I
understand this is going in the direction of "we need to re-look at
DocumentStore API". I'm ok with refresh-cache strategy - just putting the
thought here for the record.
> Avoid caching of NodeDocument while iterating in BlobReferenceIterator
> --
>
> Key: OAK-3878
> URL: https://issues.apache.org/jira/browse/OAK-3878
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: documentmk
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.8
>
>
> {{BlobReferenceIterator}} in DocumentMK makes use of {{DocumentStore}} API to
> query the NodeDocument. This would cause all those NodeDocuments to be added
> to cache in DocumentStore. Due to this when blob gc is running cache usage
> would not be that effective due to all the associated churn.
> As these NodeDocument are only required for BlobGC logic and its not expected
> that this document would read again soon it would be better to skip caching
> of these documents within DocumentStore
> Similar requirement exist in VersionGC logic but there we use direct store
> based API which does not add such documents to the cache
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-3878) Avoid caching of NodeDocument while iterating in BlobReferenceIterator
[
https://issues.apache.org/jira/browse/OAK-3878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16210708#comment-16210708
]
Vikas Saurabh commented on OAK-3878:
I feel Julian's concern is valid in the sense that declarative javadoc should
come into play only when there's no other way to safe-guard.
I think refresh-cache-if-already-cached could be a good enough mitigating
strategy (as [~reschke]'s patch in OAK-6839 does).
That said, I was also wondering if DocumentStore could have an API which
iterates all documents and takes a tranformation method so that
BlobReferenceIterator could just ask document store to scan all documents and
map those with a method like {{ map(NodeDocument doc);}}. Btw, I
understand this is going in the direction of "we need to re-look at
DocumentStore API". I'm ok with refresh-cache strategy - just putting the
thought here for the record.
> Avoid caching of NodeDocument while iterating in BlobReferenceIterator
> --
>
> Key: OAK-3878
> URL: https://issues.apache.org/jira/browse/OAK-3878
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: documentmk
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.8
>
>
> {{BlobReferenceIterator}} in DocumentMK makes use of {{DocumentStore}} API to
> query the NodeDocument. This would cause all those NodeDocuments to be added
> to cache in DocumentStore. Due to this when blob gc is running cache usage
> would not be that effective due to all the associated churn.
> As these NodeDocument are only required for BlobGC logic and its not expected
> that this document would read again soon it would be better to skip caching
> of these documents within DocumentStore
> Similar requirement exist in VersionGC logic but there we use direct store
> based API which does not add such documents to the cache
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-6847) oak-solr-core test failures with java 9
[
https://issues.apache.org/jira/browse/OAK-6847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-6847:
Summary: oak-solr-core test failures with java 9 (was: oak-solr-core test
faillures with java 9)
> oak-solr-core test failures with java 9
> ---
>
> Key: OAK-6847
> URL: https://issues.apache.org/jira/browse/OAK-6847
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: solr
>Reporter: Julian Reschke
>Assignee: Tommaso Teofili
> Attachments:
> TEST-org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexIT.xml,
> org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexIT.txt,
> unit-tests.log
>
>
> {noformat}
> [ERROR] Tests run: 29, Failures: 2, Errors: 0, Skipped: 2, Time elapsed:
> 156.134 s <<< FAILURE! - in
> org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexIT
> [ERROR]
> testNativeMLTQueryWithStream(org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexIT)
> Time elapsed: 5.501 s <<< FAILURE!
> org.junit.ComparisonFailure: expected: but was:
> at
> org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexIT.testNativeMLTQueryWithStream(SolrIndexIT.java:281)
> [ERROR]
> testNativeMLTQuery(org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexIT)
> Time elapsed: 5.523 s <<< FAILURE!
> org.junit.ComparisonFailure: expected: but was:
> at
> org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexIT.testNativeMLTQuery(SolrIndexIT.java:259)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
