[jira] [Updated] (OAK-5488) BackgroundObserver MBean report Listener class again
[
https://issues.apache.org/jira/browse/OAK-5488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-5488:
--
Fix Version/s: (was: 1.12.0)
> BackgroundObserver MBean report Listener class again
>
>
> Key: OAK-5488
> URL: https://issues.apache.org/jira/browse/OAK-5488
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, jcr
>Affects Versions: 1.5.18
>Reporter: Stefan Eissing
>Priority: Minor
> Fix For: 1.14.0
>
>
> The MBean stats for {{BackgroundObserverStats}} used to give the className of
> the listening class.
> With the introduction of {{FilteringDispatcher}} all MBeans only list that
> class name, making it difficult to find out which observer really is shown.
> Proposal: show the effective className as before again.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-6833) LuceneIndex*Test failures
[
https://issues.apache.org/jira/browse/OAK-6833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-6833:
--
Fix Version/s: (was: 1.12.0)
> 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
>Priority: Major
> Fix For: 1.14.0
>
> 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
(v7.6.3#76005)
[jira] [Updated] (OAK-6309) Not always convert XPath "primaryType in a, b" to union
[
https://issues.apache.org/jira/browse/OAK-6309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-6309:
--
Fix Version/s: (was: 1.12.0)
> Not always convert XPath "primaryType in a, b" to union
> ---
>
> Key: OAK-6309
> URL: https://issues.apache.org/jira/browse/OAK-6309
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Critical
> Fix For: 1.14.0
>
>
> Currently, queries with multiple primary types are always converted to a
> "union", but this is not alway the best solution. The main problem is that
> results are not sorted by score as expected. Example:
> {noformat}
> /jcr:root/content//element(*, nt:hierarchyNode)[jcr:contains(., 'abc)
> and (@jcr:primaryType = 'acme:Page' or @jcr:primaryType = 'acme:Asset')]
> {noformat}
> This is currently converted to a union, even if the same index is used for
> buth subqueries (assuming there is an index on nt:hierarchyNode).
> A workaround is to use:
> {noformat}
> /jcr:root/content//element(*, nt:hierarchyNode)[jcr:contains(., 'abc)
> and (./@jcr:primaryType = 'acme:Page' or ./@jcr:primaryType = 'acme:Asset')]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-6619) Async indexer thread may get stuck in CopyOnWriteDirectory close method
[
https://issues.apache.org/jira/browse/OAK-6619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-6619:
--
Fix Version/s: (was: 1.12.0)
> Async indexer thread may get stuck in CopyOnWriteDirectory close method
> ---
>
> Key: OAK-6619
> URL: https://issues.apache.org/jira/browse/OAK-6619
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Critical
> Fix For: 1.14.0
>
> Attachments: status-threaddump-Sep-5.txt
>
>
> With copy-on-write mode enabled at times its seen that async index thread
> remain stuck in CopyOnWriteDirectory#close method
> {noformat}
> "async-index-update-async" prio=5 tid=0xb9e63 nid=0x timed_waiting
>java.lang.Thread.State: TIMED_WAITING
> at sun.misc.Unsafe.park(Native Method)
> - waiting to lock <0x2504cd51> (a
> java.util.concurrent.CountDownLatch$Sync) owned by "null" tid=0x-1
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnWriteDirectory.close(CopyOnWriteDirectory.java:221)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.writer.DefaultIndexWriter.updateSuggester(DefaultIndexWriter.java:177)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.writer.DefaultIndexWriter.close(DefaultIndexWriter.java:121)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorContext.closeWriter(LuceneIndexEditorContext.java:136)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditor.leave(LuceneIndexEditor.java:154)
> at
> org.apache.jackrabbit.oak.plugins.index.IndexUpdate.leave(IndexUpdate.java:357)
> at
> org.apache.jackrabbit.oak.spi.commit.VisibleEditor.leave(VisibleEditor.java:60)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:56)
> at
> org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate.updateIndex(AsyncIndexUpdate.java:727)
> at
> org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate.runWhenPermitted(AsyncIndexUpdate.java:572)
> at
> org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate.run(AsyncIndexUpdate.java:431)
> - locked <0x3d542de5> (a
> org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate)
> at
> org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:245)
> at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> The thread is waiting on a latch and no other thread is going to release the
> latch.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-2538) Support index time aggregation in Solr index
[ https://issues.apache.org/jira/browse/OAK-2538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-2538: -- Fix Version/s: (was: 1.12.0) > Support index time aggregation in Solr index > > > Key: OAK-2538 > URL: https://issues.apache.org/jira/browse/OAK-2538 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: solr >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili >Priority: Major > Labels: performance > Fix For: 1.14.0 > > > Solr index is only able to do query time aggregation while that "would not > perform well for multi term searches as each term involves a separate call > and with intersection cursor being used the operation might result in reading > up all match terms even when user accesses only first page", therefore it'd > be good to implement index time aggregation like in Lucene index. (/cc > [~chetanm]) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6973) Define public/internal packages
[ https://issues.apache.org/jira/browse/OAK-6973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6973: -- Fix Version/s: (was: 1.12.0) > Define public/internal packages > --- > > Key: OAK-6973 > URL: https://issues.apache.org/jira/browse/OAK-6973 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Marcel Reutegger >Priority: Major > Fix For: 1.14.0 > > > As part of the Oak modularization packages previously exported without a > version will at some point have to adhere to proper semantic versioning. See > also OAK-3919 and its sub-tasks. > Since some of those packages are not meant to be used outside of Oak, there > should be a mechanism to define which exported packages are public and which > are considered internal. While semantic versioning rules apply to both > categories, we may want to provide different guarantees/guidance to consumers > of those packages. E.g. increasing the major version of a package used only > by Oak has less impact compared to a major version increase of a 'public' > package used by many applications. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-5792) TarMK: Implement tooling to repair broken nodes
[
https://issues.apache.org/jira/browse/OAK-5792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-5792:
--
Fix Version/s: (was: 1.12.0)
> TarMK: Implement tooling to repair broken nodes
> ---
>
> Key: OAK-5792
> URL: https://issues.apache.org/jira/browse/OAK-5792
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: run, segment-tar
>Reporter: Michael Dürig
>Assignee: Andrei Dulceanu
>Priority: Major
> Labels: production, technical_debt, tooling
> Fix For: 1.14.0
>
>
> With {{oak-run check}} we can determine the last good revision of a
> repository and use it to manually roll back a corrupted segment store.
> Complementary to this we should implement a tool to roll forward a broken
> revision to a fixed new revision. Such a tool needs to detect which items are
> affected by a corruption and replace these items with markers. With this the
> repository could brought back online and the markers could be used to
> identify the locations in the tree where further manual action might be
> needed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-6566) Generate markdown files from metatype description
[ https://issues.apache.org/jira/browse/OAK-6566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6566: -- Fix Version/s: (was: 1.12.0) > Generate markdown files from metatype description > - > > Key: OAK-6566 > URL: https://issues.apache.org/jira/browse/OAK-6566 > Project: Jackrabbit Oak > Issue Type: Task > Components: doc >Reporter: Chetan Mehrotra >Priority: Major > Fix For: 1.14.0 > > > Currently we maintain some documentation around supporting configuration > options for few components at [1]. Same information is also captured in > metatype annotation. > We should look into generating these md file from metatype. This can possibly > be done via a new maven plugin [2] > [1] http://jackrabbit.apache.org/oak/docs/osgi_config.html > [2] https://github.com/TouK/metatype-exporter-maven-plugin -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-5655) TarMK: Analyse locality of reference
[ https://issues.apache.org/jira/browse/OAK-5655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-5655: -- Fix Version/s: 1.14.0 > TarMK: Analyse locality of reference > - > > Key: OAK-5655 > URL: https://issues.apache.org/jira/browse/OAK-5655 > Project: Jackrabbit Oak > Issue Type: Task > Components: segment-tar >Reporter: Michael Dürig >Priority: Major > Labels: scalability > Fix For: 1.12.0, 1.14.0 > > Attachments: compaction-time-vs-reposize.m, > compaction-time-vs.reposize.png, data00053a.tar-reads.png, offrc.jfr, > segment-per-path-compacted-nocache.png, > segment-per-path-compacted-nostringcache.png, segment-per-path-compacted.png, > segment-per-path.png, segment-reads.png > > > We need to better understand the locality aspects of content stored in TarMK: > * How is related content spread over segments? > * What content do we consider related? > * How does locality of related content develop over time when changes are > applied? > * What changes do we consider typical? > * What is the impact of compaction on locality? > * What is the impact of the deduplication caches on locality (during normal > operation and during compaction)? > * How good are checkpoints deduplicated? Can we monitor this online? > * ... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7504) Include dynamic commit information in the persisted repository data
[ https://issues.apache.org/jira/browse/OAK-7504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7504: -- Fix Version/s: (was: 1.12.0) > Include dynamic commit information in the persisted repository data > --- > > Key: OAK-7504 > URL: https://issues.apache.org/jira/browse/OAK-7504 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar >Reporter: Francesco Mari >Priority: Minor > Fix For: 1.14.0 > > > The data in the Segment Store doesn't provide any information about the > dynamic behaviour of the system. For example, who performed the commit? How > many commits were performed from the same committer? > In order to simplify debugging the dynamic behaviour of a system, it should > be possible to store metadata about the commit in the super-root generated by > that commit. For example, the following information might be attached to the > super-root: > * The name of the thread performing the commit. This solution might prove > expensive in terms of consumed disk space, but would be the most precise tool > to identify the author of a commit. > * A hash of the thread name. If storing thread names proves expensive, a hash > of the thread name can be stored instead. This doesn't allow to exactly > identify the author of the commit, but would allow us to correlated different > commits as performed by the same thread. > * Both the thread name and its hash, with the thread name stored only every > Nth commit. This solution is not as precise as storing the thread name for > every commit but, if there is a frequent committer, its thread name will be > more likely to be sampled, thus providing a precise identity to a thread name > hash. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6346) Set baseline plugin comparison for trunk to latest stable version
[ https://issues.apache.org/jira/browse/OAK-6346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6346: -- Fix Version/s: (was: 1.12.0) > Set baseline plugin comparison for trunk to latest stable version > - > > Key: OAK-6346 > URL: https://issues.apache.org/jira/browse/OAK-6346 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Major > Fix For: 1.14.0 > > Attachments: OAK-6346-v1.patch, release-process-v1.patch > > > The purpose of baseline plugin is to ensure that any change in api get > reflected in exported version of the package. Currently the baseline plugin > compares against the immediate previous version. > This causes issue with unstable branches where new features are being > implemented and which evolve over few minor release on the trunk. In such > cases its possible that a new method expose in 1.7.1 gets removed later in > 1.7.2 (as happened in OAK-6337). > It would be better to configure baseline plugin to check against releases > from stable branch so that we can ensure that package versions are properly > aligned against stable versions -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-5787) BlobStore should be Closeable
[
https://issues.apache.org/jira/browse/OAK-5787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-5787:
--
Fix Version/s: (was: 1.12.0)
> BlobStore should be Closeable
> -
>
> Key: OAK-5787
> URL: https://issues.apache.org/jira/browse/OAK-5787
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: blob
>Reporter: Julian Reschke
>Assignee: Amit Jain
>Priority: Minor
> Fix For: 1.14.0
>
>
> {{DocumentNodeStore}} currently calls {{close()}} if the blob store instance
> implements {{Closeable}}.
> This has led to problems where wrapper implementations did not implement it,
> and thus the actual blob store instance wasn't properly shut down.
> Proposal: make {{BlobStore}} extend {{Closeable}} and get rid of all
> {{instanceof}} checks.
> [~tmueller] [~amitjain] - feedback appreciated.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-5739) Misleading traversal warning for spellcheck queries without index
[
https://issues.apache.org/jira/browse/OAK-5739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-5739:
--
Fix Version/s: (was: 1.12.0)
> Misleading traversal warning for spellcheck queries without index
> -
>
> Key: OAK-5739
> URL: https://issues.apache.org/jira/browse/OAK-5739
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.14.0
>
>
> In OAK-4313 we avoid traversal for native queries, but we see in some cases
> traversal warnings as follows:
> {noformat}
> org.apache.jackrabbit.oak.query.QueryImpl query plan
> [nt:base] as [a] /* traverse "" where (spellcheck([a], 'NothingToFind'))
> and (issamenode([a], [/])) */
> org.apache.jackrabbit.oak.query.QueryImpl Traversal query (query without
> index):
> select [jcr:path], [jcr:score], [rep:spellcheck()] from [nt:base] as a where
> spellcheck('NothingToFind')
> and issamenode(a, '/')
> /* xpath: /jcr:root
> [rep:spellcheck('NothingToFind')]/(rep:spellcheck()) */;
> consider creating an index
> {noformat}
> This warning is misleading. If no index is available, then either the query
> should fail, or the warning should say that the query result is not correct
> because traversal is used.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-1838) NodeStore API: divergence in contract and implementations
[ https://issues.apache.org/jira/browse/OAK-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-1838: -- Fix Version/s: (was: 1.12.0) > NodeStore API: divergence in contract and implementations > - > > Key: OAK-1838 > URL: https://issues.apache.org/jira/browse/OAK-1838 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: Michael Dürig >Assignee: Marcel Reutegger >Priority: Major > Fix For: 1.14.0 > > > Currently there is a gap between what the API mandates and what the document > and kernel node stores implement. This hinders further evolution of the Oak > stack as implementers must always be aware of non explicit design > requirements. We should look into ways we could close this gap by bringing > implementation and specification closer towards each other. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6911) Provide a way to tune inline size while storing binaries
[ https://issues.apache.org/jira/browse/OAK-6911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6911: -- Fix Version/s: (was: 1.12.0) > Provide a way to tune inline size while storing binaries > > > Key: OAK-6911 > URL: https://issues.apache.org/jira/browse/OAK-6911 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar >Reporter: Chetan Mehrotra >Priority: Major > Labels: performance, scalability > Fix For: 1.14.0 > > > SegmentNodeStore currently inlines binaries of size less that 16KB > (Segment.MEDIUM_LIMIT) even if external BlobStore is configured. > Due to this behaviour quite a bit of segment tar storage consist of blob > data. In one setup out of 370 GB segmentstore size 290GB is due to inlined > binary. If most of this binary content is moved to BlobStore then it would > allow same repository to work better in lesser RAM > So it would be useful if some way is provided to disable this default > behaviour and let BlobStore take control of inline size i.e. in presence of > BlobStore no inlining is attempted by SegmentWriter. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-5990) Add properties filtering support to OakEventFilter
[ https://issues.apache.org/jira/browse/OAK-5990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-5990: -- Fix Version/s: (was: 1.12.0) > Add properties filtering support to OakEventFilter > -- > > Key: OAK-5990 > URL: https://issues.apache.org/jira/browse/OAK-5990 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: jcr >Affects Versions: 1.6.1 >Reporter: Stefan Egli >Priority: Major > Fix For: 1.14.0 > > > SLING-6164 introduced a _property name hint_ which, when set, allows to limit > the observation events to only include those that affect at least one of the > those properties listed. The advantage is to be further able to reduce the > events sent out. This feature has not yet been implemented on the oak side. > Thus we should add this to the OakEventFilter. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-4614) Collection of observation resilience issues
[ https://issues.apache.org/jira/browse/OAK-4614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-4614: -- Fix Version/s: 1.14.0 > Collection of observation resilience issues > --- > > Key: OAK-4614 > URL: https://issues.apache.org/jira/browse/OAK-4614 > Project: Jackrabbit Oak > Issue Type: Epic > Components: core, documentmk, jcr >Reporter: Marcel Reutegger >Priority: Major > Fix For: 1.12.0, 1.14.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7321) Test failure: DocumentNodeStoreIT.modifiedResetWithDiff
[
https://issues.apache.org/jira/browse/OAK-7321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-7321:
--
Fix Version/s: (was: 1.12.0)
> Test failure: DocumentNodeStoreIT.modifiedResetWithDiff
> ---
>
> Key: OAK-7321
> URL: https://issues.apache.org/jira/browse/OAK-7321
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration, documentmk
>Reporter: Hudson
>Priority: Major
> Fix For: 1.14.0
>
>
> No description is provided
> The build Jackrabbit Oak #1295 has failed.
> First failed run: [Jackrabbit Oak
> #1295|https://builds.apache.org/job/Jackrabbit%20Oak/1295/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/1295/console]
> {noformat}
> org.apache.jackrabbit.oak.plugins.document.DocumentStoreException: Configured
> cluster node id 1 already in use: machineId/instanceId do not match:
> mac:0242454078e1//home/jenkins/jenkins-slave/workspace/Jackrabbit
> Oak/oak-store-document !=
> mac:0242d5bcc8f8//home/jenkins/jenkins-slave/workspace/Jackrabbit
> Oak/oak-store-document
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreIT.modifiedResetWithDiff(DocumentNodeStoreIT.java:65)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7193) DataStore: API to retrieve statistic (file headers, size estimation)
[
https://issues.apache.org/jira/browse/OAK-7193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-7193:
--
Fix Version/s: (was: 1.12.0)
> DataStore: API to retrieve statistic (file headers, size estimation)
>
>
> Key: OAK-7193
> URL: https://issues.apache.org/jira/browse/OAK-7193
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: blob
>Reporter: Thomas Mueller
>Priority: Major
> Fix For: 1.14.0
>
>
> Extension of OAK-6254: in addition to retrieving the size, it would be good
> to retrieve the estimated number and total size per file type. A simple (and
> in my view sufficient) solution is to use the first few bytes ("magic
> numbers", 2 bytes should be enough) to get the file type. That would allow to
> estimate, for example, the number of, and total size, of PDF files, JPEG,
> Lucene index and so on. A histogram would be nice as well, but I think is not
> needed.
> To speed up calculation, the blob ID could be extended with the first 2 bytes
> of the file content, that is: #@ where magic is the
> first two bytes, in hex. That would allow to quickly get the data from the
> blob ids (no need to actually read content).
> Sampling should be enough. The longer it takes, the more accurate the data.
> We could store the data while doing datastore GC, in which case the returned
> data would be somewhat stale; that's OK.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-6759) Convert oak-blob-cloud-azure to OSGi R6 annotations
[ https://issues.apache.org/jira/browse/OAK-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6759: -- Fix Version/s: (was: 1.12.0) > Convert oak-blob-cloud-azure to OSGi R6 annotations > --- > > Key: OAK-6759 > URL: https://issues.apache.org/jira/browse/OAK-6759 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: blob-cloud >Reporter: Robert Munteanu >Priority: Major > Fix For: 1.14.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7254) Indexes with excludedPaths, or includedPaths should not be picked for queries without path
[
https://issues.apache.org/jira/browse/OAK-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-7254:
--
Fix Version/s: (was: 1.12.0)
> Indexes with excludedPaths, or includedPaths should not be picked for queries
> without path
> --
>
> Key: OAK-7254
> URL: https://issues.apache.org/jira/browse/OAK-7254
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene, query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Critical
> Fix For: 1.14.0
>
>
> Queries that don't have a clear path restriction should not use indexes that
> have excludedPaths or includedPaths set, except in some exceptional cases (to
> be defined).
> For example, if a query doesn't have a path restriction, say:
> {noformat}
> /jcr:root//element(*, nt:base)[@status='RUNNING']
> {noformat}
> Then an index that has excludedPaths set (for example to /etc) shouldn't be
> used, at least not if a different index is available. Currently it is used
> currently, actually in _favor_ of another index, if the property "status" is
> commonly used in /etc. Because of that, the index that doesn't have
> excludedPath has a higher cost (as it indexes the property "status" in /etc,
> and so has more entries for "status", than the index that doesn't index /etc).
> The same for includedPaths, in case queryPaths isn't set to the same value(s).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-6387) Building an index (new index + reindex): temporarily store blob references
[ https://issues.apache.org/jira/browse/OAK-6387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6387: -- Fix Version/s: (was: 1.12.0) > Building an index (new index + reindex): temporarily store blob references > -- > > Key: OAK-6387 > URL: https://issues.apache.org/jira/browse/OAK-6387 > Project: Jackrabbit Oak > Issue Type: Bug > Components: lucene, query >Reporter: Thomas Mueller >Priority: Major > Fix For: 1.14.0 > > > If reindexing a Lucene index takes multiple days, and if datastore garbage > collection (DSGC) is run during that time, then DSGC may remove binaries of > that index because they are not referenced. > It would be good if all binaries that are needed, and that are older than > (for example) one hour, are referenced during reindexing (for example in a > temporary location). So that DSGC will not remove them. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-5927) Load excerpt lazily
[
https://issues.apache.org/jira/browse/OAK-5927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-5927:
--
Fix Version/s: (was: 1.12.0)
> Load excerpt lazily
> ---
>
> Key: OAK-5927
> URL: https://issues.apache.org/jira/browse/OAK-5927
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Chetan Mehrotra
>Priority: Major
> Labels: performance
> Fix For: 1.14.0
>
>
> Currently LucenePropertyIndex loads the excerpt eagerly in batch as part of
> loadDocs call. The load docs batch size doubles starting from 50 (max 100k)
> as more data is read.
> We should look into ways to make the excerpt loaded lazily as and when caller
> ask for excerpt.
> Note that currently the excerpt are only loaded when query request for
> excerpt i.e. there is a not null property restriction for {{rep:excerpt}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-5860) Compressed segments
[ https://issues.apache.org/jira/browse/OAK-5860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-5860: -- Fix Version/s: (was: 1.12.0) > Compressed segments > --- > > Key: OAK-5860 > URL: https://issues.apache.org/jira/browse/OAK-5860 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: segment-tar >Reporter: Michael Dürig >Assignee: Andrei Dulceanu >Priority: Major > Labels: scalability > Fix For: 1.14.0 > > > It would be interesting to see the effect of compressing the segments within > the tar files with a sufficiently effective and performant compression > algorithm: > * Can we increase overall throughput by trading CPU for IO? > * Can we scale to bigger repositories (in number of nodes) by squeezing in > more segments per MB and thus pushing out onset of thrashing? > * What would be a good compression algorithm/library? > * Can/should we make this optional? > * Migration and compatibility issues? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7358) Remove all usage of java.security.acl.Group for Java 13
[ https://issues.apache.org/jira/browse/OAK-7358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7358: -- Fix Version/s: (was: 1.12.0) > Remove all usage of java.security.acl.Group for Java 13 > --- > > Key: OAK-7358 > URL: https://issues.apache.org/jira/browse/OAK-7358 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: security >Reporter: Alex Deparvu >Assignee: Alex Deparvu >Priority: Major > Fix For: 1.14.0 > > > Followup of OAK-7024 for the actual removal of the Group class from the > codebase to be java 11 compliant. > Not sure what to use for 'fix version', I went with 1.9.0 so this remains on > the radar, but we can push it out as needed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[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
]
Davide Giannella updated OAK-3219:
--
Fix Version/s: (was: 1.12.0)
> Lucene IndexPlanner should also account for number of property constraints
> evaluated while giving cost estimation
> -
>
> Key: OAK-3219
> URL: https://issues.apache.org/jira/browse/OAK-3219
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Thomas Mueller
>Priority: Minor
> Labels: performance
> Fix For: 1.14.0
>
>
> 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
(v7.6.3#76005)
[jira] [Updated] (OAK-4643) Support multiple readers in suggester, spellcheck and faceted search
[ https://issues.apache.org/jira/browse/OAK-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-4643: -- Fix Version/s: (was: 1.12.0) > Support multiple readers in suggester, spellcheck and faceted search > > > Key: OAK-4643 > URL: https://issues.apache.org/jira/browse/OAK-4643 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Chetan Mehrotra >Priority: Major > Fix For: 1.14.0 > > > As part of OAK-4566 normal search has been modified to support multiple > readers. However for suggester, spellcheck and faceted search the logic is > still working with the assumption of single reader. > Those parts need to be adapted to support multiple readers -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-5272) Expose BlobStore API to provide information whether blob id is content hashed
[ https://issues.apache.org/jira/browse/OAK-5272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-5272: -- Fix Version/s: (was: 1.12.0) > Expose BlobStore API to provide information whether blob id is content hashed > - > > Key: OAK-5272 > URL: https://issues.apache.org/jira/browse/OAK-5272 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: blob >Reporter: Amit Jain >Assignee: Thomas Mueller >Priority: Major > Fix For: 1.14.0 > > > As per discussion in OAK-5253 it's better to have some information from the > BlobStore(s) whether the blob id can be solely relied upon for comparison. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7423) Document the proc tree
[ https://issues.apache.org/jira/browse/OAK-7423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7423: -- Fix Version/s: (was: 1.12.0) > Document the proc tree > -- > > Key: OAK-7423 > URL: https://issues.apache.org/jira/browse/OAK-7423 > Project: Jackrabbit Oak > Issue Type: Documentation > Components: segment-tar >Reporter: Francesco Mari >Assignee: Francesco Mari >Priority: Major > Labels: technical_debt > Fix For: 1.14.0 > > > The proc tree, contributed in OAK-7416, lacks Javadoc and high-level > documentation. In particular, the exposed content structure should be > described in greater detail. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-3150) Update Lucene to 6.x series
[ https://issues.apache.org/jira/browse/OAK-3150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-3150: -- Fix Version/s: (was: 1.12.0) > Update Lucene to 6.x series > --- > > Key: OAK-3150 > URL: https://issues.apache.org/jira/browse/OAK-3150 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Chetan Mehrotra >Assignee: Tommaso Teofili >Priority: Major > Labels: technical_debt > Fix For: 1.14.0 > > > We should look into updating the Lucene version to 6.x. Java 8 is the minimum > Java version required > Note this is to be done for trunk only -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6761) Convert oak-blob-plugins to OSGi R6 annotations
[ https://issues.apache.org/jira/browse/OAK-6761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6761: -- Fix Version/s: (was: 1.12.0) > Convert oak-blob-plugins to OSGi R6 annotations > --- > > Key: OAK-6761 > URL: https://issues.apache.org/jira/browse/OAK-6761 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: blob-plugins >Reporter: Robert Munteanu >Priority: Major > Fix For: 1.14.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-3866) Sorting on relative properties doesn't work in Solr
[
https://issues.apache.org/jira/browse/OAK-3866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-3866:
--
Fix Version/s: (was: 1.12.0)
> Sorting on relative properties doesn't work in Solr
> ---
>
> Key: OAK-3866
> URL: https://issues.apache.org/jira/browse/OAK-3866
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: solr
>Affects Versions: 1.0.22, 1.2.9, 1.3.13
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
>Priority: Major
> Fix For: 1.14.0
>
>
> Executing a query like
> {noformat}
> /jcr:root/content/foo//*[(@sling:resourceType = 'x' or @sling:resourceType =
> 'y') and jcr:contains(., 'bar*~')] order by jcr:content/@jcr:primaryType
> descending
> {noformat}
> would assume sorting on the _jcr:primaryType_ property of resulting nodes'
> _jcr:content_ children.
> That is currently not supported in Solr, while it is in Lucene as the latter
> supports index time aggregation.
> We should inspect if it's possible to extend support for Solr too, most
> probably via index time aggregation.
> The query should not fail but at least log a warning about that limitation
> for the time being.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-6225) Analyse changing the persistence format of GroupImpl
[ https://issues.apache.org/jira/browse/OAK-6225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6225: -- Fix Version/s: 1.14.0 > Analyse changing the persistence format of GroupImpl > > > Key: OAK-6225 > URL: https://issues.apache.org/jira/browse/OAK-6225 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: Alex Deparvu >Assignee: Alex Deparvu >Priority: Major > Fix For: 1.12.0, 1.14.0 > > Attachments: groupimpl-v0.patch, groupimpl-v1.patch, > groupimpl-v2.patch > > > As suggested on OAK-3933, I'd like to look into using a different persistence > format for the GroupImpl members. > Currently this is saved as a list of child nodes, and I'd like to bench this > against a tree based approach where each sub child node represents a part of > the key so it can be used for lookup. > WIP branch can be found at [0], I merged all the commits so far into a single > one to reduce the noise. > fyi [~anchela] > [0] > https://github.com/apache/jackrabbit-oak/compare/trunk...stillalex:oak-6225 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6765) Convert oak-jcr to OSGi R6 annotations
[ https://issues.apache.org/jira/browse/OAK-6765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6765: -- Fix Version/s: (was: 1.12.0) > Convert oak-jcr to OSGi R6 annotations > -- > > Key: OAK-6765 > URL: https://issues.apache.org/jira/browse/OAK-6765 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: jcr >Reporter: Robert Munteanu >Priority: Major > Fix For: 1.14.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7412) Make oak-solr extend from oak-search
[ https://issues.apache.org/jira/browse/OAK-7412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7412: -- Fix Version/s: (was: 1.12.0) > Make oak-solr extend from oak-search > > > Key: OAK-7412 > URL: https://issues.apache.org/jira/browse/OAK-7412 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: oak-search >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili >Priority: Major > Fix For: 1.14.0 > > > Once Oak Search module is ready, Oak Solr should be refactored so that it > extends from oak-search SPIs. > Both implementation and extensive testing (regression, performance) should be > conducted to make sure nothing is lost during this transition. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7744) Persistent cache for the Segment Node Store
[
https://issues.apache.org/jira/browse/OAK-7744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-7744:
--
Fix Version/s: (was: 1.12.0)
> Persistent cache for the Segment Node Store
> ---
>
> Key: OAK-7744
> URL: https://issues.apache.org/jira/browse/OAK-7744
> Project: Jackrabbit Oak
> Issue Type: Story
> Components: segment-tar
>Reporter: Tomek Rękawek
>Assignee: Tomek Rękawek
>Priority: Major
> Fix For: 1.14.0
>
> Attachments: OAK-7744.patch
>
>
> With the introduction of custom, remote persistence mechanisms for the
> SegmentMK (namely the Azure Segment Store), it makes sense to create another
> level of cache, apart from the on-heap segment cache which is currently used.
> Let's implement the persistent cache, using the existing {{TarFiles}} class
> and storing the processed segments on disk. It may be created as a
> pass-through {{SegmentNodeStorePersistence}} implementation, so it can be
> composed with other existing persistence implementations, eg. [split
> persistence|OAK-7735].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-6264) Test failure: IllegalArgumentException during upgrade tests
[
https://issues.apache.org/jira/browse/OAK-6264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-6264:
--
Fix Version/s: (was: 1.12.0)
> Test failure: IllegalArgumentException during upgrade tests
>
>
> Key: OAK-6264
> URL: https://issues.apache.org/jira/browse/OAK-6264
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration, upgrade
>Reporter: Hudson
>Priority: Major
> Labels: CI, jenkins, test-failure
> Fix For: 1.14.0
>
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #338 has failed.
> First failed run: [Jackrabbit Oak
> #338|https://builds.apache.org/job/Jackrabbit%20Oak/338/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/338/console]
> {noformat}
> javax.jcr.RepositoryException: Failed to copy content
> Stacktrace
> java.lang.RuntimeException: javax.jcr.RepositoryException: Failed to copy
> content
> at
> org.apache.jackrabbit.oak.upgrade.CopyCheckpointsTest.prepare(CopyCheckpointsTest.java:141)
> Caused by: javax.jcr.RepositoryException: Failed to copy content
> at
> org.apache.jackrabbit.oak.upgrade.CopyCheckpointsTest.prepare(CopyCheckpointsTest.java:141)
> Caused by: java.lang.IllegalArgumentException
> at
> org.apache.jackrabbit.oak.upgrade.CopyCheckpointsTest.prepare(CopyCheckpointsTest.java:141)
> {noformat}
> This affects
> {noformat}
>
> org.apache.jackrabbit.oak.upgrade.CopyCheckpointsTest.validateMigration[Suppress
> the warning]
>
> org.apache.jackrabbit.oak.upgrade.CopyCheckpointsTest.validateMigration[Source
> data store defined, checkpoints migrated]
>
> org.apache.jackrabbit.oak.upgrade.IgnoreMissingBinariesTest.validateMigration
> org.apache.jackrabbit.oak.upgrade.UpgradeOldSegmentTest.upgradeFrom10
>
> org.apache.jackrabbit.oak.upgrade.cli.SegmentTarToSegmentTest.validateMigration
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToJdbcTest.validateMigration
>
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToSegmentTarTest.validateMigration
>
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToSegmentTarWithMissingDestinationDirectoryTest.validateMigration
>
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToSegmentTest.validateMigration
>
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToSegmentWithMissingDestinationDirectoryTest.validateMigration
>
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
> references, no blobstores defined, segment -> segment]
>
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
> references, no blobstores defined, segment-tar -> segment-tar]
>
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
> references, no blobstores defined, segment -> segment-tar]
>
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
> embedded to embedded, no blobstores defined]
>
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
> embedded to external, no blobstores defined]
>
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
> references, src blobstore defined]
>
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
> external to embedded, src blobstore defined]
>
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
> external to external, src blobstore defined]
> org.apache.jackrabbit.oak.upgrade.cli.blob.FbsToFbsTest.validateMigration
> org.apache.jackrabbit.oak.upgrade.cli.blob.FbsToFdsTest.validateMigration
> org.apache.jackrabbit.oak.upgrade.cli.blob.FdsToFbsTest.validateMigration
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-5553) Index async index in a new lane without blocking the main lane
[ https://issues.apache.org/jira/browse/OAK-5553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-5553: -- Fix Version/s: (was: 1.12.0) > Index async index in a new lane without blocking the main lane > -- > > Key: OAK-5553 > URL: https://issues.apache.org/jira/browse/OAK-5553 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: indexing >Reporter: Chetan Mehrotra >Priority: Major > Fix For: 1.14.0 > > > Currently if an async index has to be reindex for any reason say update of > index definition then this process blocks the indexing of other indexes on > that lane. > For e.g. if on "async" lane we have 2 indexes /oak:index/fooIndex and > /oak:index/barIndex and fooIndex needs to be reindexed. In such a case > currently AsyncIndexUpdate would work on reindexing and untill that gets > complete other index do not receive any update. If the reindexing takes say 1 > day then other index would start lagging behind by that time. Note that NRT > indexing would help somewhat here. > To improve this we can implement something similar to what was done for > property index in OAK-1456 i.e. provide a way where > # an admin can trigger reindex of some async indexes > # those indexes are moved to different lane and then reindexed > # post reindexing logic should then move them back to there original lane > Further this task can then be performed on non leader node as the indexes > would not be part of any active lane. Also we may implement it as part of > oak-run -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-2976) Oak percolator
[ https://issues.apache.org/jira/browse/OAK-2976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-2976: -- Fix Version/s: (was: 1.12.0) > Oak percolator > -- > > Key: OAK-2976 > URL: https://issues.apache.org/jira/browse/OAK-2976 > Project: Jackrabbit Oak > Issue Type: Task > Components: query >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili >Priority: Major > Fix For: 1.14.0 > > > Inspired by [Elasticsearch > percolator|https://www.elastic.co/guide/en/elasticsearch/reference/current/search-percolate.html] > we may implement an Oak percolator that would basically store queries and > perform specific tasks upon indexing of documents matching those queries. > The reasons for possibly having that are that such a mechanism could be used > to run common but slow queries automatically whenever batches of matching > documents get indexed, to eventually warm up the underlying indexes caches. > Also such a percolator could be used as a notification mechanism (alerting, > monitoring). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6303) Cache in CachingBlobStore might grow beyond configured limit
[
https://issues.apache.org/jira/browse/OAK-6303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-6303:
--
Fix Version/s: (was: 1.12.0)
> Cache in CachingBlobStore might grow beyond configured limit
>
>
> Key: OAK-6303
> URL: https://issues.apache.org/jira/browse/OAK-6303
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: blob, core
>Reporter: Julian Reschke
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.14.0
>
> Attachments: OAK-6303-test.diff, OAK-6303.diff
>
>
> It appears that depending on actual cache entry sizes, the {{CacheLIRS}}
> might grow beyond the configured limit.
> For {{RDBBlobStore}}, the limit is currently configured to 16MB, yet storing
> random 2M entries appears to fill the cache with 64MB of data (according to
> it's own stats).
> The attached test case reproduces this.
> (it seems this is caused by the fact that each of the 16 segments of the
> cache can hold 2 entries, no matter how big they are...)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7671) [oak-run] Deprecate the datastorecheck command in favor of datastore
[
https://issues.apache.org/jira/browse/OAK-7671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-7671:
--
Fix Version/s: (was: 1.12.0)
> [oak-run] Deprecate the datastorecheck command in favor of datastore
>
>
> Key: OAK-7671
> URL: https://issues.apache.org/jira/browse/OAK-7671
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: run
>Reporter: Amit Jain
>Assignee: Amit Jain
>Priority: Major
> Fix For: 1.14.0
>
>
> With the introduction of \{{datastore}} command which supports both garbage
> collection as well as consistency check the \{{datastorecheck}} command
> should be deprecated and delegated internally to use that implementation.
> Besides some options which are currently not supported by the new command
> should also be implemented e.g. --ids, --refs
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7328) Update DocumentNodeStore based OakFixture
[ https://issues.apache.org/jira/browse/OAK-7328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7328: -- Fix Version/s: (was: 1.12.0) > Update DocumentNodeStore based OakFixture > - > > Key: OAK-7328 > URL: https://issues.apache.org/jira/browse/OAK-7328 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: run >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.14.0 > > > The current OakFixtures using a DocumentNodeStore use a configuration / setup > which is different from what a default DocumentNodeStoreService would use. It > would be better if benchmarks run with a configuration close to a default > setup. The main differences identified are: > - Does not have a proper executor, which means some tasks are executed with > the same thread. > - Does not use a separate persistent cache for the journal (diff cache). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-1905) SegmentMK: Arch segment(s)
[ https://issues.apache.org/jira/browse/OAK-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-1905: -- Fix Version/s: (was: 1.12.0) > SegmentMK: Arch segment(s) > -- > > Key: OAK-1905 > URL: https://issues.apache.org/jira/browse/OAK-1905 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar >Reporter: Jukka Zitting >Priority: Minor > Labels: perfomance, scalability > Fix For: 1.14.0 > > > There are a lot of constants and other commonly occurring name, values and > other data in a typical repository. To optimize storage space and access > speed, it would be useful to place such data in one or more constant "arch > segments" that are always cached in memory. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-5937) Disable query where path restriction is not absolute
[ https://issues.apache.org/jira/browse/OAK-5937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-5937: -- Fix Version/s: (was: 1.12.0) > Disable query where path restriction is not absolute > > > Key: OAK-5937 > URL: https://issues.apache.org/jira/browse/OAK-5937 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Chetan Mehrotra >Assignee: Thomas Mueller >Priority: Minor > Fix For: 1.14.0 > > > Query like below cannot be executed in a performant way. We should provide an > option to reject such queries > //content/foo/bar -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7725) Allow to have the users and groups created in the immutable part of the composite setup
[ https://issues.apache.org/jira/browse/OAK-7725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7725: -- Fix Version/s: (was: 1.12.0) > Allow to have the users and groups created in the immutable part of the > composite setup > --- > > Key: OAK-7725 > URL: https://issues.apache.org/jira/browse/OAK-7725 > Project: Jackrabbit Oak > Issue Type: Story > Components: composite, security >Reporter: Tomek Rękawek >Assignee: Tomek Rękawek >Priority: Major > Fix For: 1.14.0 > > Attachments: OAK-7725-tests.patch > > > When running the Oak with Composite Node Store, the /home subtree is always > stored in the mutable, global part. Therefore, even if we switch the > immutable part (eg. /libs), the users and groups are not affected. > This setup makes sense for the users and groups created interactively. > However, we also have the service users, which usually are not created > interactively, but are part of the application and therefore are related to > the /libs part. For such users, it'd make sense to include them dynamically, > together with the application, read-only mount. > The proposal is to allow some part of the /home (eg. /home/service) to be > mounted from the read-only partial node store. Let's consider the constraints > we need to put in place (eg. it shouldn't be possible to have inter-mounts > group memberships) and how we can implement this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-5291) Per-Query Limits (nodes read, nodes read in memory)
[
https://issues.apache.org/jira/browse/OAK-5291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-5291:
--
Fix Version/s: (was: 1.12.0)
> Per-Query Limits (nodes read, nodes read in memory)
> ---
>
> Key: OAK-5291
> URL: https://issues.apache.org/jira/browse/OAK-5291
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.14.0
>
>
> In OAK-1395 we added limits for long running queries. In OAK-1571 we added
> OSGi configuration. In OAK-5237 we change the default settings.
> It would be nice to be able to define the limits per query, similar to
> OAK-4888. The query would look like (for example, to limit reading to 1
> million nodes, even if the default query limit is lower):
> {noformat}
> select * from [nt:base]
> where ischildnode('/oak:index')
> order by name()
> option(traversal ok, limit 100)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7922) Improve the operations and the reporting of the check command
[
https://issues.apache.org/jira/browse/OAK-7922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-7922:
--
Fix Version/s: (was: 1.12.0)
> Improve the operations and the reporting of the check command
> -
>
> Key: OAK-7922
> URL: https://issues.apache.org/jira/browse/OAK-7922
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Francesco Mari
>Assignee: Francesco Mari
>Priority: Major
> Fix For: 1.14.0
>
> Attachments: OAK-7922-01.patch
>
>
> The check command allows a user to check for both the head and the
> checkpoints. At the end of the execution the command outputs the consistent
> revisions for the head and the individual checkpoints, if any is found.
> Moreover, it prints an overall good revision. The consistent revisions for
> the head and the checkpoints could all be different. If both the head and all
> the checkpoints are assigned to a consistent revision, the overall good
> revision is the oldest of those revisions.
> I wonder how useful all of this information is to a user of the command:
> - I might have a revision where a checkpoint is consistent, but the head is
> not. In this case, I don't want to revert to that revision because my system
> will probably be unstable due to the inconsistent head.
> - The overall good revision might still be partially inconsistent due to the
> way the command short-circuits the consistency check on the head and the
> checkpoints. If I revert to the overall good revision, the head might still
> be inconsistent or one of the checkpoints might be missing.
> I propose to remove the {{\--checkpoints}} and the {{\--head}} flags and
> define the behaviour of the command as follows.
> - The check command checks one super-root at a time in its entirety (both
> head and referenced checkpoints).
> - The command exits as soon as a super-root is found where both the head and
> all the checkpoints are consistent.
> - While searching, the command might find a super-root with a consistent
> head but one or more inconsistent checkpoint. In this case, the first of such
> revisions is printed, specifying which checkpoints are inconsistent.
> - The user might specify a {{--no-checkpoints}} flag to skip checking the
> checkpoints in the steps above.
> The optimisations currently implemented by the check command can be
> maintained. We don't need to fully traverse the head or the checkpoints if a
> well-known corrupted path is still corrupted in the current iteration. The
> approach proposed above enables additional optimisations:
> - Since checkpoints are immutable, the command doesn't need to traverse a
> checkpoint that was inspected before. This is true regardless of the
> consistency of the checkpoint.
> - If a super-root includes a checkpoint that was previously determined
> corrupted, the command can skip that super-root without further inspection.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7230) Reduce calls to DocumentStore
[ https://issues.apache.org/jira/browse/OAK-7230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7230: -- Fix Version/s: (was: 1.12.0) > Reduce calls to DocumentStore > - > > Key: OAK-7230 > URL: https://issues.apache.org/jira/browse/OAK-7230 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Major > Labels: performance > Fix For: 1.14.0 > > > Analyze and further reduce calls to the DocumentStore when content is written > to the repository. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7192) Remove package export for org.apache.jackrabbit.oak.composite.checks
[
https://issues.apache.org/jira/browse/OAK-7192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-7192:
--
Fix Version/s: (was: 1.12.0)
> Remove package export for org.apache.jackrabbit.oak.composite.checks
>
>
> Key: OAK-7192
> URL: https://issues.apache.org/jira/browse/OAK-7192
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: composite
>Reporter: Marcel Reutegger
>Priority: Minor
> Fix For: 1.14.0
>
>
> It appears the package {{org.apache.jackrabbit.oak.composite.checks}} is only
> used internally by the oak-store-composite module and should not be exported.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-6947) Add package export versions for oak-store-spi
[ https://issues.apache.org/jira/browse/OAK-6947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6947: -- Fix Version/s: (was: 1.12.0) > Add package export versions for oak-store-spi > - > > Key: OAK-6947 > URL: https://issues.apache.org/jira/browse/OAK-6947 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: store-spi >Reporter: angela >Assignee: Michael Dürig >Priority: Major > Fix For: 1.14.0 > > Attachments: OAK-6947.patch > > > [~mduerig], [~mreutegg], [~frm], [~stillalex], do you have any strong > preferences wrt to the packages we placed in the _oak-store-spi_ module? > Currently we explicitly export all packages and I think it would make sense > to enable the baseline plugin for these packages. > Any objection from your side? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-4498) Introduce lower limit for gc() maxRevisionAge
[ https://issues.apache.org/jira/browse/OAK-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-4498: -- Fix Version/s: (was: 1.12.0) > Introduce lower limit for gc() maxRevisionAge > - > > Key: OAK-4498 > URL: https://issues.apache.org/jira/browse/OAK-4498 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, documentmk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.14.0 > > > Introduce and enforce a lower limit for maxRevisionAge in > VersionGarbageCollector.gc(). > OAK-4494 changes the way documents in a cache are considered up-to-date. In > addition to the modCount value it also considers the modified timestamp. To > work properly, a new document must have a modified timestamp that is > different from a previous incarnation (i.e. before gc removed it). The > version GC should therefore not remove documents with a maxRevisionAge less > than the modified resolution (5 seconds). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-5980) Bad Join Query Plan Used
[
https://issues.apache.org/jira/browse/OAK-5980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-5980:
--
Fix Version/s: (was: 1.12.0)
> Bad Join Query Plan Used
>
>
> Key: OAK-5980
> URL: https://issues.apache.org/jira/browse/OAK-5980
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.14.0
>
>
> For a join query, where selectors are joined over ischildnode but also can
> use an index,
> the selectors sometimes use the index instead of the much less
> expensive parent join. Example:
> {noformat}
> select [a].* from [nt:unstructured] as [a]
> inner join [nt:unstructured] as [b] on ischildnode([b], [a])
> inner join [nt:unstructured] as [c] on ischildnode([c], [b])
> inner join [nt:unstructured] as [d] on ischildnode([d], [c])
> inner join [nt:unstructured] as [e] on ischildnode([e], [d])
> where [a].[classname] = 'letter'
> and isdescendantnode([a], '/content')
> and [c].[classname] = 'chapter'
> and localname([b]) = 'chapters'
> and [e].[classname] = 'list'
> and localname([d]) = 'lists'
> and [e].[path] = cast('/content/abc' as path)
> {noformat}
> The order of selectors is sometimes wrong (not e, d, c, b, a), but
> more importantly, selectors c and a use the index on className.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8187) Respect service ranking with AuthorizableNodeName, AuthorizableActionProvider and RestrictionProvider
[
https://issues.apache.org/jira/browse/OAK-8187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-8187:
--
Fix Version/s: (was: 1.12.0)
> Respect service ranking with AuthorizableNodeName, AuthorizableActionProvider
> and RestrictionProvider
> -
>
> Key: OAK-8187
> URL: https://issues.apache.org/jira/browse/OAK-8187
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: angela
>Priority: Major
> Fix For: 1.14.0
>
>
> The way multiple {{AuthorizableNodeName}}, {{AuthorizableActionProvider}} and
> {{RestrictionProvider}} service are handled by
> {{SecurityProviderRegistration}} suffers from the same issues as was reported
> for {{UserAuthenticationFactory}} (see OAK-8045). Once OAK-8045 is addressed
> we should adopt the same behavior for the remaining bind/unbind methods for
> the interfaces mentioned above.
> cc: [~stillalex]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-1150) NodeType index: don't index all primary and mixin types
[ https://issues.apache.org/jira/browse/OAK-1150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-1150: -- Fix Version/s: (was: 1.12.0) > NodeType index: don't index all primary and mixin types > --- > > Key: OAK-1150 > URL: https://issues.apache.org/jira/browse/OAK-1150 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: property-index >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Major > Fix For: 1.14.0 > > > Currently, the nodetype index indexes all primary types and mixin types > (including nt:base I think). > This results in many nodes in this index, which unnecessarily increases the > repository size, but doesn't really help executing queries (running a query > to get all nt:base nodes doesn't benefit much from using the nodetype index). > It should also help reduce writes in updating the index, for example for > OAK-1099 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6288) Test failure: upgrade tests failing: Failed to copy content
[
https://issues.apache.org/jira/browse/OAK-6288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-6288:
--
Fix Version/s: (was: 1.12.0)
> Test failure: upgrade tests failing: Failed to copy content
> ---
>
> Key: OAK-6288
> URL: https://issues.apache.org/jira/browse/OAK-6288
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration, upgrade
>Reporter: Hudson
>Priority: Major
> Labels: CI, jenkins, test-failure
> Fix For: 1.14.0
>
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #364 has failed.
> First failed run: [Jackrabbit Oak
> #364|https://builds.apache.org/job/Jackrabbit%20Oak/364/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/364/console]
> Failing tests:
> {noformat}
>
> org.apache.jackrabbit.oak.upgrade.CopyCheckpointsTest.validateMigration[Suppress
> the warning]
>
> org.apache.jackrabbit.oak.upgrade.CopyCheckpointsTest.validateMigration[Source
> data store defined, checkpoints migrated]
>
> org.apache.jackrabbit.oak.upgrade.IgnoreMissingBinariesTest.validateMigration
> org.apache.jackrabbit.oak.upgrade.UpgradeOldSegmentTest.upgradeFrom10
>
> org.apache.jackrabbit.oak.upgrade.cli.SegmentTarToSegmentTest.validateMigration
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToJdbcTest.validateMigration
>
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToSegmentTarTest.validateMigration
>
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToSegmentTarWithMissingDestinationDirectoryTest.validateMigration
>
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToSegmentTest.validateMigration
>
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToSegmentWithMissingDestinationDirectoryTest.validateMigration
>
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
> references, no blobstores defined, segment -> segment]
>
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
> references, no blobstores defined, segment-tar -> segment-tar]
>
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
> references, no blobstores defined, segment -> segment-tar]
>
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
> embedded to embedded, no blobstores defined]
>
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
> embedded to external, no blobstores defined]
>
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
> references, src blobstore defined]
>
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
> external to embedded, src blobstore defined]
>
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
> external to external, src blobstore defined]
> org.apache.jackrabbit.oak.upgrade.cli.blob.FbsToFbsTest.validateMigration
> org.apache.jackrabbit.oak.upgrade.cli.blob.FbsToFdsTest.validateMigration
> org.apache.jackrabbit.oak.upgrade.cli.blob.FdsToFbsTest.validateMigration
> {noformat}
> All seem to fail with
> {noformat}
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.737
> s <<< FAILURE! - in
> org.apache.jackrabbit.oak.upgrade.cli.SegmentTarToSegmentTest
> [ERROR]
> validateMigration(org.apache.jackrabbit.oak.upgrade.cli.SegmentTarToSegmentTest)
> Time elapsed: 3.73 s <<< ERROR!
> java.lang.RuntimeException: javax.jcr.RepositoryException: Failed to copy
> content
> Caused by: javax.jcr.RepositoryException: Failed to copy content
> Caused by: java.lang.IllegalArgumentException
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7937) Implement CugAccessControlManager.getEffectivePolicies(Set principals)
[ https://issues.apache.org/jira/browse/OAK-7937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7937: -- Fix Version/s: (was: 1.12.0) > Implement CugAccessControlManager.getEffectivePolicies(Set > principals) > - > > Key: OAK-7937 > URL: https://issues.apache.org/jira/browse/OAK-7937 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: authorization-cug, security >Reporter: angela >Assignee: Alex Deparvu >Priority: Major > Fix For: 1.14.0 > > > today CugAccessControlManager.getEffectivePolicies(Set principals) > returns an empty array and has a comment stating that this is not implemented. > having thought this through again, i think there was some benefit in having > the implementation. as long as the given set of principal does NOT include > everyone the return value should just include the CUG-policies that > explicitly list any of principals. IF _everyone_ was part of the set, the > return-value basically includes _all_ CUG-policies, because every CUG will > deny read-access for everyone except for the principals explicitly listed in > the CUG-policy... if we do the latter as lazy as possible it might still be > doable even in a scenario, when there are tons of CUG-policies specified. > [~stillalex], wdyt? do you want to take care of this? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-2182) Specify collection to be used by Solr index
[ https://issues.apache.org/jira/browse/OAK-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-2182: -- Fix Version/s: (was: 1.12.0) > Specify collection to be used by Solr index > --- > > Key: OAK-2182 > URL: https://issues.apache.org/jira/browse/OAK-2182 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: solr >Affects Versions: 1.1.0 >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili >Priority: Major > Fix For: 1.14.0 > > > Currently all the information to hit a Solr server is hold by the singleton > SolrServerProvider while there are some use cases where more than one query > index definition for a Solr index may be done, targeting different content, > and therefore it'd be good to be able to specify which collection should be > used by each of these indexes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6408) Review package exports for o.a.j.oak.plugins.index.*
[ https://issues.apache.org/jira/browse/OAK-6408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6408: -- Fix Version/s: (was: 1.12.0) > Review package exports for o.a.j.oak.plugins.index.* > > > Key: OAK-6408 > URL: https://issues.apache.org/jira/browse/OAK-6408 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, indexing >Reporter: angela >Priority: Major > Fix For: 1.14.0 > > > while working on OAK-6304 and OAK-6355, i noticed that the > _o.a.j.oak.plugins.index.*_ contains both internal api/utilities and > implementation details which get equally exported (though without having any > package export version set). > in the light of the modularization effort, i would like to suggest that we > try to sort that out and separate the _public_ parts from implementation > details. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-5152) Improve overflow handling in ChangeSetFilterImpl
[ https://issues.apache.org/jira/browse/OAK-5152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-5152: -- Fix Version/s: (was: 1.12.0) > Improve overflow handling in ChangeSetFilterImpl > > > Key: OAK-5152 > URL: https://issues.apache.org/jira/browse/OAK-5152 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Affects Versions: 1.5.14 >Reporter: Stefan Egli >Priority: Major > Fix For: 1.14.0 > > > As described in OAK-5151 when a ChangeSet overflows, the ChangeSetFilterImpl > treats the changes as included and doesn't go further into the remaining, > perhaps not-overflown other sets. Besides more testing it wouldn't be much > effort to change this though. Putting this as outside of 1.6 scope for now > though. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6166) Support versioning in the composite node store
[ https://issues.apache.org/jira/browse/OAK-6166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6166: -- Fix Version/s: (was: 1.12.0) > Support versioning in the composite node store > -- > > Key: OAK-6166 > URL: https://issues.apache.org/jira/browse/OAK-6166 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: composite >Reporter: Tomek Rękawek >Priority: Minor > Fix For: 1.14.0 > > > The mount info provider should affect the versioning code as well, so version > histories for the mounted paths are stored separately. Similarly to what we > have in the indexing, let's store the mounted version histories under: > /jcr:system/jcr:versionStorage/:oak:mount-MOUNTNAME -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-3809) Test failure: FacetTest
[
https://issues.apache.org/jira/browse/OAK-3809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-3809:
--
Fix Version/s: (was: 1.12.0)
> Test failure: FacetTest
> ---
>
> Key: OAK-3809
> URL: https://issues.apache.org/jira/browse/OAK-3809
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: solr
> Environment:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
>Reporter: Michael Dürig
>Assignee: Tommaso Teofili
>Priority: Major
> Labels: ci, jenkins, test, test-failure
> Fix For: 1.14.0
>
>
> {{org.apache.jackrabbit.oak.jcr.query.FacetTest}} keeps failing on Jenkins:
> {noformat}
> testFacetRetrievalMV(org.apache.jackrabbit.oak.jcr.query.FacetTest) Time
> elapsed: 5.927 sec <<< FAILURE!
> junit.framework.ComparisonFailure: expected: (2), aem (1), apache (1), cosmetics (1), furniture (1)], tags:[repository
> (2), software (2), aem (1), apache (1), cosmetics (1), furniture (1)],
> tags:[repository (2), software (2), aem (1), apache (1), cosmetics (1),
> furniture (1)], tags:[repository (2), software (2), aem (1), apache (1),
> cosmetics (1), furniture (1)]]> but was:
> at junit.framework.Assert.assertEquals(Assert.java:100)
> at junit.framework.Assert.assertEquals(Assert.java:107)
> at junit.framework.TestCase.assertEquals(TestCase.java:269)
> at
> org.apache.jackrabbit.oak.jcr.query.FacetTest.testFacetRetrievalMV(FacetTest.java:80)
> {noformat}
> Failure seen at builds: 628, 629, 630, 633, 634, 636, 642, 643, 644, 645,
> 648, 651, 656, 659, 660, 663, 666
> See e.g.
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/634/#showFailuresLink
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-6366) Detect unsupported combination of read and write concern
[ https://issues.apache.org/jira/browse/OAK-6366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6366: -- Fix Version/s: (was: 1.12.0) > Detect unsupported combination of read and write concern > > > Key: OAK-6366 > URL: https://issues.apache.org/jira/browse/OAK-6366 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk >Reporter: Marcel Reutegger >Priority: Minor > Fix For: 1.14.0 > > > With OAK-4069 Oak will try to use a majority read concern when connected to a > replica set. The implementation should be more careful when setting a > majority read concern automatically and take the write concern into account. > It is currently possible to end up with a system that has a user configured > write concern of 1 and a majority read concern. This results in a > non-functional system and should be prevented. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6897) XPath query: option to _not_ convert "or" to "union"
[ https://issues.apache.org/jira/browse/OAK-6897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6897: -- Fix Version/s: (was: 1.12.0) > XPath query: option to _not_ convert "or" to "union" > > > Key: OAK-6897 > URL: https://issues.apache.org/jira/browse/OAK-6897 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Trivial > Fix For: 1.14.0 > > > Right now, all XPath queries that contain "or" of the form "@a=1 or @b=2" are > converted to SQL-2 "union". In some cases, this is a problem, specially in > combination with "order by @jcr:score desc". > Now that SQL-2 "or" conditions can be converted to union (depending if union > has a lower cost), it is no longer strictly needed to do the union conversion > in the XPath conversion. Or at least emit different SQL-2 queries and take > the one with the lowest cost. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-5588) Improve Session stats.
[ https://issues.apache.org/jira/browse/OAK-5588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-5588: -- Fix Version/s: (was: 1.12.0) > Improve Session stats. > -- > > Key: OAK-5588 > URL: https://issues.apache.org/jira/browse/OAK-5588 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: Ian Boston >Priority: Major > Labels: monitoring, production > Fix For: 1.14.0 > > > Currently each session has a SessionsStats MBean. Omongst other things it > records the total number or refresh operations. It also records the rate of > refresh operations, although this number in its current form is not usefull > as the rate is the number of refresh operations/session lifetime. It would > be much better to have a set of stats related to classes of users that > recorded proper metrics in a consistent way. eg 1 metric set per > service-user, 1 for the admin user and perhaps 1 for all normal users. Each > would record m1,m5,m15 rates, total count, p50,p75,p95,p99,p999 durations > with mean and stdev then 2 sets of metrics could be compared and monitored > without having to look at the code to work out how the metric was calculated. > Oak has metrics support to do this, minimal code would be required. > I dont think it would be viable to have 1 metric per unique session (too much > overhead, too much data, good for devs but bad for production), and in fact > having 1 JMX MBean per unique session is likely to cause problems with > everything connected to JMX even the ManagementServer can cope. Same goes for > the other proliferation of MBeans in the Oak 1.6. Perhaps a review of JMX in > Oak is due. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7374) Investigate changing the UUID generation algorithm / format to reduce index size, improve speed
[ https://issues.apache.org/jira/browse/OAK-7374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7374: -- Fix Version/s: (was: 1.12.0) > Investigate changing the UUID generation algorithm / format to reduce index > size, improve speed > --- > > Key: OAK-7374 > URL: https://issues.apache.org/jira/browse/OAK-7374 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Major > Fix For: 1.14.0 > > > UUIDs are currently randomly generated, which is bad for indexing; specially > read and writes access, due to low locality. > If we could add a time component, I think the index churn (amount of writes) > would shrink, and lookup would be faster. > It should be fairly easy to verify if that's really true (create a > proof-of-concept, and measure). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7381) Reduce debug log output for queries
[ https://issues.apache.org/jira/browse/OAK-7381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7381: -- Fix Version/s: (was: 1.12.0) > Reduce debug log output for queries > --- > > Key: OAK-7381 > URL: https://issues.apache.org/jira/browse/OAK-7381 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Major > Fix For: 1.14.0 > > > When enabling the debug log level, running a query can log a lot. That can > slow down executing a large query quite a lot. The amount of logged data > should be reduced. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-5463) Implement optimized MultiBinaryPropertyState.size(int)
[
https://issues.apache.org/jira/browse/OAK-5463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-5463:
--
Fix Version/s: (was: 1.12.0)
> Implement optimized MultiBinaryPropertyState.size(int)
> --
>
> Key: OAK-5463
> URL: https://issues.apache.org/jira/browse/OAK-5463
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Marcel Reutegger
>Priority: Minor
> Fix For: 1.14.0
>
>
> {{MultiBinaryPropertyState}} currently does not have a {{size(int)}}
> implementation, which means the base class will convert the {{Blob}} into a
> String to get the size. This is inefficient and should have an optimized
> implementation in {{MultiBinaryPropertyState}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-5889) Change internal queries to use "option(traversal fail)"
[ https://issues.apache.org/jira/browse/OAK-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-5889: -- Fix Version/s: (was: 1.12.0) > Change internal queries to use "option(traversal fail)" > --- > > Key: OAK-5889 > URL: https://issues.apache.org/jira/browse/OAK-5889 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Major > Fix For: 1.14.0 > > > The Oak internal queries that use an index (that is, hopefully all of them) > should fail if no index is available. For example, it's better to fail > queries that search a node by UUID, if the UUID index is disabled, otherwise > for each such query, the complete repository is traversed. > To do that, "option(traversal fail)" can be appended to the query. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6904) NRT Indexes should be closed if async indexer progresses
[ https://issues.apache.org/jira/browse/OAK-6904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6904: -- Fix Version/s: (was: 1.12.0) > NRT Indexes should be closed if async indexer progresses > > > Key: OAK-6904 > URL: https://issues.apache.org/jira/browse/OAK-6904 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: 1.14.0 > > > Currently NRTIndex associated with IndexNodeManager are only closed upon > index update. However each IndexNodeManager keeps reference to 2 NRTIndex > instances. It can happen that following sequence can happen > # Index /oak:index/ntBaseLucene refers to 2 nrt indexes NR1 and NR2. Where > NR1 has 1 M entries and NR2 has 1 M entries > # AsyncIndexer updates and thus refreshes the /oak:index/ntBaseLucene. This > causes new NRT Index NR3 to be created and NR1 to be closed. So NR3 and NR2 > are active > # AsyncIndexer updates but no change happen in setup which causes any update > to /oak:index/ntBaseLucene. Thus this index does not get refreshed and > continues to refer to NR2 > So as a fix we should refresh any index if it refers to 2 NRT indexes where > previous one is not empty -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7374) Investigate changing the UUID generation algorithm / format to reduce index size, improve speed
[ https://issues.apache.org/jira/browse/OAK-7374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7374: -- Fix Version/s: 1.14.0 > Investigate changing the UUID generation algorithm / format to reduce index > size, improve speed > --- > > Key: OAK-7374 > URL: https://issues.apache.org/jira/browse/OAK-7374 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Major > Fix For: 1.12.0, 1.14.0 > > > UUIDs are currently randomly generated, which is bad for indexing; specially > read and writes access, due to low locality. > If we could add a time component, I think the index churn (amount of writes) > would shrink, and lookup would be faster. > It should be fairly easy to verify if that's really true (create a > proof-of-concept, and measure). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6768) Convert oak-remote to OSGi R6 annotations
[ https://issues.apache.org/jira/browse/OAK-6768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6768: -- Fix Version/s: 1.14.0 > Convert oak-remote to OSGi R6 annotations > - > > Key: OAK-6768 > URL: https://issues.apache.org/jira/browse/OAK-6768 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: remoting >Reporter: Robert Munteanu >Priority: Major > Fix For: 1.12.0, 1.14.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7151) Support indexed based excerpts on properties
[
https://issues.apache.org/jira/browse/OAK-7151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-7151:
--
Fix Version/s: (was: 1.12.0)
> Support indexed based excerpts on properties
>
>
> Key: OAK-7151
> URL: https://issues.apache.org/jira/browse/OAK-7151
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
> Fix For: 1.14.0
>
> Attachments: OAK-7151.patch, OAK-7151.xpath-new-syntax.patch,
> OAK-7151.xpath.patch
>
>
> As discovered in OAK-4401 we fallback to {{SimpleExcerptProvider}} when
> requesting excerpts for properties.
> The issue as highlighted in [~teofili]'s comment \[0] is that we at time of
> query we don't have information about which all columns/fields would be
> required for excerpts.
> A possible approach is that the query specified explicitly which columns
> would be required in facets (of course, node level excerpt would still be
> supported). This issue is to track that improvement.
> Note: this is *not* a substitute for OAK-4401 which is about doing saner
> highlighting when {{SimpleExcerptProvider}} comes into play e.g. despite this
> issue excerpt for non-stored fields (properties which aren't configured with
> {{useInExcerpt}} in the index definition}, we'd need to fallback to
> {{SimpleExcerptProvider}}.
> /[~tmueller]
> \[0]:
> https://issues.apache.org/jira/browse/OAK-4401?focusedCommentId=15299857=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15299857
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[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
]
Davide Giannella updated OAK-3355:
--
Fix Version/s: 1.14.0
> Test failure: SpellcheckTest.testSpellcheckMultipleWords
>
>
> Key: OAK-3355
> URL: https://issues.apache.org/jira/browse/OAK-3355
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: solr
>Affects Versions: 1.0.24
> Environment:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
>Reporter: Michael Dürig
>Assignee: Tommaso Teofili
>Priority: Major
> Labels: ci, jenkins, test, test-failure
> Fix For: 1.12.0, 1.14.0
>
>
> {{org.apache.jackrabbit.oak.jcr.query.SpellcheckTest.testSpellcheckMultipleWords}}
> fails on Jenkins.
> Failure seen at builds: 389, 392, 395, 396, 562
> 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
(v7.6.3#76005)
[jira] [Updated] (OAK-6764) Convert oak-exercise to OSGi R6 annotations
[ https://issues.apache.org/jira/browse/OAK-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6764: -- Fix Version/s: (was: 1.12.0) > Convert oak-exercise to OSGi R6 annotations > --- > > Key: OAK-6764 > URL: https://issues.apache.org/jira/browse/OAK-6764 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: exercise >Reporter: Robert Munteanu >Priority: Major > Fix For: 1.14.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6741) Switch to official OSGi component and metatype annotations
[ https://issues.apache.org/jira/browse/OAK-6741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6741: -- Fix Version/s: 1.14.0 > Switch to official OSGi component and metatype annotations > -- > > Key: OAK-6741 > URL: https://issues.apache.org/jira/browse/OAK-6741 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Robert Munteanu >Priority: Major > Fix For: 1.12.0, 1.14.0 > > Attachments: OAK-6741-proposed-changes-chetans-feedback.patch, > osgi-metadata-1.7.8.json, osgi-metadata-trunk.json > > > We should remove the 'old' Felix SCR annotations and move to the 'new' OSGi > R6 annotations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6254) DataStore: API to retrieve approximate storage size
[
https://issues.apache.org/jira/browse/OAK-6254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-6254:
--
Fix Version/s: (was: 1.12.0)
> DataStore: API to retrieve approximate storage size
> ---
>
> Key: OAK-6254
> URL: https://issues.apache.org/jira/browse/OAK-6254
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: blob
>Reporter: Thomas Mueller
>Priority: Major
> Fix For: 1.14.0
>
>
> The estimated size of the datastore (on disk) is needed to:
> * monitor growth over time, or growth of certain operations
> * monitor if garbage collection is effective
> * avoid out of disk space
> * estimate backup size
> * statistical purposes (for example, if there are many repositories, to group
> them by size)
> Datastore size: we could use the following heuristic: We could read the file
> sizes in ./datastore/00/00 (if it exists) and multiply by 65536; or
> ./datastore/00 and multiply by 256. That would give a rough estimation
> (within about 20% for repositories with datastore size > 50 GB).
> I think this is mainly important for the FileDataStore. The S3 datastore, if
> there is a simple and fast S3 API to read the size, then that would be good
> as well, but if there is none, then returning "unknown" is fine for me.
> As for the API, I would use something like this: {{long
> getEstimatedStorageSize(int accuracyLevel)}} with accuracyLevel 1 for
> inaccurate (fastest), 2 more accurate (slower),..., 9 precise (possibly very
> slow). Similar to
> [java.util.zip.Deflater.setLevel|https://docs.oracle.com/javase/7/docs/api/java/util/zip/Deflater.html#setLevel(int)].
> I would expect it takes up to 1 second for accuracyLevel 0, up to 5 seconds
> for accuracyLevel 1, and possibly hours for level 9. With level 1, I would
> read files in 00/00, with level 2 - 8 I would read files in 00, and with
> level 9 I would read all the files. For level 1, I wouldn't stop; for level
> 2, if it takes more than 5 seconds, I would stop and return the current best
> estimate.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-3767) Provide a way to extend shipped index definitions
[
https://issues.apache.org/jira/browse/OAK-3767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-3767:
--
Fix Version/s: 1.14.0
> Provide a way to extend shipped index definitions
> -
>
> Key: OAK-3767
> URL: https://issues.apache.org/jira/browse/OAK-3767
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: indexing, query
>Reporter: Davide Giannella
>Priority: Major
> Fix For: 1.12.0, 1.14.0
>
>
> We need to provide an explicit support for extending out of the box shipped
> index definition by an application built on top of Oak. Consider a Sling
> based app which ships with an index on assets like /oak:index/assetIndex.
> This application is now used in a project where some project specific
> extensions are to be done i.e. some new custom asset properties are to be
> indexed. Currently there are two options
> # Create new duplicate index - For project usage we can create a separate
> index which includes the project specific properties. This has following
> downsides
> ## Increases index memory consumption - As both /oak:index/assetIndex and
> /oak:index/myAssetIndex would index same asset nodes they would be storing
> the same asset path twice and hence cause an increase in memory consumption
> by the index
> # Increase in indexing time - With increase in number of indexes at same
> level the indexing time would increase
> # Ambiguity in index selection - As both indexes index same type of nodes
> they would compete in answering queries related to assets leading to
> ambiguity in index selection by query engine.
> Given above it would be better to avoid such cases and provide an explicit
> support for extending the index definitions. This can be done by enabling
> support for adding index definition extensions under a sub directory in a sub
> directory under /oak:index
> {noformat}
> /oak:index
> + assetIndex
> + apps
> + assetIndex
> {noformat}
> The indexing logic should then use the effective index definition for
> indexing and querying.
> *question*. Shall we allow this only under root or under any arbitrary path
> as well? For example /content.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-6225) Analyse changing the persistence format of GroupImpl
[ https://issues.apache.org/jira/browse/OAK-6225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6225: -- Fix Version/s: (was: 1.12.0) > Analyse changing the persistence format of GroupImpl > > > Key: OAK-6225 > URL: https://issues.apache.org/jira/browse/OAK-6225 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: Alex Deparvu >Assignee: Alex Deparvu >Priority: Major > Fix For: 1.14.0 > > Attachments: groupimpl-v0.patch, groupimpl-v1.patch, > groupimpl-v2.patch > > > As suggested on OAK-3933, I'd like to look into using a different persistence > format for the GroupImpl members. > Currently this is saved as a list of child nodes, and I'd like to bench this > against a tree based approach where each sub child node represents a part of > the key so it can be used for lookup. > WIP branch can be found at [0], I merged all the commits so far into a single > one to reduce the noise. > fyi [~anchela] > [0] > https://github.com/apache/jackrabbit-oak/compare/trunk...stillalex:oak-6225 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-4177) Tests on Mongo should fail if mongo is not available
[
https://issues.apache.org/jira/browse/OAK-4177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-4177:
--
Fix Version/s: (was: 1.12.0)
> Tests on Mongo should fail if mongo is not available
>
>
> Key: OAK-4177
> URL: https://issues.apache.org/jira/browse/OAK-4177
> Project: Jackrabbit Oak
> Issue Type: Test
>Reporter: Davide Giannella
>Assignee: Davide Giannella
>Priority: Major
> Fix For: 1.14.0
>
>
> Most if not all of the IT/UT that run against mongodb have an
> assumption at class level that if mongodb is not available the tests
> are skipped.
> The tests should fail instead if mongodb is not available and we
> explicitly said that, via the {{nsfixtures}} flags, we want to run the
> tests against mongodb.
> We currently have 4 fixtures/flags: DOCUMENT_NS, SEGMENT_MK,
> DOCUMENT_RDB, MEMORY_NS.
> https://github.com/apache/jackrabbit-oak/blob/f957b6787eb7a70eba454ceb1cae90bd4d47f15c/oak-commons/src/test/java/org/apache/jackrabbit/oak/commons/FixturesHelper.java#L46
> We may have the need to introduce a new Fixture/Flag that indicate
> that we want to run the tests against Document using the in-memory
> implementation. For example: DOCUMENT_NS_IM.
> This will be useful on the Apache Jenkins as we don't have mongo there
> but we still want to run all the possible Document NS tests against
> the in-memory implementation when this is possible.
> /cc [~mreutegg]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-6741) Switch to official OSGi component and metatype annotations
[ https://issues.apache.org/jira/browse/OAK-6741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6741: -- Fix Version/s: (was: 1.12.0) > Switch to official OSGi component and metatype annotations > -- > > Key: OAK-6741 > URL: https://issues.apache.org/jira/browse/OAK-6741 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Robert Munteanu >Priority: Major > Fix For: 1.14.0 > > Attachments: OAK-6741-proposed-changes-chetans-feedback.patch, > osgi-metadata-1.7.8.json, osgi-metadata-trunk.json > > > We should remove the 'old' Felix SCR annotations and move to the 'new' OSGi > R6 annotations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-5272) Expose BlobStore API to provide information whether blob id is content hashed
[ https://issues.apache.org/jira/browse/OAK-5272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-5272: -- Fix Version/s: 1.14.0 > Expose BlobStore API to provide information whether blob id is content hashed > - > > Key: OAK-5272 > URL: https://issues.apache.org/jira/browse/OAK-5272 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: blob >Reporter: Amit Jain >Assignee: Thomas Mueller >Priority: Major > Fix For: 1.12.0, 1.14.0 > > > As per discussion in OAK-5253 it's better to have some information from the > BlobStore(s) whether the blob id can be solely relied upon for comparison. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-5782) Test failure: persistentCache.BroadcastTest.broadcastTCP
[ https://issues.apache.org/jira/browse/OAK-5782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-5782: -- Fix Version/s: (was: 1.12.0) > Test failure: persistentCache.BroadcastTest.broadcastTCP > - > > Key: OAK-5782 > URL: https://issues.apache.org/jira/browse/OAK-5782 > Project: Jackrabbit Oak > Issue Type: Bug > Components: cache, continuous integration, core >Affects Versions: 1.6.0 >Reporter: Hudson >Assignee: Thomas Mueller >Priority: Major > Labels: test-failure, ubuntu > Fix For: 1.14.0 > > > Jenkins CI failure: > https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/ > The build Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.8 > (latest),nsfixtures=SEGMENT_TAR,profile=unittesting #1447 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.8 (latest),nsfixtures=SEGMENT_TAR,profile=unittesting > #1447|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=SEGMENT_TAR,profile=unittesting/1447/] > [console > log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=SEGMENT_TAR,profile=unittesting/1447/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-4647) Multiplexing support in PropertyIndexStats MBean
[
https://issues.apache.org/jira/browse/OAK-4647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-4647:
--
Fix Version/s: (was: 1.12.0)
> Multiplexing support in PropertyIndexStats MBean
>
>
> Key: OAK-4647
> URL: https://issues.apache.org/jira/browse/OAK-4647
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: property-index
>Reporter: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.14.0
>
>
> {{PropertyIndexStats}} MBean added in OAK-4144 allows introspecting property
> index content. This needs to be adapted to support updated storage format
> when multiplexing is enabled
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-3437) Regression in org.apache.jackrabbit.core.query.JoinTest#testJoinWithOR5 when enabling OAK-1617
[
https://issues.apache.org/jira/browse/OAK-3437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-3437:
--
Fix Version/s: (was: 1.12.0)
> Regression in org.apache.jackrabbit.core.query.JoinTest#testJoinWithOR5 when
> enabling OAK-1617
> --
>
> Key: OAK-3437
> URL: https://issues.apache.org/jira/browse/OAK-3437
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: solr
>Reporter: Davide Giannella
>Assignee: Tommaso Teofili
>Priority: Major
> Fix For: 1.14.0
>
>
> When enabling OAK-1617 (still to be committed) there's a regression in the
> {{oak-solr-core}} unit tests
> - {{org.apache.jackrabbit.core.query.JoinTest#testJoinWithOR3}}
> - {{org.apache.jackrabbit.core.query.JoinTest#testJoinWithOR4}}
> - {{org.apache.jackrabbit.core.query.JoinTest#testJoinWithOR5}}
> The WIP of the feature can be found in
> https://github.com/davidegiannella/jackrabbit-oak/tree/OAK-1617 and a full
> patch will be attached shortly for review in OAK-1617 itself.
> The feature is currently disabled, in order to enable it for unit testing an
> approach like this can be taken
> https://github.com/davidegiannella/jackrabbit-oak/blob/177df1a8073b1237857267e23d12a433e3d890a4/oak-core/src/test/java/org/apache/jackrabbit/oak/query/SQL2OptimiseQueryTest.java#L142
> or setting the system property {{-Doak.query.sql2optimisation}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-5932) Use static optional greedy policy for BlobStore in DocumentNodeStoreService
[
https://issues.apache.org/jira/browse/OAK-5932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-5932:
--
Fix Version/s: 1.14.0
> Use static optional greedy policy for BlobStore in DocumentNodeStoreService
> ---
>
> Key: OAK-5932
> URL: https://issues.apache.org/jira/browse/OAK-5932
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: documentmk
>Reporter: Chetan Mehrotra
>Priority: Major
> Fix For: 1.12.0, 1.14.0
>
>
> Currently {{DocumentNodeStoreService}} uses DYNAMIC policy for BlobStore and
> DataSource. This leads to complexity in activation due to dynamic nature of
> OSGi.
> To simplify that we should switch to static, greedy policy. This approach is
> used by SegmentNodeStoreService as part of OAK-5223 and reduces the setup
> complexity quite a bit
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7106) Index Tooling for Oak 1.10
[ https://issues.apache.org/jira/browse/OAK-7106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7106: -- Fix Version/s: (was: 1.12.0) > Index Tooling for Oak 1.10 > -- > > Key: OAK-7106 > URL: https://issues.apache.org/jira/browse/OAK-7106 > Project: Jackrabbit Oak > Issue Type: Epic > Components: indexing, run >Reporter: Chetan Mehrotra >Priority: Major > Fix For: 1.14.0 > > > Epic to track tooling work for Oak 1.10 release -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-5984) Property indexes can get ouf of sync
[ https://issues.apache.org/jira/browse/OAK-5984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-5984: -- Fix Version/s: (was: 1.12.0) > Property indexes can get ouf of sync > > > Key: OAK-5984 > URL: https://issues.apache.org/jira/browse/OAK-5984 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: property-index >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Major > Fix For: 1.14.0 > > > Property indexes can get out of sync for the following reasons: > * the index was disabled for some time > * the property index component was not started / configured > * the index definition was changed without reindexing -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6597) rep:excerpt not working for content indexed by aggregation in lucene
[
https://issues.apache.org/jira/browse/OAK-6597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-6597:
--
Fix Version/s: (was: 1.12.0)
> rep:excerpt not working for content indexed by aggregation in lucene
>
>
> Key: OAK-6597
> URL: https://issues.apache.org/jira/browse/OAK-6597
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.6.1, 1.7.6, 1.8.0
>Reporter: Dirk Rudolph
>Assignee: Chetan Mehrotra
>Priority: Major
> Labels: excerpt
> Fix For: 1.14.0
>
> Attachments: excerpt-with-aggregation-test.patch
>
>
> I mentioned that properties that got indexed due to an aggregation are not
> considered for excerpts (highlighting) as they are not indexed as stored
> fields.
> See the attached patch that implements a test for excerpts in
> {{LuceneIndexAggregationTest2}}.
> It creates the following structure:
> {code}
> /content/foo [test:Page]
> + bar (String)
> - jcr:content [test:PageContent]
> + bar (String)
> {code}
> where both strings (the _bar_ property at _foo_ and the _bar_ property at
> _jcr:content_) contain different text.
> Afterwards it queries for 2 terms ("tinc*" and "aliq*") that either exist in
> _/content/foo/bar_ or _/content/foo/jcr:content/bar_ but not in both. For the
> former one the excerpt is properly provided for the later one it isn't.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7166) Union with different selector names
[
https://issues.apache.org/jira/browse/OAK-7166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-7166:
--
Fix Version/s: (was: 1.12.0)
> Union with different selector names
> ---
>
> Key: OAK-7166
> URL: https://issues.apache.org/jira/browse/OAK-7166
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.14.0
>
>
> The following query returns the wrong nodes:
> {noformat}
> /jcr:root/libs/(* | */* | */*/* | */*/*/* | */*/*/*/*)/install
> select b.[jcr:path] as [jcr:path], b.[jcr:score] as [jcr:score], b.* from
> [nt:base] as a
> inner join [nt:base] as b on ischildnode(b, a)
> where ischildnode(a, '/libs') and name(b) = 'install'
> union select c.[jcr:path] as [jcr:path], c.[jcr:score] as [jcr:score], c.*
> from [nt:base] as a
> inner join [nt:base] as b on ischildnode(b, a)
> inner join [nt:base] as c on ischildnode(c, b)
> where ischildnode(a, '/libs') and name(c) = 'install'
> union select d.[jcr:path] as [jcr:path], d.[jcr:score] as [jcr:score], d.*
> from [nt:base] as a
> inner join [nt:base] as b on ischildnode(b, a)
> inner join [nt:base] as c on ischildnode(c, b)
> inner join [nt:base] as d on ischildnode(d, c)
> where ischildnode(a, '/libs') and name(d) = 'install'
> {noformat}
> If I change the selector name to "x" in each subquery, then it works. There
> is no XPath version of this workaround:
> {noformat}
> select x.[jcr:path] as [jcr:path], x.[jcr:score] as [jcr:score], x.* from
> [nt:base] as a
> inner join [nt:base] as x on ischildnode(x, a)
> where ischildnode(a, '/libs') and name(x) = 'install'
> union select x.[jcr:path] as [jcr:path], x.[jcr:score] as [jcr:score], x.*
> from [nt:base] as a
> inner join [nt:base] as b on ischildnode(b, a)
> inner join [nt:base] as x on ischildnode(x, b)
> where ischildnode(a, '/libs') and name(x) = 'install'
> union select x.[jcr:path] as [jcr:path], x.[jcr:score] as [jcr:score], x.*
> from [nt:base] as a
> inner join [nt:base] as b on ischildnode(b, a)
> inner join [nt:base] as c on ischildnode(c, b)
> inner join [nt:base] as x on ischildnode(x, c)
> where ischildnode(a, '/libs') and name(x) = 'install'
> {noformat}
> Need to check if this is a Oak bug, or a bug in the query tool I use.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-3919) Properly manage APIs / SPIs intended for public consumption
[
https://issues.apache.org/jira/browse/OAK-3919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-3919:
--
Fix Version/s: 1.14.0
> Properly manage APIs / SPIs intended for public consumption
> ---
>
> Key: OAK-3919
> URL: https://issues.apache.org/jira/browse/OAK-3919
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Michael Dürig
>Priority: Major
> Labels: modularization, technical_debt
> Fix For: 1.12.0, 1.14.0
>
>
> This is a follow up to OAK-3842, which removed package export declarations
> for all packages that we either do not want to be used outside of Oak or that
> are not stable enough yet.
> This issue is to identify those APIs and SPIs of Oak that we actually *want*
> to export and to refactor those such we *can* export them.
> Candidates that are currently used from upstream projects I know of are:
> {code}
> org.apache.jackrabbit.oak.plugins.observation
> org.apache.jackrabbit.oak.spi.commit
> org.apache.jackrabbit.oak.spi.state
> org.apache.jackrabbit.oak.commons
> org.apache.jackrabbit.oak.plugins.index.lucene
> {code}
> I suggest to create subtask for those we want to go forward with.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7382) Cloud datastore without local disk
[ https://issues.apache.org/jira/browse/OAK-7382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7382: -- Fix Version/s: 1.14.0 > Cloud datastore without local disk > -- > > Key: OAK-7382 > URL: https://issues.apache.org/jira/browse/OAK-7382 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: blob, blob-cloud >Reporter: Thomas Mueller >Assignee: Amit Jain >Priority: Major > Fix For: 1.12.0, 1.14.0 > > > Currently, the S3 datastores need local disk to work (not sure about the > Azure one). > This should not be needed (not for upload, caching,...). > Also, temporary files for garbage collection should not be needed (instead, > use temporary binaries, possibly written to S3 / Azure). > Really everything should fit in a few MB of memory. > For S3, it might be needed to read a few MB of data into memory, and then > possibly do a multipart upload: > > https://stackoverflow.com/questions/8653146/can-i-stream-a-file-upload-to-s3-without-a-content-length-header -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6628) More precise indexRules support via filtering criteria on property
[
https://issues.apache.org/jira/browse/OAK-6628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-6628:
--
Fix Version/s: (was: 1.12.0)
> More precise indexRules support via filtering criteria on property
> --
>
> Key: OAK-6628
> URL: https://issues.apache.org/jira/browse/OAK-6628
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Chetan Mehrotra
>Priority: Major
> Fix For: 1.14.0
>
>
> For Lucene index we currently support indexRules based on nodetype. Here the
> recommendation is that users must use most precise nodeType/mixinType to
> target the indexing rule so that only relevant nodes are indexed.
> For many Sling based applications its being seen that lots of content is
> nt:unstructured and it uses {{sling:resourceType}} property to distinguish
> various such nt:unstructured nodes. Currently its not possible to target
> index definition to index only those nt:unstructured which have specific
> {{sling:resourceType}}. Which makes it harder to provide a more precise index
> definitions.
> To help such cases we can generalize the indexRule support via a filtering
> criteria
> {noformat}
> activityIndex
> - type = "lucene"
> + indexRules
> + nt:unstructured
> - filter-property = "sling:resourceType"
> - filter-value = "app/activitystreams/components/activity"
> + properties
> - jcr:primaryType = "nt:unstructured"
> + verb
> - propertyIndex = true
> - name = "verb"
> {noformat}
> So indexRule would have 2 more config properties
> * filter-property - Name of property to match
> * filter-value - The value to match
> *Indexing*
> At time of indexing currently LuceneIndexEditor does a
> {{indexDefinition.getApplicableIndexingRule}} passing it the NodeState.
> Currently this checks only for jcr:PrimaryType and jxr:mixins to find
> matching rule.
> This logic would need to be extended to also check if any filter-property is
> defined in definition. If yes then check if NodeState has that value
> *Querying*
> On query side we need to change the IndexPlanner where it currently use query
> nodetype for finding matching indexRule. In addition it would need to pass on
> the property restrictions and the rule only be matched if the property
> restriction matches the filter
> *Open Item*
> # How to handle change in filter-property value. I think we have similar
> problem currently if an index nodes nodeType gets changed. In such a case we
> do not remove it from index. So we need to solve that for both
> # Ensure that all places where rules are matched account for this filter
> concept
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-6261) Log queries that sort by un-indexed properties
[ https://issues.apache.org/jira/browse/OAK-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6261: -- Fix Version/s: (was: 1.12.0) > Log queries that sort by un-indexed properties > -- > > Key: OAK-6261 > URL: https://issues.apache.org/jira/browse/OAK-6261 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Minor > Fix For: 1.14.0 > > > Queries that can read many nodes, and sort by properties that are not > indexed, can be very slow. This includes for example fulltext queries. > As a start, it might make sense to log an "info" level message (but avoid > logging the same message each time a query is run). Per configuration, this > could be turned to "warning". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-5787) BlobStore should be Closeable
[
https://issues.apache.org/jira/browse/OAK-5787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-5787:
--
Fix Version/s: 1.14.0
> BlobStore should be Closeable
> -
>
> Key: OAK-5787
> URL: https://issues.apache.org/jira/browse/OAK-5787
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: blob
>Reporter: Julian Reschke
>Assignee: Amit Jain
>Priority: Minor
> Fix For: 1.12.0, 1.14.0
>
>
> {{DocumentNodeStore}} currently calls {{close()}} if the blob store instance
> implements {{Closeable}}.
> This has led to problems where wrapper implementations did not implement it,
> and thus the actual blob store instance wasn't properly shut down.
> Proposal: make {{BlobStore}} extend {{Closeable}} and get rid of all
> {{instanceof}} checks.
> [~tmueller] [~amitjain] - feedback appreciated.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7998) [DirectBinaryAccess] Verify that binary exists in cloud before creating signed download URI
[ https://issues.apache.org/jira/browse/OAK-7998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7998: -- Fix Version/s: (was: 1.12.0) > [DirectBinaryAccess] Verify that binary exists in cloud before creating > signed download URI > --- > > Key: OAK-7998 > URL: https://issues.apache.org/jira/browse/OAK-7998 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: blob-cloud, blob-cloud-azure >Affects Versions: 1.10.0 >Reporter: Matt Ryan >Assignee: Matt Ryan >Priority: Major > Fix For: 1.14.0 > > > IIUC, the direct binary access download logic doesn't actually verify that > the requested blob is available in the cloud before creating the signed > download URI. It is possible that a user could request a download URI for a > blob that is "in the repo" but hasn't actually been uploaded yet. > We should verify this by uploading a new blob, preventing it being uploaded > to the cloud (retain in cache), and then request the download URI. We should > get a null back or get some other error or exception; if we get a URI it > would return an HTTP 404 if the blob is not actually uploaded yet (maybe this > would also be ok). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7098) Refactor common logic between IndexUpdate and DocumentStoreIndexer
[ https://issues.apache.org/jira/browse/OAK-7098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7098: -- Fix Version/s: (was: 1.12.0) > Refactor common logic between IndexUpdate and DocumentStoreIndexer > -- > > Key: OAK-7098 > URL: https://issues.apache.org/jira/browse/OAK-7098 > Project: Jackrabbit Oak > Issue Type: Task > Components: indexing, run >Reporter: Chetan Mehrotra >Priority: Major > Fix For: 1.14.0 > > > DocumentStoreIndexer implements an alternative way of indexing which differs > from diff based indexing done by IndexUpdate. However some part of logic is > commong > We should refactor them and abstract them out so both can share same logic -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7079) Enable oak-run indexing to connect to secondary node in Mongo replica set
[ https://issues.apache.org/jira/browse/OAK-7079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7079: -- Fix Version/s: 1.14.0 > Enable oak-run indexing to connect to secondary node in Mongo replica set > - > > Key: OAK-7079 > URL: https://issues.apache.org/jira/browse/OAK-7079 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk, run >Reporter: Chetan Mehrotra >Priority: Major > Fix For: 1.12.0, 1.14.0 > > > With OAK-6353 support for document order traversal based indexing has been > added. Currently it connects to Mongo primary. > We need to test and validate if it can be made only to connect to Mongo > secondary for below 2 cases > # Pre created checkpoint - Here checkpoint is created already and then > oak-run *only* connects to Mongo secondary > # Online indexing - Here oak-run would also create checkpoint. However it > would need to be ensured that when it performs the document order traversal > query that query is handled by Mongo secondary and oak-run logic ensures that > secondary node has the created checkpoint -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7079) Enable oak-run indexing to connect to secondary node in Mongo replica set
[ https://issues.apache.org/jira/browse/OAK-7079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7079: -- Fix Version/s: (was: 1.12.0) > Enable oak-run indexing to connect to secondary node in Mongo replica set > - > > Key: OAK-7079 > URL: https://issues.apache.org/jira/browse/OAK-7079 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk, run >Reporter: Chetan Mehrotra >Priority: Major > Fix For: 1.14.0 > > > With OAK-6353 support for document order traversal based indexing has been > added. Currently it connects to Mongo primary. > We need to test and validate if it can be made only to connect to Mongo > secondary for below 2 cases > # Pre created checkpoint - Here checkpoint is created already and then > oak-run *only* connects to Mongo secondary > # Online indexing - Here oak-run would also create checkpoint. However it > would need to be ensured that when it performs the document order traversal > query that query is handled by Mongo secondary and oak-run logic ensures that > secondary node has the created checkpoint -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6577) Determine the approach for reindexing in case of CompositeNodeStore setups
[ https://issues.apache.org/jira/browse/OAK-6577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6577: -- Fix Version/s: (was: 1.12.0) > Determine the approach for reindexing in case of CompositeNodeStore setups > -- > > Key: OAK-6577 > URL: https://issues.apache.org/jira/browse/OAK-6577 > Project: Jackrabbit Oak > Issue Type: Task > Components: composite, indexing >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Major > Fix For: 1.14.0 > > > Current index tooling is designed to work with a single NodeStore setups. We > should determine how reindexing should be done for CompositeNodeStore setup > specially where one of the mount is private and read only -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6757) Convert oak-auth-ldap to OSGi R6 annotations
[ https://issues.apache.org/jira/browse/OAK-6757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6757: -- Fix Version/s: (was: 1.12.0) > Convert oak-auth-ldap to OSGi R6 annotations > > > Key: OAK-6757 > URL: https://issues.apache.org/jira/browse/OAK-6757 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: auth-ldap >Reporter: Robert Munteanu >Priority: Major > Fix For: 1.14.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
