[jira] [Updated] (OAK-2929) Parent of unseen children must not be removable
[
https://issues.apache.org/jira/browse/OAK-2929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amit Jain updated OAK-2929:
---
Fix Version/s: (was: 1.3.7)
1.3.8
> Parent of unseen children must not be removable
> ---
>
> Key: OAK-2929
> URL: https://issues.apache.org/jira/browse/OAK-2929
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, mongomk
>Affects Versions: 1.0.13, 1.2
>Reporter: Vikas Saurabh
>Assignee: Marcel Reutegger
>Priority: Minor
> Labels: concurrency, technical_debt
> Fix For: 1.3.8, 1.2.7, 1.0.22
>
> Attachments: IgnoredTestCase.patch
>
>
> With OAK-2673, it's now possible to have hidden intermediate nodes created
> concurrently.
> So, a scenario like:
> {noformat}
> start -> /:hidden
> N1 creates /:hiddent/parent/node1
> N2 creates /:hidden/parent/node2
> {noformat}
> is allowed.
> But, if N2's creation of {{parent}} got persisted later than that on N1, then
> N2 is currently able to delete {{parent}} even though there's {{node1}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3054) IndexStatsMBean should provide some details if the async indexing is failing
[
https://issues.apache.org/jira/browse/OAK-3054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amit Jain updated OAK-3054:
---
Fix Version/s: (was: 1.3.7)
1.3.8
> IndexStatsMBean should provide some details if the async indexing is failing
>
>
> Key: OAK-3054
> URL: https://issues.apache.org/jira/browse/OAK-3054
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Chetan Mehrotra
>Priority: Minor
> Labels: resilience, tooling
> Fix For: 1.3.8, 1.2.7
>
>
> If the background indexing fails for some reason it logs the exception for
> the first time then it logs the exception like _The index update failed ..._.
> After that if indexing continues to fail then no further logging is done so
> as to avoid creating noise.
> This poses a problem on long running system where original exception might
> not be noticed and index does not show updated result. For such cases we
> should expose the indexing health as part of {{IndexStatsMBean}}. Also we can
> provide the last recorded exception.
> Administrator can then check for MBean and enable debug logs for further
> troubleshooting
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3151) Lucene Version should be based on IndexFormatVersion
[
https://issues.apache.org/jira/browse/OAK-3151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amit Jain updated OAK-3151:
---
Fix Version/s: (was: 1.3.7)
1.3.8
> Lucene Version should be based on IndexFormatVersion
>
>
> Key: OAK-3151
> URL: https://issues.apache.org/jira/browse/OAK-3151
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Labels: technical_debt
> Fix For: 1.3.8
>
>
> Currently in oak-lucene where ever call is made to Lucene it passes
> Version.LUCENE_47 as hardcoded version. To enable easier upgrade of Lucene
> and hence change of defaults for fresh setup this version should be instead
> based on {{IndexFormatVersion}}.
> Say
> * For IndexFormatVersion set to V2 (current default) - Lucene version used is
> LUCENE_47
> * For IndexFormatVersion set to V3 (proposed) - Lucene version used would be
> per Lucene library version
> If the index is reindexed then it would automatically be updated to the
> latest revision
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2656) Test failures in LDAP authentication: Failed to bind an LDAP service
[
https://issues.apache.org/jira/browse/OAK-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amit Jain updated OAK-2656:
---
Fix Version/s: (was: 1.3.7)
1.3.8
> Test failures in LDAP authentication: Failed to bind an LDAP service
>
>
> Key: OAK-2656
> URL: https://issues.apache.org/jira/browse/OAK-2656
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-ldap
> Environment: Jenkins, Ubuntu:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
>Reporter: Michael Dürig
>Assignee: Tobias Bocanegra
>Priority: Minor
> Labels: CI, Jenkins, technical_debt
> Fix For: 1.3.8
>
>
> The following tests all fail with the same error message "Failed to bind an
> LDAP service (1024) to the service registry.".
> {noformat}
> testAuthenticateFail(org.apache.jackrabbit.oak.security.authentication.ldap.LdapProviderTest):
> Failed to bind an LDAP service (1024) to the service registry.
> testGetGroups2(org.apache.jackrabbit.oak.security.authentication.ldap.LdapProviderTest):
> Failed to bind an LDAP service (1024) to the service registry.
> org.apache.jackrabbit.oak.security.authentication.ldap.LdapDefaultLoginModuleTest:
> Failed to bind an LDAP service (1024) to the service registry.
> testGetUserByUserId(org.apache.jackrabbit.oak.security.authentication.ldap.LdapProviderTest):
> Failed to bind an LDAP service (1024) to the service registry.
> {noformat}
> The stacktrace is always similar:
> {noformat}
> java.net.BindException: Address already in use]
> at
> org.apache.directory.server.ldap.LdapServer.startNetwork(LdapServer.java:528)
> at
> org.apache.directory.server.ldap.LdapServer.start(LdapServer.java:394)
> at
> org.apache.directory.server.unit.AbstractServerTest.setUp(AbstractServerTest.java:273)
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.InternalLdapServer.setUp(InternalLdapServer.java:37)
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.LdapLoginTestBase.beforeClass(LdapLoginTestBase.java:86)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Caused by: java.net.BindException: Address already in use
> at sun.nio.ch.Net.bind0(Native Method)
> at sun.nio.ch.Net.bind(Net.java:444)
> at sun.nio.ch.Net.bind(Net.java:436)
> at
> sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:214)
> at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> at
> org.apache.mina.transport.socket.nio.NioSocketAcceptor.open(NioSocketAcceptor.java:198)
> at
> org.apache.mina.transport.socket.nio.NioSocketAcceptor.open(NioSocketAcceptor.java:51)
> at
> org.apache.mina.core.polling.AbstractPollingIoAcceptor.registerHandles(AbstractPollingIoAcceptor.java:547)
> at
>
[jira] [Updated] (OAK-3149) SuggestHelper should manage a suggestor per index definition
[
https://issues.apache.org/jira/browse/OAK-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amit Jain updated OAK-3149:
---
Fix Version/s: (was: 1.3.7)
1.3.8
> SuggestHelper should manage a suggestor per index definition
>
>
> Key: OAK-3149
> URL: https://issues.apache.org/jira/browse/OAK-3149
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Tommaso Teofili
> Fix For: 1.3.8
>
>
> {{SuggestHelper}} currently keeps a static reference to suggestor and thus
> have a singleton suggestor for whole repo. Instead it should be implemented
> in such a way that a suggestor instance is associated with index definition.
> Logically the suggestor instance should be part of IndexNode similar to how
> {{IndexSearcher}} instances are managed
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-1648) Creating multiple checkpoint on same head revision overwrites previous entries
[ https://issues.apache.org/jira/browse/OAK-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-1648: --- Fix Version/s: (was: 1.3.7) 1.3.8 > Creating multiple checkpoint on same head revision overwrites previous entries > -- > > Key: OAK-1648 > URL: https://issues.apache.org/jira/browse/OAK-1648 > Project: Jackrabbit Oak > Issue Type: Bug > Components: mongomk >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Labels: resilience > Fix For: 1.3.8 > > > Currently when a checkpoint is created in DocumentNodeStore then it is saved > in form of currentHeadRev=>expiryTime. Now if multiple checkpoints are > created where head revision has not changed then only the last one would be > saved and previous entries would be overridden as revision is used as key > One fix would be to change the expiry time only if the new expiry time is > greater than previous entry. However doing that safely in a cluster (check > then save) is currently not possible with DocumentStore API as the modCount > check if only supported for Nodes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3269) Improve Lucene indexer resilience
[ https://issues.apache.org/jira/browse/OAK-3269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-3269: --- Fix Version/s: (was: 1.3.7) 1.3.8 > Improve Lucene indexer resilience > - > > Key: OAK-3269 > URL: https://issues.apache.org/jira/browse/OAK-3269 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Michael Marth > Labels: resilience > Fix For: 1.3.8 > > > As discussed bilaterally grouping the improvements for Lucene indexer > resilience in this issue for easier tracking -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2847) Dependency cleanup
[ https://issues.apache.org/jira/browse/OAK-2847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-2847: --- Fix Version/s: (was: 1.3.7) 1.3.8 > Dependency cleanup > --- > > Key: OAK-2847 > URL: https://issues.apache.org/jira/browse/OAK-2847 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Michael Dürig >Assignee: Vikas Saurabh > Labels: technical_debt > Fix For: 1.3.8 > > > Early in the next release cycle we should go through the list of Oak's > dependencies and decide whether we have candidates we want to upgrade and > remove orphaned dependencies. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3268) Improve datastore resilience
[ https://issues.apache.org/jira/browse/OAK-3268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-3268: --- Fix Version/s: (was: 1.3.7) 1.3.8 > Improve datastore resilience > > > Key: OAK-3268 > URL: https://issues.apache.org/jira/browse/OAK-3268 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: blob >Reporter: Michael Marth > Labels: resilience > Fix For: 1.3.8 > > > As discussed bilaterally grouping the improvements for datastore resilience > in this issue for easier tracking -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-1575) DocumentNS: Implement refined conflict resolution for addExistingNode conflicts
[ https://issues.apache.org/jira/browse/OAK-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-1575: --- Fix Version/s: (was: 1.3.7) 1.3.8 > DocumentNS: Implement refined conflict resolution for addExistingNode > conflicts > --- > > Key: OAK-1575 > URL: https://issues.apache.org/jira/browse/OAK-1575 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: mongomk >Reporter: Michael Dürig >Assignee: Marcel Reutegger > Labels: resilience > Fix For: 1.3.8 > > > Implement refined conflict resolution for addExistingNode conflicts as > defined in the parent issue for the document NS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2797) Closeable aspect of Analyzer should be accounted for
[
https://issues.apache.org/jira/browse/OAK-2797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amit Jain updated OAK-2797:
---
Fix Version/s: (was: 1.3.7)
1.3.8
> Closeable aspect of Analyzer should be accounted for
>
>
> Key: OAK-2797
> URL: https://issues.apache.org/jira/browse/OAK-2797
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Chetan Mehrotra
> Labels: technical_debt
> Fix For: 1.3.8
>
>
> Lucene {{Analyzer}} implements {{Closeable}} [1] interface and internally it
> has a ThreadLocal storage of some persistent resource
> So far in oak-lucene we do not take care of closing any analyzer. In fact we
> use a singleton Analyzer in all cases. Opening this bug to think about this
> aspect and see if our usage of Analyzer follows the best practices
> [1]
> http://lucene.apache.org/core/4_7_0/core/org/apache/lucene/analysis/Analyzer.html#close%28%29
> /cc [~teofili] [~alex.parvulescu]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2910) oak-jcr bundle should be usable as a standalone bundle
[ https://issues.apache.org/jira/browse/OAK-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-2910: --- Fix Version/s: (was: 1.3.7) 1.3.8 > oak-jcr bundle should be usable as a standalone bundle > -- > > Key: OAK-2910 > URL: https://issues.apache.org/jira/browse/OAK-2910 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: jcr >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Labels: modularization, osgi, technical_debt > Fix For: 1.3.8 > > > Currently oak-jcr bundle needs to be embedded within some other bundle if the > Oak needs to be properly configured in OSGi env. Need to revisit this aspect > and see what needs to be done to enable Oak to be properly configured without > requiring the oak-jcr bundle to be embedded in the repo -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3451) OrderedIndexIT fails
[
https://issues.apache.org/jira/browse/OAK-3451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amit Jain updated OAK-3451:
---
Fix Version/s: (was: 1.3.7)
1.3.8
> OrderedIndexIT fails
>
>
> Key: OAK-3451
> URL: https://issues.apache.org/jira/browse/OAK-3451
> Project: Jackrabbit Oak
> Issue Type: Bug
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
> Fix For: 1.3.8
>
>
> This test fails on oak-jcr:
> {noformat}
> mvn -PintegrationTesting clean install
> oak2035(org.apache.jackrabbit.oak.jcr.OrderedIndexIT) Time elapsed: 0.979
> sec <<< FAILURE!
> java.lang.AssertionError: both path and date failed to match. Expected:
> /content/n1412 - 2012-12-24T23:00:00.000-05:00.
> Obtained:
> /content/n1092, 2012-12-24T20:00:00.000-08:00
> at org.junit.Assert.fail(Assert.java:93)
> at
> org.apache.jackrabbit.oak.jcr.OrderedIndexIT.assertRightOrder(OrderedIndexIT.java:232)
> at
> org.apache.jackrabbit.oak.jcr.OrderedIndexIT.oak2035(OrderedIndexIT.java:203)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[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
]
Amit Jain updated OAK-1819:
---
Fix Version/s: (was: 1.3.7)
1.3.8
> 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, test
> Fix For: 1.3.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.3.4#6332)
[jira] [Updated] (OAK-2719) Warn about local copy size different than remote copy in oak-lucene with copyOnRead enabled
[
https://issues.apache.org/jira/browse/OAK-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amit Jain updated OAK-2719:
---
Fix Version/s: (was: 1.3.7)
1.3.8
> Warn about local copy size different than remote copy in oak-lucene with
> copyOnRead enabled
> ---
>
> Key: OAK-2719
> URL: https://issues.apache.org/jira/browse/OAK-2719
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Labels: resilience
> Fix For: 1.3.8
>
>
> At times following warning is seen in logs
> {noformat}
> 31.03.2015 14:04:57.610 *WARN* [pool-6-thread-7]
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopier Found local copy
> for _0.cfs in
> NIOFSDirectory@/path/to/index/e5a943cdec3000bd8ce54924fd2070ab5d1d35b9ecf530963a3583d43bf28293/1
>
> lockFactory=NativeFSLockFactory@/path/to/index/e5a943cdec3000bd8ce54924fd2070ab5d1d35b9ecf530963a3583d43bf28293/1
> but size of local 1040384 differs from remote 1958385. Content would be read
> from remote file only
> {noformat}
> The file length check provides a weak check around index file consistency. In
> some cases this warning is misleading. For e.g.
> # Index version Rev1 - Task submitted to copy index file F1
> # Index updated to Rev2 - Directory bound to Rev1 is closed
> # Read is performed with Rev2 for F1 - Here as the file would be locally
> created the size would be different as the copying is in progress
> In such a case the logic should ensure that once copy is done the local file
> gets used
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3270) Improve DocumentMK resilience
[ https://issues.apache.org/jira/browse/OAK-3270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-3270: --- Fix Version/s: (was: 1.3.7) 1.3.8 > Improve DocumentMK resilience > - > > Key: OAK-3270 > URL: https://issues.apache.org/jira/browse/OAK-3270 > Project: Jackrabbit Oak > Issue Type: Epic > Components: mongomk, rdbmk >Reporter: Michael Marth > Labels: resilience > Fix For: 1.3.8 > > > Collection of DocMK resilience improvements -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2556) do intermediate commit during async indexing
[ https://issues.apache.org/jira/browse/OAK-2556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-2556: --- Fix Version/s: (was: 1.3.7) 1.3.8 > do intermediate commit during async indexing > > > Key: OAK-2556 > URL: https://issues.apache.org/jira/browse/OAK-2556 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Affects Versions: 1.0.11 >Reporter: Stefan Egli > Labels: resilience > Fix For: 1.3.8 > > > A recent issue found at a customer unveils a potential issue with the async > indexer. Reading the AsyncIndexUpdate.updateIndex it looks like it is doing > the entire update of the async indexer *in one go*, ie in one commit. > When there is - for some reason - however, a huge diff that the async indexer > has to process, the 'one big commit' can become gigantic. There is no limit > to the size of the commit in fact. > So the suggestion is to do intermediate commits while the async indexer is > going on. The reason this is acceptable is the fact that by doing async > indexing, that index is anyway not 100% up-to-date - so it would not make > much of a difference if it would commit after every 100 or 1000 changes > either. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2879) Compaction should check for required disk space before running
[ https://issues.apache.org/jira/browse/OAK-2879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-2879: --- Fix Version/s: (was: 1.3.7) 1.3.8 > Compaction should check for required disk space before running > -- > > Key: OAK-2879 > URL: https://issues.apache.org/jira/browse/OAK-2879 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: segmentmk >Reporter: Michael Dürig >Assignee: Francesco Mari > Labels: compaction, doc-impacting, gc, resilience > Fix For: 1.3.8 > > > In the worst case compaction doubles the repository size while running. As > this is somewhat unexpected we should check whether there is enough free disk > space before running compaction and log a warning otherwise. This is to avoid > a common source of running out of disk space and ending up with a corrupted > repository. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2065) JMX stats for operations being performed in DocumentStore
[ https://issues.apache.org/jira/browse/OAK-2065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-2065: --- Fix Version/s: (was: 1.3.7) 1.3.8 > JMX stats for operations being performed in DocumentStore > - > > Key: OAK-2065 > URL: https://issues.apache.org/jira/browse/OAK-2065 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Labels: tooling > Fix For: 1.3.8 > > Attachments: > 0001-OAK-2065-JMX-stats-for-operations-being-performed-in.patch, > OAK-2065-1.patch > > > Currently DocumentStore performs various background operations like > # Cache consistency check > # Pushing the lastRev updates > # Synchrnizing the root node version > We should capture some stats like time taken in various task and expose them > over JMX to determine if those background operations are performing well or > not. For example its important that all tasks performed in background task > should be completed under 1 sec (default polling interval). If the time taken > increases then it would be cause of concern > See http://markmail.org/thread/57fax4nyabbubbef -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2891) Use more efficient approach to manage in memory map in LengthCachingDataStore
[ https://issues.apache.org/jira/browse/OAK-2891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-2891: --- Fix Version/s: (was: 1.3.7) 1.3.8 > Use more efficient approach to manage in memory map in LengthCachingDataStore > - > > Key: OAK-2891 > URL: https://issues.apache.org/jira/browse/OAK-2891 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: upgrade >Reporter: Chetan Mehrotra >Priority: Minor > Fix For: 1.3.8 > > > LengthCachingDataStore introduced in OAK-2882 has an in memory map for > keeping the mapping between blobId and length. This would pose issue when > number of binaries are very large. > Instead of in memory map we should use some off heap store like MVStore of > MapDB -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2779) DocumentNodeStore should provide option to set initial cache size as percentage of MAX VM size
[ https://issues.apache.org/jira/browse/OAK-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-2779: --- Fix Version/s: (was: 1.3.7) 1.3.8 > DocumentNodeStore should provide option to set initial cache size as > percentage of MAX VM size > -- > > Key: OAK-2779 > URL: https://issues.apache.org/jira/browse/OAK-2779 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk >Affects Versions: 1.2 >Reporter: Will McGauley > Labels: performance, resilience > Fix For: 1.3.8 > > > Currently the DocumentNodeStore provides a way to configure various cache > parameters, including cache size and distribution of that size to various > caches. The distribution of caches is done as a % of the total cache size, > which is very helpful, but the overall cache size can only be set as a > literal value. > It would be helpful to achieve a good default value based on the available VM > memory as a %, instead of a literal value. By doing this the cache size > would not need to be set by each customer, and a better initial experience > would be achieved. > I suggest that 25% of the max VM size would be a good starting point. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3253) Support caching in FileDataStoreService
[ https://issues.apache.org/jira/browse/OAK-3253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-3253: --- Fix Version/s: (was: 1.3.7) 1.3.8 > Support caching in FileDataStoreService > --- > > Key: OAK-3253 > URL: https://issues.apache.org/jira/browse/OAK-3253 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: blob >Affects Versions: 1.3.3 >Reporter: Shashank Gupta >Assignee: Shashank Gupta > Labels: candidate_oak_1_0, candidate_oak_1_2, docs-impacting, > features, performance > Fix For: 1.3.8 > > > FDS on SAN/NAS storage is not efficient as it involves network call. In OAK. > indexes are stored SAN/NAS and even idle system does lot of read system > generated data. > Enable caching in FDS so the reads are done locally and async upload to > SAN/NAS > See [previous > discussions|https://issues.apache.org/jira/browse/OAK-3005?focusedCommentId=14700801=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14700801] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2722) IndexCopier fails to delete older index directory upon reindex
[
https://issues.apache.org/jira/browse/OAK-2722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amit Jain updated OAK-2722:
---
Fix Version/s: (was: 1.3.7)
1.3.8
> IndexCopier fails to delete older index directory upon reindex
> --
>
> Key: OAK-2722
> URL: https://issues.apache.org/jira/browse/OAK-2722
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Labels: resilience
> Fix For: 1.3.8
>
>
> {{IndexCopier}} tries to remove the older index directory incase of reindex.
> This might fails on platform like Windows if the files are still memory
> mapped or are locked.
> For deleting directories we would need to take similar approach like being
> done with deleting old index files i.e. do retries later.
> Due to this following test fails on Windows (Per [~julian.resc...@gmx.de] )
> {noformat}
> Tests run: 9, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.07 sec <<<
> FAILURE!
> deleteOldPostReindex(org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopierTest)
> Time elapsed: 0.02 sec <<< FAILURE!
> java.lang.AssertionError: Old index directory should have been removed
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.assertTrue(Assert.java:43)
> at org.junit.Assert.assertFalse(Assert.java:68)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopierTest.deleteOldPostReindex(IndexCopierTest.java:160)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-1695) Document Solr index
[ https://issues.apache.org/jira/browse/OAK-1695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-1695: --- Fix Version/s: (was: 1.3.7) 1.3.8 > Document Solr index > --- > > Key: OAK-1695 > URL: https://issues.apache.org/jira/browse/OAK-1695 > Project: Jackrabbit Oak > Issue Type: Task > Components: doc, solr >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > Labels: documentation > Fix For: 1.3.8 > > > Provide documentation about the Oak Solr index. That should contain > information about the design and how to configure it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2622) dynamic cache allocation
[ https://issues.apache.org/jira/browse/OAK-2622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-2622: --- Fix Version/s: (was: 1.3.7) 1.3.8 > dynamic cache allocation > > > Key: OAK-2622 > URL: https://issues.apache.org/jira/browse/OAK-2622 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk >Affects Versions: 1.0.12 >Reporter: Stefan Egli > Labels: performance, resilience > Fix For: 1.3.8 > > > At the moment mongoMk's various caches are configurable (OAK-2546) but other > than that static in terms of size. Different use-cases might require > different allocations of the sub caches though. And it might not always be > possible to find a good configuration upfront for all use cases. > We might be able to come up with dynamically allocating the overall cache > size to the different sub-caches, based on which cache is how heavily loaded > or how well performing for example. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2808) Active deletion of 'deleted' Lucene index files from DataStore without relying on full scale Blob GC
[ https://issues.apache.org/jira/browse/OAK-2808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-2808: --- Fix Version/s: (was: 1.3.7) 1.3.8 > Active deletion of 'deleted' Lucene index files from DataStore without > relying on full scale Blob GC > > > Key: OAK-2808 > URL: https://issues.apache.org/jira/browse/OAK-2808 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Chetan Mehrotra >Assignee: Thomas Mueller > Labels: datastore, performance > Fix For: 1.3.8 > > Attachments: OAK-2808-1.patch, copyonread-stats.png > > > With storing of Lucene index files within DataStore our usage pattern > of DataStore has changed between JR2 and Oak. > With JR2 the writes were mostly application based i.e. if application > stores a pdf/image file then that would be stored in DataStore. JR2 by > default would not write stuff to DataStore. Further in deployment > where large number of binary content is present then systems tend to > share the DataStore to avoid duplication of storage. In such cases > running Blob GC is a non trivial task as it involves a manual step and > coordination across multiple deployments. Due to this systems tend to > delay frequency of GC > Now with Oak apart from application the Oak system itself *actively* > uses the DataStore to store the index files for Lucene and there the > churn might be much higher i.e. frequency of creation and deletion of > index file is lot higher. This would accelerate the rate of garbage > generation and thus put lot more pressure on the DataStore storage > requirements. > Discussion thread http://markmail.org/thread/iybd3eq2bh372zrl -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3355) Test failure: SpellcheckTest.testSpellcheckMultipleWords
[
https://issues.apache.org/jira/browse/OAK-3355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amit Jain updated OAK-3355:
---
Fix Version/s: (was: 1.3.7)
1.3.8
> Test failure: SpellcheckTest.testSpellcheckMultipleWords
>
>
> Key: OAK-3355
> URL: https://issues.apache.org/jira/browse/OAK-3355
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: solr
> Environment:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
>Reporter: Michael Dürig
> Labels: ci, jenkins, test-failure
> Fix For: 1.3.8
>
>
> {{org.apache.jackrabbit.oak.jcr.query.SpellcheckTest.testSpellcheckMultipleWords}}
> fails on Jenkins.
> Failure seen at builds: 389, 392, 395, 396
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/396/jdk=jdk-1.6u45,label=Ubuntu,nsfixtures=DOCUMENT_RDB,profile=unittesting/console
> {noformat}
> testSpellcheckMultipleWords(org.apache.jackrabbit.oak.jcr.query.SpellcheckTest)
> Time elapsed: 0.907 sec <<< FAILURE!
> junit.framework.ComparisonFailure: expected:<[voting[ in] ontario]> but
> was:<[voting[, voted,] ontario]>
> at junit.framework.Assert.assertEquals(Assert.java:85)
> at junit.framework.Assert.assertEquals(Assert.java:91)
> at
> org.apache.jackrabbit.oak.jcr.query.SpellcheckTest.testSpellcheckMultipleWords(SpellcheckTest.java:86)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (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 ] Amit Jain updated OAK-3159: --- Fix Version/s: (was: 1.3.7) 1.3.8 > 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: Improvement > Components: doc >Reporter: Konrad Windszus > Fix For: 1.3.8 > > > 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-3236) integration test that simulates influence of clock drift
[ https://issues.apache.org/jira/browse/OAK-3236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-3236: --- Fix Version/s: (was: 1.3.7) 1.3.8 > integration test that simulates influence of clock drift > > > Key: OAK-3236 > URL: https://issues.apache.org/jira/browse/OAK-3236 > Project: Jackrabbit Oak > Issue Type: Test > Components: core >Affects Versions: 1.3.4 >Reporter: Stefan Egli >Assignee: Stefan Egli > Fix For: 1.3.8 > > > Spin-off of OAK-2739 [of this > comment|https://issues.apache.org/jira/browse/OAK-2739?focusedCommentId=14693398=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14693398] > - ie there should be an integration test that show cases the issues with > clock drift and why it is a good idea to have a lease-check (that refuses to > let the document store be used any further once the lease times out locally) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3215) Solr test often fail with No such core: oak
[
https://issues.apache.org/jira/browse/OAK-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amit Jain updated OAK-3215:
---
Fix Version/s: (was: 1.3.7)
1.3.8
> Solr test often fail with No such core: oak
>
>
> Key: OAK-3215
> URL: https://issues.apache.org/jira/browse/OAK-3215
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: solr
>Reporter: Chetan Mehrotra
>Assignee: Tommaso Teofili
>Priority: Minor
> Labels: CI
> Fix For: 1.3.8
>
>
> Often it can be seen that all test from oak-solr module fail. And in all such
> failure following error is reported
> {noformat}
> org.apache.solr.common.SolrException: No such core: oak
> at
> org.apache.solr.client.solrj.embedded.EmbeddedSolrServer.request(EmbeddedSolrServer.java:112)
> at
> org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:118)
> at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:116)
> at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:102)
> at
> org.apache.jackrabbit.oak.plugins.index.solr.query.SolrQueryIndexTest.testQueryOnIgnoredExistingProperty(SolrQueryIndexTest.java:330)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> {noformat}
> Most recent failure in
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/325/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-937) Query engine index selection tweaks: shortcut and hint
[ https://issues.apache.org/jira/browse/OAK-937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-937: -- Fix Version/s: (was: 1.3.7) 1.3.8 > Query engine index selection tweaks: shortcut and hint > -- > > Key: OAK-937 > URL: https://issues.apache.org/jira/browse/OAK-937 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, query >Reporter: Alex Parvulescu >Priority: Minor > Labels: performance > Fix For: 1.3.8 > > > This issue covers 2 different changes related to the way the QueryEngine > selects a query index: > Firstly there could be a way to end the index selection process early via a > known constant value: if an index returns a known value token (like -1000) > then the query engine would effectively stop iterating through the existing > index impls and use that index directly. > Secondly it would be nice to be able to specify a desired index (if one is > known to perform better) thus skipping the existing selection mechanism (cost > calculation and comparison). This could be done via certain query hints [0]. > [0] http://en.wikipedia.org/wiki/Hint_(SQL) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2477) Move suggester specific config to own configuration node
[ https://issues.apache.org/jira/browse/OAK-2477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-2477: --- Fix Version/s: (was: 1.3.7) 1.3.8 > Move suggester specific config to own configuration node > > > Key: OAK-2477 > URL: https://issues.apache.org/jira/browse/OAK-2477 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > Labels: technical_debt > Fix For: 1.3.8 > > > Currently suggester configuration is controlled via properties defined on > main config / props node but it'd be good if we would have its own place to > configure the whole suggest feature to not mix up configuration of other > features / parameters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-318) Excerpt support
[
https://issues.apache.org/jira/browse/OAK-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amit Jain updated OAK-318:
--
Fix Version/s: (was: 1.3.7)
1.3.8
> Excerpt support
> ---
>
> Key: OAK-318
> URL: https://issues.apache.org/jira/browse/OAK-318
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: core, query
>Reporter: Alex Parvulescu
> Fix For: 1.3.8
>
>
> Test class: ExcerptTest.
> Right now I only see parse errors:
> Caused by: java.text.ParseException: Query:
> {noformat}
> testroot/*[jcr:contains(., 'jackrabbit')]/rep:excerpt((*).); expected:
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2911) Analyze inter package dependency in oak-core
[
https://issues.apache.org/jira/browse/OAK-2911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amit Jain updated OAK-2911:
---
Fix Version/s: (was: 1.3.7)
1.3.8
> Analyze inter package dependency in oak-core
>
>
> Key: OAK-2911
> URL: https://issues.apache.org/jira/browse/OAK-2911
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: core
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Labels: modularization, technical_debt
> Fix For: 1.3.8
>
> Attachments: oak-core-jdepend-report.html
>
>
> For better code health the packages should have proper inter dependency. Its
> preferable that various {{plugin}} packages within oak-core have minimal
> inter dependency and should be able to exist independently.
> Following work need to be performed
> # Check whats the current state
> # Look into ways to ensure that such dependency are minimal and at minimum
> must not have cycle
> See
> *
> http://stackoverflow.com/questions/3416547/maven-jdepend-fail-build-with-cycles
> * https://github.com/andrena/no-package-cycles-enforcer-rule
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3450) Configuration to have case insensitive suggestions
[
https://issues.apache.org/jira/browse/OAK-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amit Jain updated OAK-3450:
---
Fix Version/s: (was: 1.3.7)
1.3.8
> Configuration to have case insensitive suggestions
> --
>
> Key: OAK-3450
> URL: https://issues.apache.org/jira/browse/OAK-3450
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
> Fix For: 1.3.8
>
>
> Currently suggestions follow the same case as requested in query parameter.
> It makes sense to allow for it to be case insensitive. e.g. Asking for
> suggestions for {{cat}} should give {{Cat is an animal}} as well as
> {{category needs to be assigned}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2618) Improve performance of queries with ORDER BY and multiple OR filters
[ https://issues.apache.org/jira/browse/OAK-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-2618: --- Fix Version/s: (was: 1.3.7) 1.3.8 > Improve performance of queries with ORDER BY and multiple OR filters > > > Key: OAK-2618 > URL: https://issues.apache.org/jira/browse/OAK-2618 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Amit Jain >Assignee: Amit Jain > Labels: performance > Fix For: 1.3.8 > > > When multiple OR constraints are specified in the XPATH query, itis broken up > into union of multiple clauses. If query includes an order by clause, the > sorting in this case is done by traversing the result set in memory leading > to slow query performance. > Possible improvements could include: > * For indexes which can support multiple filters (like lucene, solr) such > queries should be efficient and the query engine can pass-thru the query as > is. > ** Possibly also needed for other cases also. So, we can have some sort of > capability advertiser for indexes which can hint the query engine > and/or > * Batched merging of the sorted iterators returned for the multiple union > queries (possible externally). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-1557) Mark documents as deleted
[ https://issues.apache.org/jira/browse/OAK-1557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-1557: --- Fix Version/s: (was: 1.3.7) 1.3.8 > Mark documents as deleted > - > > Key: OAK-1557 > URL: https://issues.apache.org/jira/browse/OAK-1557 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk >Reporter: Marcel Reutegger >Assignee: Chetan Mehrotra > Labels: performance, resilience > Fix For: 1.3.8 > > > This is an improvement to make a certain use case more efficient. When there > is a parent node with frequently added and removed child nodes, the reading > of the current list of child nodes becomes inefficient because the decision > whether a node exists at a certain revision is done in the DocumentNodeStore > and no filtering is done on the MongoDB side. > So far we figured this would be solved automatically by the MVCC garbage > collection, when documents for deleted nodes are removed. However for > locations in the repository where nodes are added and deleted again > frequently (think of a temp folder), the issue pops up before the GC had a > chance to clean up. > The Document should have an additional field, which is set when the node is > deleted in the most recent revision. Based on this field the > DocumentNodeStore can limit the query to MongoDB to documents that are not > deleted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3090) Caching BlobStore implementation
[ https://issues.apache.org/jira/browse/OAK-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-3090: --- Fix Version/s: (was: 1.3.7) 1.3.8 > Caching BlobStore implementation > - > > Key: OAK-3090 > URL: https://issues.apache.org/jira/browse/OAK-3090 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: blob >Reporter: Chetan Mehrotra > Labels: performance, resilience > Fix For: 1.3.8 > > > Storing binaries in Mongo puts lots of pressure on the MongoDB for reads. To > reduce the read load it would be useful to have a filesystem based cache of > frequently used binaries. > This would be similar to CachingFDS (OAK-3005) but would be implemented on > top of BlobStore API. > Requirements > * Specify the max binary size which can be cached on file system > * Limit the size of all binary content present in the cache -- 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
]
Amit Jain updated OAK-3219:
---
Fix Version/s: (was: 1.3.7)
1.3.8
> 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: Chetan Mehrotra
>Priority: Minor
> Labels: performance
> Fix For: 1.3.8
>
>
> 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
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3452) Document possible migration options
[ https://issues.apache.org/jira/browse/OAK-3452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-3452: --- Fix Version/s: (was: 1.3.7) 1.3.8 > Document possible migration options > --- > > Key: OAK-3452 > URL: https://issues.apache.org/jira/browse/OAK-3452 > Project: Jackrabbit Oak > Issue Type: Documentation > Components: doc, upgrade >Reporter: Tomek Rękawek > Fix For: 1.3.8 > > > Document the oak-upgrade tool and the [SplitBlobStore|OAK-3148] migration on > the project page. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-1610) Improved default indexing by JCR type in SolrIndexEditor
[ https://issues.apache.org/jira/browse/OAK-1610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-1610: --- Fix Version/s: (was: 1.3.7) 1.3.8 > Improved default indexing by JCR type in SolrIndexEditor > > > Key: OAK-1610 > URL: https://issues.apache.org/jira/browse/OAK-1610 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: solr >Reporter: Tommaso Teofili > Fix For: 1.3.8 > > > It'd be good to provide a typed indexing default so that properties of a > certain type can be mapped to certain Solr dynamic fields with dedicated > types. The infrastructure for doing that is already in place as per > OakSolrConfiguration#getFieldNameFor(Type) but the default configuration is > not properly set with a good mapping. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3335) RepositorySidegrade has runtime dependency on jackrabbit-core
[
https://issues.apache.org/jira/browse/OAK-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amit Jain updated OAK-3335:
---
Fix Version/s: (was: 1.3.7)
1.3.8
> RepositorySidegrade has runtime dependency on jackrabbit-core
> -
>
> Key: OAK-3335
> URL: https://issues.apache.org/jira/browse/OAK-3335
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: upgrade
>Affects Versions: 1.3.5
>Reporter: Julian Sedding
>Assignee: Julian Sedding
> Fix For: 1.3.8
>
>
> It should be possible to run {{RepositorySidegrade}} from a runnable jar file
> that does not embed {{jackrabbit-core}}. E.g. once {{RepositorySidegrade}} is
> enabled in {{oak-run}}, it shoudl work in the variant that does not embed
> jackrabbit-core.
> OAK-3239 introduced a transitive runtime dependency from
> {{RepositorySidegrade}} to {{RepositoryUpgrade}} (via static imports), which
> has dependencies to classes in {{jackrabbit-core}}. This leads to failure
> with a {{ClassNotFoundException}}.
> Moving the constants and static method to {{RepositorySidegrade}} and
> importing them in {{RepositoryUpgrade}} instead should resolve the issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3295) Test failure: NodeTypeTest.trivialUpdates
[
https://issues.apache.org/jira/browse/OAK-3295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amit Jain updated OAK-3295:
---
Fix Version/s: (was: 1.3.7)
1.3.8
> Test failure: NodeTypeTest.trivialUpdates
> -
>
> Key: OAK-3295
> URL: https://issues.apache.org/jira/browse/OAK-3295
> Project: Jackrabbit Oak
> Issue Type: Bug
> Environment: Jenkins, Ubuntu:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
>Reporter: Michael Dürig
> Labels: CI, Jenkins
> Fix For: 1.3.8
>
>
> {{org.apache.jackrabbit.oak.jcr.nodetype.NodeTypeTest.trivialUpdates}} fails
> on Jenkins when running the {{DOCUMENT_RDB}} fixture.
> Failure seen at builds: 236, 249, 253, 297, 357
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/357/jdk=latest1.7,label=Ubuntu,nsfixtures=DOCUMENT_RDB,profile=unittesting/console
> {noformat}
> trivialUpdates[0](org.apache.jackrabbit.oak.jcr.nodetype.NodeTypeTest) Time
> elapsed: 10.066 sec <<< ERROR!
> javax.jcr.InvalidItemStateException: Failed to register node types.
> at
> org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:239)
> at
> org.apache.jackrabbit.oak.plugins.nodetype.write.ReadWriteNodeTypeManager.registerNodeTypes(ReadWriteNodeTypeManager.java:156)
> at
> org.apache.jackrabbit.oak.jcr.nodetype.NodeTypeTest.trivialUpdates(NodeTypeTest.java:188)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:24)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.jackrabbit.oak.api.CommitFailedException: OakMerge0001:
> OakMerge0001: Failed to merge changes to the underlying store (retries 5,
> 3624 ms)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge0(DocumentNodeStoreBranch.java:183)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge(DocumentNodeStoreBranch.java:123)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentRootBuilder.merge(DocumentRootBuilder.java:158)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.merge(DocumentNodeStore.java:1526)
> at
> org.apache.jackrabbit.oak.core.MutableRoot.commit(MutableRoot.java:247)
> at
> org.apache.jackrabbit.oak.core.MutableRoot.commit(MutableRoot.java:258)
> at
> org.apache.jackrabbit.oak.plugins.nodetype.write.ReadWriteNodeTypeManager.registerNodeTypes(ReadWriteNodeTypeManager.java:145)
> ... 27 more
> Caused by: org.apache.jackrabbit.oak.plugins.document.DocumentStoreException:
> update of 3:/jcr:system/jcr:nodeTypes/mix:created failed, race condition?
> at
> org.apache.jackrabbit.oak.plugins.document.rdb.RDBDocumentStore.internalCreateOrUpdate(RDBDocumentStore.java:830)
> at
>
[jira] [Updated] (OAK-2478) Move spellcheck config to own configuration node
[ https://issues.apache.org/jira/browse/OAK-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-2478: --- Fix Version/s: (was: 1.3.7) 1.3.8 > Move spellcheck config to own configuration node > > > Key: OAK-2478 > URL: https://issues.apache.org/jira/browse/OAK-2478 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Tommaso Teofili > Labels: technical_debt > Fix For: 1.3.8 > > > Currently spellcheck configuration is controlled via properties defined on > main config / props node but it'd be good if we would have its own place to > configure the whole spellcheck feature to not mix up configuration of other > features / parameters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3285) Datastore performance improvements
[ https://issues.apache.org/jira/browse/OAK-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-3285: --- Fix Version/s: (was: 1.3.7) 1.3.8 > Datastore performance improvements > -- > > Key: OAK-3285 > URL: https://issues.apache.org/jira/browse/OAK-3285 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: blob >Reporter: Michael Marth > Labels: performance > Fix For: 1.3.8 > > > Collector issue for DS performance improvements -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3405) Avoid instanceof check in LastRevRecoveryAgent
[ https://issues.apache.org/jira/browse/OAK-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-3405: --- Fix Version/s: (was: 1.3.7) 1.3.8 > Avoid instanceof check in LastRevRecoveryAgent > -- > > Key: OAK-3405 > URL: https://issues.apache.org/jira/browse/OAK-3405 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, mongomk >Affects Versions: 1.3.4 >Reporter: Marcel Reutegger > Labels: technical_debt > Fix For: 1.3.8 > > > Similar to OAK-3390, the instanceof check in LastRevRecoveryAgent does not > work when the MongoDocumentStore is wrapped. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2629) Cleanup Oak Travis jobs
[ https://issues.apache.org/jira/browse/OAK-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-2629: --- Fix Version/s: (was: 1.3.7) 1.3.8 > Cleanup Oak Travis jobs > --- > > Key: OAK-2629 > URL: https://issues.apache.org/jira/browse/OAK-2629 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: it >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > Labels: CI > Fix For: 1.3.8 > > > Since we're moving toward Jenkins, let's remove the Travis jobs for Oak. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3092) Cache recently extracted text to avoid duplicate extraction
[
https://issues.apache.org/jira/browse/OAK-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amit Jain updated OAK-3092:
---
Fix Version/s: (was: 1.3.7)
1.3.8
> Cache recently extracted text to avoid duplicate extraction
> ---
>
> Key: OAK-3092
> URL: https://issues.apache.org/jira/browse/OAK-3092
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Labels: performance
> Fix For: 1.3.8
>
>
> It can happen that text can be extracted from same binary multiple times in a
> given indexing cycle. This can happen due to 2 reasons
> # Multiple Lucene indexes indexing same node - A system might have multiple
> Lucene indexes e.g. a global Lucene index and an index for specific nodeType.
> In a given indexing cycle same file would be picked up by both index
> definition and both would extract same text
> # Aggregation - With Index time aggregation same file get picked up multiple
> times due to aggregation rules
> To avoid the wasted effort for duplicate text extraction from same file in a
> given indexing cycle it would be better to have an expiring cache which can
> hold on to extracted text content for some time. The cache should have
> following features
> # Limit on total size
> # Way to expire the content using [Timed
> Evicition|https://code.google.com/p/guava-libraries/wiki/CachesExplained#Timed_Eviction]
> - As chances of same file getting picked up are high only for a given
> indexing cycle it would be better to expire the cache entries after some time
> to avoid hogging memory unnecessarily
> Such a cache would provide following benefit
> # Avoid duplicate text extraction - Text extraction is costly and has to be
> minimized on critical path of {{indexEditor}}
> # Avoid expensive IO specially if binary content are to be fetched from a
> remote {{BlobStore}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3284) Query performance improvements
[ https://issues.apache.org/jira/browse/OAK-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-3284: --- Fix Version/s: (was: 1.3.7) 1.3.8 > Query performance improvements > -- > > Key: OAK-3284 > URL: https://issues.apache.org/jira/browse/OAK-3284 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene, query >Reporter: Michael Marth > Labels: performance > Fix For: 1.3.8 > > > Collector issue for various performance improvements on query engine and > Lucene indexer -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3368) Speed up ExternalPrivateStoreIT and ExternalSharedStoreIT
[ https://issues.apache.org/jira/browse/OAK-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-3368: --- Fix Version/s: (was: 1.3.7) 1.3.8 > Speed up ExternalPrivateStoreIT and ExternalSharedStoreIT > - > > Key: OAK-3368 > URL: https://issues.apache.org/jira/browse/OAK-3368 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: tarmk-standby >Reporter: Marcel Reutegger >Assignee: Manfred Baedke > Fix For: 1.3.8 > > > Both tests run for more than 5 minutes. Most of the time the tests are > somehow stuck in shutting down the server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3193) Integrate with Felix WebConsole
[ https://issues.apache.org/jira/browse/OAK-3193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-3193: --- Fix Version/s: (was: 1.3.7) 1.3.8 > Integrate with Felix WebConsole > --- > > Key: OAK-3193 > URL: https://issues.apache.org/jira/browse/OAK-3193 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: webapp >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: 1.3.8 > > > To allow better debugging support of repository setup it would be useful if > Felix WebConsole is configured with the webapp. This would allow easier > access to OSGi runtime state -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3406) Configuration to rank exact match suggestions over partial match suggestions
[
https://issues.apache.org/jira/browse/OAK-3406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amit Jain updated OAK-3406:
---
Fix Version/s: (was: 1.3.7)
1.3.8
> Configuration to rank exact match suggestions over partial match suggestions
>
>
> Key: OAK-3406
> URL: https://issues.apache.org/jira/browse/OAK-3406
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
> Fix For: 1.3.8
>
>
> Currently, a suggestion query ranks the results according to popularity. But,
> at times, it's intended to have suggested phrases based on exact matches to
> be ranked above a more popular suggestion based on a partial match. e.g. a
> repository might have a 1000 docs with {{windows is a very popular OS}} and
> say 4 with {{win over them}} - it's a useful case to configure suggestions
> such that for a suggestions query for {{win}}, we'd get {{win over them}} as
> a higher ranked suggestion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3166) Apply adjustments for newly exported JackrabbitSession#getItemOrNull
[ https://issues.apache.org/jira/browse/OAK-3166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-3166: --- Fix Version/s: (was: 1.3.7) 1.3.8 > Apply adjustments for newly exported JackrabbitSession#getItemOrNull > > > Key: OAK-3166 > URL: https://issues.apache.org/jira/browse/OAK-3166 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: jcr >Affects Versions: 1.3.3 >Reporter: Joel Richard >Assignee: Dominique Jäggi > Fix For: 1.3.8 > > Attachments: > 0001-OAK-3166-Apply-adjustments-for-newly-exported-Jackra.patch > > > Once the patch for JCR-3870 has been applied, there are a few cosmetic > adjustments necessary and test coverage should be increased. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3378) Test failure: SuggestTest
[
https://issues.apache.org/jira/browse/OAK-3378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amit Jain updated OAK-3378:
---
Fix Version/s: (was: 1.3.7)
1.3.8
> Test failure: SuggestTest
> -
>
> Key: OAK-3378
> URL: https://issues.apache.org/jira/browse/OAK-3378
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: solr
>Reporter: Chetan Mehrotra
>Assignee: Tommaso Teofili
> Labels: ci, jenkins
> Fix For: 1.3.8
>
>
> Various testcases in SuggestTest test are failing on *1.0 branch* for past
> few runs 390, 391, 394, 398
> {noformat}
> testSuggestSql(org.apache.jackrabbit.oak.jcr.query.SuggestTest) Time
> elapsed: 7.963 sec <<< FAILURE!
> junit.framework.ComparisonFailure: expected:<[[{term=in 2015 a red fox is
> still a fox,weight=1}, {term=in 2015 my fox is red, like mike's fox and
> john's fox,weight=1}]]> but was:<[]>
> at junit.framework.Assert.assertEquals(Assert.java:85)
> at junit.framework.Assert.assertEquals(Assert.java:91)
> at
> org.apache.jackrabbit.oak.jcr.query.SuggestTest.testSuggestSql(SuggestTest.java:50)
> testSuggestXPath(org.apache.jackrabbit.oak.jcr.query.SuggestTest) Time
> elapsed: 0.149 sec <<< FAILURE!
> junit.framework.ComparisonFailure: expected:<[[{term=in 2015 a red fox is
> still a fox,weight=1}, {term=in 2015 my fox is red, like mike's fox and
> john's fox,weight=1}]]> but was:<[]>
> at junit.framework.Assert.assertEquals(Assert.java:85)
> at junit.framework.Assert.assertEquals(Assert.java:91)
> at
> org.apache.jackrabbit.oak.jcr.query.SuggestTest.testSuggestXPath(SuggestTest.java:67)
>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3388) Inconsistent read in cluster with clock differences
[ https://issues.apache.org/jira/browse/OAK-3388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-3388: --- Fix Version/s: (was: 1.3.7) 1.3.8 > Inconsistent read in cluster with clock differences > --- > > Key: OAK-3388 > URL: https://issues.apache.org/jira/browse/OAK-3388 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, mongomk >Affects Versions: 1.0, 1.2 >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Labels: resilience > Fix For: 1.3.8 > > Attachments: OAK-3388.patch > > > This issue is similar to OAK-2929 but related to how the DocumentNodeStore > reads a node state when there is a clock difference between multiple cluster > nodes. The node state read from a NodeDocument may not be correct when there > is a clock difference. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2675) Include change type information in perf logs for diff logic
[
https://issues.apache.org/jira/browse/OAK-2675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amit Jain updated OAK-2675:
---
Fix Version/s: (was: 1.3.7)
1.3.8
> Include change type information in perf logs for diff logic
> ---
>
> Key: OAK-2675
> URL: https://issues.apache.org/jira/browse/OAK-2675
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Chetan Mehrotra
>Priority: Minor
> Labels: observation, performance, resilience, tooling
> Fix For: 1.3.8
>
>
> Currently the diff perf logs in {{NodeObserver}} does not indicate what type
> of change was processed i.e. was the change an internal one or an external
> one.
> Having this information would allow us to determine how the cache is being
> used. For e.g. if we see slower number even for local changes then that would
> indicate that there is some issue with the diff cache and its not be being
> utilized effectively
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-2623) Add test for GC of previous docs of a deleted document
[ https://issues.apache.org/jira/browse/OAK-2623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved OAK-2623. -- Resolution: Fixed Applied the patch with 1705603 > Add test for GC of previous docs of a deleted document > -- > > Key: OAK-2623 > URL: https://issues.apache.org/jira/browse/OAK-2623 > Project: Jackrabbit Oak > Issue Type: Task > Components: mongomk >Reporter: Chetan Mehrotra >Assignee: Vikas Saurabh >Priority: Minor > Labels: CI, technical_debt > Fix For: 1.3.8 > > Attachments: OAK-2623.patch > > > As > [noted|https://issues.apache.org/jira/browse/OAK-2557?focusedCommentId=14358704#comment-14358704] > by [~tmueller] we do not have a test coverage for case when a deleted > document has previous documents and Version GC should also remove those > previous documents -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3367) Boosting fields not working as expected
[
https://issues.apache.org/jira/browse/OAK-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-3367:
-
Fix Version/s: 1.0.22
> Boosting fields not working as expected
> ---
>
> Key: OAK-3367
> URL: https://issues.apache.org/jira/browse/OAK-3367
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.3.6, 1.2.6, 1.0.22
>
> Attachments: OAK-3367.patch
>
>
> When the boost support was added the intention was to support a usecase like
> {quote}
> For the fulltext search on a node where the fulltext content is derived from
> multiple field it should be possible to boost specific text contributed by
> individual field. Meaning that if a title field is boosted more than
> description, the title (part) in the fulltext field will mean more than the
> description (part) in the fulltext field.
> {quote}
> This would enable a user to perform a search like
> _/jcr:root/content/geometrixx-outdoors/en//element(*,
> cq:Page)\[jcr:contains(., 'Keyword')\]_ and get a result where pages having
> 'Keyword' in title come above in search result compared to those where
> Keyword is found in description.
> Current implementation just sets the boost while add the field value to
> fulltext field with the intention that Lucene would use the boost as
> explained above. However it does not work like that and boost value gets
> multiplies with other field and hence boosting does not work as expected
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-3412) Node name having non space whitspace chars should not be allowed
[
https://issues.apache.org/jira/browse/OAK-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved OAK-3412.
--
Resolution: Fixed
Fix Version/s: (was: 1.3.8)
1.3.7
Done
* trunk - 1705005
* 1.0 - 1705601
* 1.2 - 1705602
> Node name having non space whitspace chars should not be allowed
>
>
> Key: OAK-3412
> URL: https://issues.apache.org/jira/browse/OAK-3412
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.3.7, 1.2.7, 1.0.22
>
> Attachments: OAK-3412.patch
>
>
> Due to the changes done in OAK-1174 node with non space whitespace chars like
> '\n', '\r' etc can be created. This is not desirable and also JR2 does not
> allow such node to be created so check must be added to prevent such a name
> from getting created.
> As discussed in [1] this is regression due to usage of incorrect utility
> method as part of [2] the fix can be simply using a
> {{Character#isWhitespace}} instead of {{Character#isSpaceChar}}
> [1]
> http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201509.mbox/%3CCAHCW-mkkGtxkn%2B9xfXuvMTfgykewjMPsLwrVH%2B00%2BXaBQjA0sg%40mail.gmail.com%3E
> [2]
> https://github.com/apache/jackrabbit-oak/commit/342809f7f04221782ca6bbfbde9392ec4ff441c2
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3436) Prevent missing checkpoint due to unstable topology from causing complete reindexing
[
https://issues.apache.org/jira/browse/OAK-3436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amit Jain updated OAK-3436:
---
Fix Version/s: (was: 1.3.7)
1.3.8
> Prevent missing checkpoint due to unstable topology from causing complete
> reindexing
>
>
> Key: OAK-3436
> URL: https://issues.apache.org/jira/browse/OAK-3436
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.3.8, 1.2.7, 1.0.22
>
> Attachments: AsyncIndexUpdateClusterTest.java, OAK-3436-0.patch
>
>
> Async indexing logic relies on embedding application to ensure that async
> indexing job is run as a singleton in a cluster. For Sling based apps it
> depends on Sling Discovery support. At times it is being seen that if
> topology is not stable then different cluster nodes can consider them as
> leader and execute the async indexing job concurrently.
> This can cause problem as both cluster node might not see same repository
> state (due to write skew and eventual consistency) and might remove the
> checkpoint which other cluster node is still relying upon. For e.g. consider
> a 2 node cluster N1 and N2 where both are performing async indexing.
> # Base state - CP1 is the checkpoint for "async" job
> # N2 starts indexing and removes changes CP1 to CP2. For Mongo the
> checkpoints are saved in {{settings}} collection
> # N1 also decides to execute indexing but has yet not seen the latest
> repository state so still thinks that CP1 is the base checkpoint and tries to
> read it. However CP1 is already removed from {{settings}} and this makes N1
> think that checkpoint is missing and it decides to reindex everything!
> To avoid this topology must be stable but at Oak level we should still handle
> such a case and avoid doing a full reindexing. So we would need to have a
> {{MissingCheckpointStrategy}} similar to {{MissingIndexEditorStrategy}} as
> done in OAK-2203
> Possible approaches
> # A1 - Fail the indexing run if checkpoint is missing - Checkpoint being
> missing can have valid reason and invalid reason. Need to see what are valid
> scenarios where a checkpoint can go missing
> # A2 - When a checkpoint is created also store the creation time. When a
> checkpoint is found to be missing and its a *recent* checkpoint then fail the
> run. For e.g. we would fail the run till checkpoint found to be missing is
> less than an hour old (for just started take startup time into account)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3412) Node name having non space whitspace chars should not be allowed
[
https://issues.apache.org/jira/browse/OAK-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amit Jain updated OAK-3412:
---
Fix Version/s: (was: 1.3.7)
1.3.8
> Node name having non space whitspace chars should not be allowed
>
>
> Key: OAK-3412
> URL: https://issues.apache.org/jira/browse/OAK-3412
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.3.8, 1.2.7, 1.0.22
>
> Attachments: OAK-3412.patch
>
>
> Due to the changes done in OAK-1174 node with non space whitespace chars like
> '\n', '\r' etc can be created. This is not desirable and also JR2 does not
> allow such node to be created so check must be added to prevent such a name
> from getting created.
> As discussed in [1] this is regression due to usage of incorrect utility
> method as part of [2] the fix can be simply using a
> {{Character#isWhitespace}} instead of {{Character#isSpaceChar}}
> [1]
> http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201509.mbox/%3CCAHCW-mkkGtxkn%2B9xfXuvMTfgykewjMPsLwrVH%2B00%2BXaBQjA0sg%40mail.gmail.com%3E
> [2]
> https://github.com/apache/jackrabbit-oak/commit/342809f7f04221782ca6bbfbde9392ec4ff441c2
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
