[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: 1.16.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, 1.16.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-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: 1.16.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, 1.16.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-6774) Convert oak-upgrade to OSGi R6 annotations
[ https://issues.apache.org/jira/browse/OAK-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6774: -- Fix Version/s: 1.16.0 > Convert oak-upgrade to OSGi R6 annotations > -- > > Key: OAK-6774 > URL: https://issues.apache.org/jira/browse/OAK-6774 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: upgrade >Reporter: Robert Munteanu >Priority: Major > Fix For: 1.14.0, 1.16.0 > > -- 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: 1.16.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, 1.16.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-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: 1.16.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, 1.16.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-6836) OnRC report
[
https://issues.apache.org/jira/browse/OAK-6836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-6836:
--
Fix Version/s: 1.16.0
> OnRC report
> ---
>
> Key: OAK-6836
> URL: https://issues.apache.org/jira/browse/OAK-6836
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Valentin Olteanu
>Priority: Minor
> Labels: production
> Fix For: 1.14.0, 1.16.0
>
> Attachments: gcreport.png
>
>
> Currently, the information regarding an online revision cleanup execution is
> scattered across multiple log lines and partially available in the attributes
> of {{SegmentRevisionGarbageCollection}} MBean.
> While useful for debugging, this is hard to grasp for users that need to
> understand the full process to be able to read it.
> The idea would be to create a "report" with all the details of an execution
> and output it at the end - write to log, but also store it in the MBean, from
> where it can be consumed by monitoring and health checks.
> In the MBean, this would replace the _Last*_ attributes.
> In the logs, this could replace all the intermediary logs (switch them to
> DEBUG).
--
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: 1.16.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, 1.16.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-5159) Killing the process may stop async index update to to 30 minutes, for DocumentStore (MongoDB, RDB)
[ https://issues.apache.org/jira/browse/OAK-5159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-5159: -- Fix Version/s: 1.16.0 > Killing the process may stop async index update to to 30 minutes, for > DocumentStore (MongoDB, RDB) > -- > > Key: OAK-5159 > URL: https://issues.apache.org/jira/browse/OAK-5159 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing >Reporter: Thomas Mueller >Priority: Major > Labels: resilience > Fix For: 1.14.0, 1.16.0 > > > Same as OAK-2108, when using a DocumentStore based repository (MongoDB, > RDBMK). This is also a problem in the single-cluster-node case, not just when > using multiple cluster node. > When killing a node that is running the sync index update, then this async > index update will not run for up to 15 minutes, because the lease time is set > to 15 minutes. > We could probably use Oak / Sling Discovery to improve the situation. -- 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: 1.16.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, 1.16.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-8343) Allow queries to be delayed until an index is available
[ https://issues.apache.org/jira/browse/OAK-8343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-8343: -- Fix Version/s: 1.16.0 > Allow queries to be delayed until an index is available > --- > > Key: OAK-8343 > URL: https://issues.apache.org/jira/browse/OAK-8343 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene, query >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Major > Fix For: 1.14.0, 1.16.0 > > Attachments: OAK-8343-b.patch, OAK-8343.patch > > > Currently, indexes are built asynchronously. That is, if an index definition > is added, the index is eventually built, but it's quite hard to say when it > is ready for queries. This can be specially a problem right after the initial > repository initialization, or after an upgrade. > In theory, system startup could be delayed until all indexes are ready (e.g. > set the "reindex" flag for important indexes, and at startup, wait until the > "reindex" flag is set to "false"). However, doing that would block threads > that _don't_ need an index. It would be better to only block threads that > actually do run queries. That would make startup deterministic, without > delaying other threads unnecessarily. > To solve the problem, we can add a property "waitForIndex" in the index > definition (just Lucene indexes is fine for now, as those are the important > asynchronous ones). If set, then queries that potentially use those indexes > are delayed, until the indexes are ready for sure. Reindex would need to > remove that property (the same as it removes e.g. refresh or sets reindex to > false). For added security, queries are only blocked as long as "reindex" is > also set to true (this ensures that waitForIndex is removed eventually), and > waiting should time out after 2 minutes, to ensure the feature doesn't block > startup forever if indexing fails for some reason. -- 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: 1.16.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, 1.16.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-7074) Ensure that all Documents are read with document order traversal indexing
[ https://issues.apache.org/jira/browse/OAK-7074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7074: -- Fix Version/s: 1.16.0 > Ensure that all Documents are read with document order traversal indexing > - > > Key: OAK-7074 > URL: https://issues.apache.org/jira/browse/OAK-7074 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk, run >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Major > Fix For: 1.14.0, 1.16.0 > > > With OAK-6353 support was added for document order traversal indexing. In > this mode we open a DB cursor and try to read all documents from it using > document order traversal. Such a cursor may remain open for long time (2-4 > hrs) and its possible that document may get reordered by the Mongo storage > engine. This would result in 2 aspects to be thought about > # Duplicate documents - Same document may appear more than once in result set > # Possibly missed document - It may be a possibility that a document got > moved and missed becoming part of cursor. > Both these aspects would need to be handled -- 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: 1.16.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, 1.16.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-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: 1.16.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, 1.16.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-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: 1.16.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, 1.16.0 > > -- 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: 1.16.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, 1.16.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6762) Convert oak-blob to OSGi R6 annotations
[ https://issues.apache.org/jira/browse/OAK-6762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6762: -- Fix Version/s: 1.16.0 > Convert oak-blob to OSGi R6 annotations > --- > > Key: OAK-6762 > URL: https://issues.apache.org/jira/browse/OAK-6762 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: blob >Reporter: Robert Munteanu >Priority: Major > Fix For: 1.14.0, 1.16.0 > > -- 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.16.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.14.0, 1.16.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6773) Convert oak-store-composite to OSGi R6 annotations
[ https://issues.apache.org/jira/browse/OAK-6773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6773: -- Fix Version/s: 1.16.0 > Convert oak-store-composite to OSGi R6 annotations > -- > > Key: OAK-6773 > URL: https://issues.apache.org/jira/browse/OAK-6773 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: composite >Reporter: Robert Munteanu >Priority: Major > Fix For: 1.14.0, 1.16.0 > > -- 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.16.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, 1.16.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-3598) Export cache related classes for usage in other oak bundle
[
https://issues.apache.org/jira/browse/OAK-3598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-3598:
--
Fix Version/s: 1.16.0
> Export cache related classes for usage in other oak bundle
> --
>
> Key: OAK-3598
> URL: https://issues.apache.org/jira/browse/OAK-3598
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: cache
>Reporter: Chetan Mehrotra
>Priority: Major
> Labels: tech-debt
> Fix For: 1.14.0, 1.16.0
>
>
> For OAK-3092 oak-lucene would need to access classes from
> {{org.apache.jackrabbit.oak.cache}} package. For now its limited to
> {{CacheStats}} to expose the cache related statistics.
> This task is meant to determine steps needed to export the package
> * Update the pom.xml to export the package
> * Review current set of classes to see if they need to be reviewed
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-6919) SegmentCache might introduce unwanted memory references to SegmentId instances
[
https://issues.apache.org/jira/browse/OAK-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-6919:
--
Fix Version/s: 1.16.0
> SegmentCache might introduce unwanted memory references to SegmentId instances
> --
>
> Key: OAK-6919
> URL: https://issues.apache.org/jira/browse/OAK-6919
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Francesco Mari
>Assignee: Francesco Mari
>Priority: Major
> Fix For: 1.14.0, 1.16.0
>
>
> {{SegmentCache}} contains, through the underlying Guava cache, hard
> references to both {{SegmentId}} and {{Segment}} instances. Thus,
> {{SegmentCache}} contributes to the computation of in-memory references that,
> in turn, constitute the root references of the garbage collection algorithm.
> Further investigations are needed to assess this statement but, if
> {{SegmentCache}} is proved to be problematic, there are some possible
> solutions.
> For example, {{SegmentCache}} might be reworked to store references to
> MSB/LSB pairs as keys, instead of to {{SegmentId}} instances. Moreover,
> instead of referencing {{Segment}} instances as values, {{SegmentCache}}
> might hold references to their underlying {{ByteBuffer}}. With these changes
> in place, {{SegmentCache}} would not interfere with {{SegmentTracker}} and
> the garbage collection algorithm.
--
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: 1.16.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, 1.16.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-7300) Lucene Index: per-column selectivity to improve cost estimation
[ https://issues.apache.org/jira/browse/OAK-7300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7300: -- Fix Version/s: 1.16.0 > Lucene Index: per-column selectivity to improve cost estimation > --- > > Key: OAK-7300 > URL: https://issues.apache.org/jira/browse/OAK-7300 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene, query >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Major > Fix For: 1.14.0, 1.16.0 > > > In OAK-6735 we have improved cost estimation for Lucene indexes, however the > following case is still not working as expected: a very common property is > indexes (many nodes have that property), and each value of that property is > more or less unique. In this case, currently the cost estimation is the total > number of documents that contain that property. Assuming the condition > "property is not null" this is correct, however for the common case "property > = x" the estimated cost is far too high. > A known workaround is to set the "costPerEntry" for the given index to a low > value, for example 0.2. However this isn't a good solution, as it affects all > properties and queries. > It would be good to be able to set the selectivity per property, for example > by specifying the number of distinct values, or (better yet) the average > number of entries for a given key (1 for unique values, 2 meaning for each > distinct values there are two documents on average). > That value can be set manually (cost override), and it can be set > automatically, e.g. when building the index, or updated from time to time > during the index update, using a cardinality > estimation algorithm. That doesn't have to be accurate; we could use an rough > approximation such as hyperbitbit. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6165) Create compound index on _sdType and _sdMaxRevTime (RDB)
[ https://issues.apache.org/jira/browse/OAK-6165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6165: -- Fix Version/s: 1.16.0 > Create compound index on _sdType and _sdMaxRevTime (RDB) > > > Key: OAK-6165 > URL: https://issues.apache.org/jira/browse/OAK-6165 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: rdbmk >Reporter: Chetan Mehrotra >Assignee: Julian Reschke >Priority: Major > Fix For: 1.14.0, 1.16.0 > > > Clone for OAK-6129 for RDB i.e. create index on OAK-6129on _sdType and > _sdMaxRevTime. This is required to run queries issued by the Revision GC > efficiently. -- 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: 1.16.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, 1.16.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-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.16.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, 1.16.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-5369) Lucene Property Index: Syntax Error, cannot parse
[
https://issues.apache.org/jira/browse/OAK-5369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-5369:
--
Fix Version/s: 1.16.0
> Lucene Property Index: Syntax Error, cannot parse
> -
>
> Key: OAK-5369
> URL: https://issues.apache.org/jira/browse/OAK-5369
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.14.0, 1.16.0
>
>
> The following query throws an exception in Apache Lucene:
> {noformat}
> /jcr:root//*[jcr:contains(., 'hello -- world')]
> 22.12.2016 16:42:54.511 *WARN* [qtp1944702753-3846]
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex query via
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex@1c0006db
> failed.
> java.lang.RuntimeException: INVALID_SYNTAX_CANNOT_PARSE: Syntax Error, cannot
> parse hello -- world:
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.tokenToQuery(LucenePropertyIndex.java:1450)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.tokenToQuery(LucenePropertyIndex.java:1418)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.access$900(LucenePropertyIndex.java:180)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$3.visitTerm(LucenePropertyIndex.java:1353)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$3.visit(LucenePropertyIndex.java:1307)
> at
> org.apache.jackrabbit.oak.query.fulltext.FullTextContains.accept(FullTextContains.java:63)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.getFullTextQuery(LucenePropertyIndex.java:1303)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.getLuceneRequest(LucenePropertyIndex.java:791)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.access$300(LucenePropertyIndex.java:180)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$1.loadDocs(LucenePropertyIndex.java:375)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$1.computeNext(LucenePropertyIndex.java:317)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$1.computeNext(LucenePropertyIndex.java:306)
> at
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
> at
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$LucenePathCursor$1.hasNext(LucenePropertyIndex.java:1571)
> at com.google.common.collect.Iterators$7.computeNext(Iterators.java:645)
> at
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
> at
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
> at
> org.apache.jackrabbit.oak.spi.query.Cursors$PathCursor.hasNext(Cursors.java:205)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$LucenePathCursor.hasNext(LucenePropertyIndex.java:1595)
> at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.next(SelectorImpl.java:420)
> at
> org.apache.jackrabbit.oak.query.QueryImpl$RowIterator.fetchNext(QueryImpl.java:828)
> at
> org.apache.jackrabbit.oak.query.QueryImpl$RowIterator.hasNext(QueryImpl.java:853)
> at
> org.apache.jackrabbit.oak.jcr.query.QueryResultImpl$1.fetch(QueryResultImpl.java:98)
> at
> org.apache.jackrabbit.oak.jcr.query.QueryResultImpl$1.(QueryResultImpl.java:94)
> at
> org.apache.jackrabbit.oak.jcr.query.QueryResultImpl.getRows(QueryResultImpl.java:78)
> Caused by:
> org.apache.lucene.queryparser.flexible.standard.parser.ParseException: Syntax
> Error, cannot parse hello -- world:
> at
> org.apache.lucene.queryparser.flexible.standard.parser.StandardSyntaxParser.generateParseException(StandardSyntaxParser.java:1054)
> at
> org.apache.lucene.queryparser.flexible.standard.parser.StandardSyntaxParser.jj_consume_token(StandardSyntaxParser.java:936)
> at
> org.apache.lucene.queryparser.flexible.standard.parser.StandardSyntaxParser.Clause(StandardSyntaxParser.java:486)
> at
> org.apache.lucene.queryparser.flexible.standard.parser.StandardSyntaxParser.ModClause(StandardSyntaxParser.java:303)
> at
> org.apache.lucene.queryparser.flexible.standard.parser.StandardSyntaxParser.ConjQuery(StandardSyntaxParser.java:234)
> at
> org.apache.lucene.queryparser.flexible.standard.parser.StandardSyntaxParser.DisjQuery(StandardSyntaxParser.java:204)
> at
> org.apache.lucene.queryparser.f
[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: 1.16.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, 1.16.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-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: 1.16.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, 1.16.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7261) DocumentStore: inconsistent behaviour for invalid Strings as document ID
[ https://issues.apache.org/jira/browse/OAK-7261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7261: -- Fix Version/s: 1.16.0 > DocumentStore: inconsistent behaviour for invalid Strings as document ID > > > Key: OAK-7261 > URL: https://issues.apache.org/jira/browse/OAK-7261 > Project: Jackrabbit Oak > Issue Type: Bug > Components: documentmk, mongomk, rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Fix For: 1.14.0, 1.16.0 > > > - H2DB and Derby roundtrip any string > - PostgreSQL rejects the invalid string early > - DB2 and Oracle fail the same way as segment store (they persist the > replacement character) (see OAK-5506) > - MySQL and SQLServer fail the same way as DB2 and Oracle, but here it's the > RDBDocumentStore's fault, because the ID column is binary, and we transform > to byte sequences ourselves > - Mongo claims it saved the document, but upon lookup, returns something > with a different ID > Note that due to how RDB reads work, the returned document has the ID that > was requested, not what the DB actually contains. > -- 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: 1.16.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, 1.16.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-7425) Add discovery mechanism for tooling implementations
[
https://issues.apache.org/jira/browse/OAK-7425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-7425:
--
Fix Version/s: 1.16.0
> Add discovery mechanism for tooling implementations
> ---
>
> Key: OAK-7425
> URL: https://issues.apache.org/jira/browse/OAK-7425
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Francesco Mari
>Assignee: Francesco Mari
>Priority: Major
> Labels: technical_debt
> Fix For: 1.14.0, 1.16.0
>
> Attachments: 001.patch
>
>
> This issue proposes an idea for discovering implementations of tooling for
> the Segment Store. Developing a tool for the Segment Store should include the
> following step.
> * The tool compiles against the {{NodeStore}} API and the API exposed through
> the oak-segment-tar-tool-api. In particular, the tool uses the
> {{ToolingSupportFactory}} and related interfaces to instantiate a NodeStore
> and, optionally, a {{NodeState}} for the proc tree.
> * The tool runs with an implementation-dependent uber-jar in the classpath.
> The uber-jar includes the {{ToolingSupportFactory}} API, its implementation,
> and every other class required for the implementation to work. No other JARs
> is required to use the {{ToolingSupportFactory}} API. The tool uses the
> Java's {{ServiceLoader}} to instantiate an implementation of
> {{ToolingSupportFactory}}. The uber-jar is the {{oak-segment-tar-tool}}
> module.
> The patch falls short of fully implementing the use case because
> {{oak-segment-tar-tool-api}} is not versioned independently from Oak. This
> can't happen at the moment because {{oak-store-spi}} and its dependencies are
> not independently versioned either. The workflow described above could still
> work, but only because the {{NodeStore}} and {{NodeState}} API are quite
> stable. A cleaner solution to dependency management is required in the long
> run.
--
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: 1.16.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, 1.16.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-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: 1.16.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 >Priority: Major > Fix For: 1.14.0, 1.16.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-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: 1.16.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, 1.16.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-3717) Make it possible to declare SynonymFilter within Analyzer with WN dictionary
[
https://issues.apache.org/jira/browse/OAK-3717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-3717:
--
Fix Version/s: 1.16.0
> Make it possible to declare SynonymFilter within Analyzer with WN dictionary
>
>
> Key: OAK-3717
> URL: https://issues.apache.org/jira/browse/OAK-3717
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
>Priority: Major
> Fix For: 1.14.0, 1.16.0
>
>
> Currently one can compose Lucene Analyzers via
> [composition|http://jackrabbit.apache.org/oak/docs/query/lucene.html#Create_analyzer_via_composition]
> within an index definition. It'd be good to be able to also use
> {{SynonymFIlter}} in there, eventually decorated with
> {{WordNetSynonymParser}} to leverage WordNet synonym files.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7116) Use JMX mode to reindex on SegmentNodeStore without requiring manual steps
[ https://issues.apache.org/jira/browse/OAK-7116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7116: -- Fix Version/s: 1.16.0 > Use JMX mode to reindex on SegmentNodeStore without requiring manual steps > -- > > Key: OAK-7116 > URL: https://issues.apache.org/jira/browse/OAK-7116 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: run >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Major > Fix For: 1.14.0, 1.16.0 > > > oak-run indexing for SegmentNodeStore currently require following steps while > performing indexing against a repository which is in use [1] > # Create checkpoint via MBean and pass it as part of cli args > # Perform actual indexing with read only access to repo > # Import the index via MBean operation > As per current documented steps #1 and #3 are manual. This can potentially be > simplified by directly using JMX operation from within oak-run as currently > for accessing SegmentNodeStore oak-run needs to run on same host as actual > application > *JMX Access* > JMX access can be done via following ways > # Application using Oak has JMX remote > ## Enabled and same info provided as cli args > ## Not enabled - In such a case we can rely on > ### pid and [local > connection|https://stackoverflow.com/questions/13252914/how-to-connect-to-a-local-jmx-server-by-knowing-the-process-id] > or [attach|https://github.com/nickman/jmxlocal] > ### Or query all running java prcess jmx and check if SegmentNodeStore repo > path is same as one provided in cli > # Application using OAk > *Proposed Approach* > # Establish the JMX connection > # Create checkpoint using the JMX connection programatically > # Perform indexing with read only access > # Import the index via JMX access > With this indexing support for SegmentNodeStore would be at par with > DocumentNodeStore in terms of ease of use > [1] https://jackrabbit.apache.org/oak/docs/query/oak-run-indexing.html -- 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.16.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.14.0, 1.16.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-5506) reject item names with unpaired surrogates early
[
https://issues.apache.org/jira/browse/OAK-5506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-5506:
--
Fix Version/s: 1.16.0
> reject item names with unpaired surrogates early
>
>
> Key: OAK-5506
> URL: https://issues.apache.org/jira/browse/OAK-5506
> Project: Jackrabbit Oak
> Issue Type: Wish
> Components: core, jcr, segment-tar
>Affects Versions: 1.5.18
>Reporter: Julian Reschke
>Priority: Minor
> Labels: resilience
> Fix For: 1.14.0, 1.16.0
>
> Attachments: OAK-5506-01.patch, OAK-5506-02.patch, OAK-5506-4.diff,
> OAK-5506-bench.diff, OAK-5506-jcr-level.diff, OAK-5506-name-conversion.diff,
> OAK-5506-segment.diff, OAK-5506-segment2.diff, OAK-5506-segment3.diff,
> OAK-5506.diff, ValidNamesTest.java
>
>
> Apparently, the following node name is accepted:
>{{"foo\ud800"}}
> but a subsequent {{getPath()}} call fails:
> {noformat}
> javax.jcr.InvalidItemStateException: This item [/test_node/foo?] does not
> exist anymore
> at
> org.apache.jackrabbit.oak.jcr.delegate.ItemDelegate.checkAlive(ItemDelegate.java:86)
> at
> org.apache.jackrabbit.oak.jcr.session.operation.ItemOperation.checkPreconditions(ItemOperation.java:34)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.prePerform(SessionDelegate.java:615)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:205)
> at
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.perform(ItemImpl.java:112)
> at
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.getPath(ItemImpl.java:140)
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl.getPath(NodeImpl.java:106)
> at
> org.apache.jackrabbit.oak.jcr.ValidNamesTest.nameTest(ValidNamesTest.java:271)
> at
> org.apache.jackrabbit.oak.jcr.ValidNamesTest.testUnpairedSurrogate(ValidNamesTest.java:259)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source){noformat}
> (test case follows)
--
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: 1.16.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, 1.16.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-5544) Improve indexing resilience
[ https://issues.apache.org/jira/browse/OAK-5544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-5544: -- Fix Version/s: 1.16.0 > Improve indexing resilience > --- > > Key: OAK-5544 > URL: https://issues.apache.org/jira/browse/OAK-5544 > Project: Jackrabbit Oak > Issue Type: Epic > Components: lucene >Reporter: Alexander Saar >Assignee: Chetan Mehrotra >Priority: Critical > Labels: resilience > Fix For: 1.14.0, 1.16.0 > > > grouping the improvements for indexer resilience in this issue for easier > tracking -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6187) Index usage analysis (which index was used when and how)
[ https://issues.apache.org/jira/browse/OAK-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6187: -- Fix Version/s: 1.16.0 > Index usage analysis (which index was used when and how) > > > Key: OAK-6187 > URL: https://issues.apache.org/jira/browse/OAK-6187 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: query >Reporter: Thomas Mueller >Priority: Minor > Fix For: 1.14.0, 1.16.0 > > > In order to reduce space usage, unused indexes should be removed or trimmed. > Trimmed, because an index definition might contain "too much" (specially > Lucene indexes, which index multiple properties and can be very large). > One solution is to > * log each query (avoiding duplicates), > * include which indexes were used, > * from that generate the minimum index definitions, > * compared with existing indexes, get the list of unused indexes and index > features since day X. -- 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: 1.16.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, 1.16.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-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: 1.16.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, 1.16.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-7684) fix maven warnings on oak-solr-osgi
[
https://issues.apache.org/jira/browse/OAK-7684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-7684:
--
Fix Version/s: 1.16.0
> fix maven warnings on oak-solr-osgi
> ---
>
> Key: OAK-7684
> URL: https://issues.apache.org/jira/browse/OAK-7684
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: solr
>Reporter: Julian Reschke
>Assignee: Tommaso Teofili
>Priority: Minor
> Fix For: 1.14.0, 1.16.0
>
>
> {noformat}
> [WARNING] Bundle org.apache.jackrabbit:oak-solr-osgi:bundle:1.10-SNAPSHOT :
> NoClassDefFoundError: com/vividsolutions/jts/io/InStream
> [WARNING] Bundle org.apache.jackrabbit:oak-solr-osgi:bundle:1.10-SNAPSHOT :
> NoClassDefFoundError: com/vividsolutions/jts/io/OutStream
> [WARNING] Bundle org.apache.jackrabbit:oak-solr-osgi:bundle:1.10-SNAPSHOT :
> NoClassDefFoundError: com/vividsolutions/jts/geom/CoordinateSequenceFilter
> [WARNING] Bundle org.apache.jackrabbit:oak-solr-osgi:bundle:1.10-SNAPSHOT :
> NoClassDefFoundError: com/vividsolutions/jts/geom/GeometryFilter
> [WARNING] Bundle org.apache.jackrabbit:oak-solr-osgi:bundle:1.10-SNAPSHOT :
> Unused Import-Package instructions: [com.sun.*]
> {noformat}
--
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.16.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.14.0, 1.16.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6766) Convert oak-lucene to OSGi R6 annotations
[ https://issues.apache.org/jira/browse/OAK-6766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6766: -- Fix Version/s: 1.16.0 > Convert oak-lucene to OSGi R6 annotations > - > > Key: OAK-6766 > URL: https://issues.apache.org/jira/browse/OAK-6766 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: lucene >Reporter: Robert Munteanu >Priority: Major > Fix For: 1.14.0, 1.16.0 > > -- 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.16.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.14.0, 1.16.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-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: 1.16.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, 1.16.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-5791) Reduce number of calls while adding a new node
[ https://issues.apache.org/jira/browse/OAK-5791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-5791: -- Fix Version/s: 1.16.0 > Reduce number of calls while adding a new node > --- > > Key: OAK-5791 > URL: https://issues.apache.org/jira/browse/OAK-5791 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk >Reporter: Chetan Mehrotra >Priority: Major > Fix For: 1.14.0, 1.16.0 > > > Adding a new child node currently takes 2 remote calls. We should look into > reducing this to 1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6062) Test failure: CopyBinariesTest.validateMigration
[
https://issues.apache.org/jira/browse/OAK-6062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-6062:
--
Fix Version/s: 1.16.0
> Test failure: CopyBinariesTest.validateMigration
>
>
> Key: OAK-6062
> URL: https://issues.apache.org/jira/browse/OAK-6062
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration, documentmk
>Reporter: Hudson
>Priority: Major
> Labels: CI, flaky-test, jenkins, test-failure
> Fix For: 1.14.0, 1.16.0
>
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #146 has failed.
> First failed run: [Jackrabbit Oak
> #146|https://builds.apache.org/job/Jackrabbit%20Oak/146/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/146/console]
> The test failure is:
> {noformat}
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest
> validateMigration[Copy references, no blobstores defined, document ->
> segment-tar](org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest)
> Time elapsed: 2.534 sec <<< ERROR!
> javax.jcr.RepositoryException: Failed to copy content
> at
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.prepare(CopyBinariesTest.java:183)
> Caused by: java.lang.IllegalStateException: Branch with failed reset
> at
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.prepare(CopyBinariesTest.java:183)
> Caused by: org.apache.jackrabbit.oak.api.CommitFailedException: OakOak0100:
> Branch reset failed
> at
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.prepare(CopyBinariesTest.java:183)
> Caused by: org.apache.jackrabbit.oak.plugins.document.DocumentStoreException:
> Empty branch cannot be reset
> at
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.prepare(CopyBinariesTest.java:183)
> {noformat}
--
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: 1.16.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, 1.16.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-3336) Abstract a full text index implementation to be extended by Lucene and Solr
[ https://issues.apache.org/jira/browse/OAK-3336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-3336: -- Fix Version/s: 1.16.0 > Abstract a full text index implementation to be extended by Lucene and Solr > --- > > Key: OAK-3336 > URL: https://issues.apache.org/jira/browse/OAK-3336 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene, query, solr >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili >Priority: Major > Fix For: 1.14.0, 1.16.0 > > > Current Lucene and Solr indexes implement quite a no. of features according > to their specific APIs, design and implementation. However in the long run, > while differences in APIs and implementations will / can of course stay, the > difference in design can make it hard to keep those features on par. > It'd be therefore nice to make it possible to abstract as much of design and > implementation bits as possible in an abstract full text implementation which > Lucene and Solr would extend according to their specifics. > An example advantage of this is that index time aggregation will be > implemented only once and therefore any bugfixes and improvements in that > area will be done in the abstract implementation rather than having to do > that in two places. -- 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: 1.16.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, 1.16.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-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: 1.16.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, 1.16.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-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: 1.16.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, 1.16.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-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.16.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, 1.16.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-5144) use 'allNodeTypes' of ChangeSet for nodeType-aggregate-filter
[ https://issues.apache.org/jira/browse/OAK-5144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-5144: -- Fix Version/s: 1.16.0 > use 'allNodeTypes' of ChangeSet for nodeType-aggregate-filter > - > > Key: OAK-5144 > URL: https://issues.apache.org/jira/browse/OAK-5144 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: jcr >Affects Versions: 1.5.14 >Reporter: Stefan Egli >Priority: Major > Fix For: 1.14.0, 1.16.0 > > > With OAK-4940 the ChangeSet now contains all node types up to root that are > related to a change. This fact could be used by the nodeType-aggregate-filter > (OAK-5021), which would likely speed up this type of filter. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-3141) Oak should warn when too many ordered child nodes
[ https://issues.apache.org/jira/browse/OAK-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-3141: -- Fix Version/s: 1.16.0 > Oak should warn when too many ordered child nodes > - > > Key: OAK-3141 > URL: https://issues.apache.org/jira/browse/OAK-3141 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Affects Versions: 1.0.16 >Reporter: Jörg Hoh >Assignee: Thomas Mueller >Priority: Major > Fix For: 1.14.0, 1.16.0 > > > When working with the RDBMK we came into situations, that large documents did > not fit into the provided db columns, there was an overflow, which caused oak > not to persist the change. We fixed it by increasing the size of the column. > But it would be nice if Oak could warn if a document exceeds a certain size > (for example 2 megabytes); because this warning indicates, that on a JCR > level there might be a problematic situation, for example: > * ordered node with a large list of childnodes > * or longstanding sessions with lots of changes, which accumulate to large > documents. > It's certainly nice to know if there's a node/document with such a problem, > before the exceptions actually happens and an operation breaks. > This message should be a warning, and should contain the JCR path of the node > plus the current size. To avoid that this message is overseen, it would be > good if it is written everyonce in a while (every 10 minutes?) if this > condition persists. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7212) Document the document order traversal option
[ https://issues.apache.org/jira/browse/OAK-7212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7212: -- Fix Version/s: 1.16.0 > Document the document order traversal option > > > Key: OAK-7212 > URL: https://issues.apache.org/jira/browse/OAK-7212 > Project: Jackrabbit Oak > Issue Type: Documentation > Components: doc, run >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Major > Fix For: 1.14.0, 1.16.0 > > > Document the doc-order-traversal option introduced with OAK-6353 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7372) Update FileDataStore recommendation
[ https://issues.apache.org/jira/browse/OAK-7372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7372: -- Fix Version/s: 1.16.0 > Update FileDataStore recommendation > --- > > Key: OAK-7372 > URL: https://issues.apache.org/jira/browse/OAK-7372 > Project: Jackrabbit Oak > Issue Type: Documentation > Components: doc >Reporter: Marcel Reutegger >Priority: Minor > Fix For: 1.14.0, 1.16.0 > > > The BlobStore documentation currently mentions use of a FileDataStore only > for deployments when the data store is shared between multiple repository > instances. The documentation should be updated to also recommend the > FileDataStore when a repository has many binaries. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-5367) Strange path parsing
[
https://issues.apache.org/jira/browse/OAK-5367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-5367:
--
Fix Version/s: 1.16.0
> Strange path parsing
>
>
> Key: OAK-5367
> URL: https://issues.apache.org/jira/browse/OAK-5367
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.14.0, 1.16.0
>
> Attachments: JcrPathParserTest.java
>
>
> Incorrect handling of path with "\{" was fixed in OAK-5260, but the behavior
> of the JcrPathParser is still strange. For example:
> * the root node, "/", is mapped to "/", and the current node, "." is mapped
> to "". But "/." is mapped to the current node (should be root node).
> * "/parent/./childA2" is mapped to "/parent/childA2" (which is fine), but
> "/parent/.}/childA2" is also mapped to "/parent/childA2".
> * "\}\{" and "}\[" and "}}[" are mapped to the current node. So are ".[" and
> "/[" and ".}". And "}\{test" is mapped to "}\{test", which is
> inconsistent-weird.
> * "x\[1\]}" is mapped to "x".
> All that weirdness should be resolved. Some seem to be just weird, but some
> look like they could become a problem at some point ("}\{").
--
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.16.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, 1.16.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-7390) QueryResult.getSize() can be slow for many "or" or "union" conditions
[ https://issues.apache.org/jira/browse/OAK-7390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7390: -- Fix Version/s: 1.16.0 > QueryResult.getSize() can be slow for many "or" or "union" conditions > - > > Key: OAK-7390 > URL: https://issues.apache.org/jira/browse/OAK-7390 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Major > Fix For: 1.14.0, 1.16.0 > > > For queries with many union conditions, the "fast" getSize method can > actually be slower than iterating over the result. > The reason is, the number of index calls grows exponential with regards to > number of subqueries: (3x + x^2) / 2, where x is the number of subqueries. > For this to have a measurable affect, the number of subqueries needs to be > large (more than 100), and the index needs to be slow. -- 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: 1.16.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, 1.16.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-6508) Make it possible to exclude subtrees by configuration in Solr index
[ https://issues.apache.org/jira/browse/OAK-6508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6508: -- Fix Version/s: 1.16.0 > Make it possible to exclude subtrees by configuration in Solr index > --- > > Key: OAK-6508 > URL: https://issues.apache.org/jira/browse/OAK-6508 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: solr >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili >Priority: Major > Fix For: 1.14.0, 1.16.0 > > > While it's possible to configure per subtree Solr indexes (via persisted > configuration), sometimes it's also useful to define index on a larger tree > but still exclude some subtrees (e.g. /jcr:system, /var, etc.) for > performance reasons (unneeded content in the index, performance). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-3236) integration test that simulates influence of clock drift
[ https://issues.apache.org/jira/browse/OAK-3236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-3236: -- Fix Version/s: 1.16.0 > integration test that simulates influence of clock drift > > > Key: OAK-3236 > URL: https://issues.apache.org/jira/browse/OAK-3236 > Project: Jackrabbit Oak > Issue Type: Test > Components: core >Affects Versions: 1.3.4 >Reporter: Stefan Egli >Priority: Major > Fix For: 1.14.0, 1.16.0 > > > Spin-off of OAK-2739 [of this > comment|https://issues.apache.org/jira/browse/OAK-2739?focusedCommentId=14693398&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14693398] > - ie there should be an integration test that show cases the issues with > clock drift and why it is a good idea to have a lease-check (that refuses to > let the document store be used any further once the lease times out locally) -- This message was sent by Atlassian JIRA (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: 1.16.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, 1.16.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-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: 1.16.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, 1.16.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-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: 1.16.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, 1.16.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-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: 1.16.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, 1.16.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-6760) Convert oak-blob-cloud to OSGi R6 annotations
[ https://issues.apache.org/jira/browse/OAK-6760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6760: -- Fix Version/s: 1.16.0 > Convert oak-blob-cloud to OSGi R6 annotations > - > > Key: OAK-6760 > URL: https://issues.apache.org/jira/browse/OAK-6760 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: blob-cloud >Reporter: Robert Munteanu >Priority: Major > Fix For: 1.14.0, 1.16.0 > > -- 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: 1.16.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, 1.16.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-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: 1.16.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, 1.16.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-7634) Repository migration docs should include info on TAR <-> Azure sidegrade
[ https://issues.apache.org/jira/browse/OAK-7634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7634: -- Fix Version/s: 1.16.0 > Repository migration docs should include info on TAR <-> Azure sidegrade > > > Key: OAK-7634 > URL: https://issues.apache.org/jira/browse/OAK-7634 > Project: Jackrabbit Oak > Issue Type: Documentation > Components: doc, segment-tar >Reporter: Andrei Dulceanu >Assignee: Andrei Dulceanu >Priority: Minor > Fix For: 1.14.0, 1.16.0 > > -- 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: 1.16.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, 1.16.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-4934) Query shapes for JCR Query
[
https://issues.apache.org/jira/browse/OAK-4934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-4934:
--
Fix Version/s: 1.16.0
> Query shapes for JCR Query
> --
>
> Key: OAK-4934
> URL: https://issues.apache.org/jira/browse/OAK-4934
> Project: Jackrabbit Oak
> Issue Type: Wish
> Components: query
>Reporter: Chetan Mehrotra
>Priority: Major
> Fix For: 1.14.0, 1.16.0
>
>
> For certain requirements it would be good to have a notion/support to deduce
> query shape [1]
> {quote}
> A combination of query predicate, sort, and projection specifications.
> For the query predicate, only the structure of the predicate, including the
> field names, are significant; the values in the query predicate are
> insignificant. As such, a query predicate \{ type: 'food' \} is equivalent to
> the query predicate \{ type: 'utensil' \} for a query shape.
> {quote}
> So transforming that to Oak the shape should represent a JCR-SQL2 query
> string (xpath query gets transformed to SQL2) which is a *canonical*
> representation of actual query ignoring the property restriction values.
> Example we have 2 queries
> * SELECT * FROM [app:Asset] AS a WHERE a.[jcr:content/metadata/status] =
> 'published'
> * SELECT * FROM [app:Asset] AS a WHERE a.[jcr:content/metadata/status] =
> 'disabled'
> The query shape would be
> SELECT * FROM [app:Asset] AS a WHERE a.[jcr:content/metadata/status] = 'A'.
> The plan for query having given shape would remain same irrespective of value
> of property restrictions. Path restriction can cause some difference though
> The shape can then be used for
> * Stats Collection - Currently stats collection gets overflown if same query
> with different value gets invoked
> * Allow configuring hints - See support in Mongo [2] for an example. One
> specify via config that for a query of such and such shape this index should
> be used
> * Less noisy diagnostics - If a query gets invoked with bad plan the QE can
> log the warning once instead of logging it for each query invocation
> involving different values.
> [1] https://docs.mongodb.com/manual/reference/glossary/#term-query-shape
> [2] https://docs.mongodb.com/manual/reference/command/planCacheSetFilter/
--
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: 1.16.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, 1.16.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-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: 1.16.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, 1.16.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-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: 1.16.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, 1.16.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OAK-8273) RDBDocumentStore: createOrUpdate with less than 3 ops suboptimal
[
https://issues.apache.org/jira/browse/OAK-8273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-8273.
-
bulk close 1.8.13
> RDBDocumentStore: createOrUpdate with less than 3 ops suboptimal
>
>
> Key: OAK-8273
> URL: https://issues.apache.org/jira/browse/OAK-8273
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: rdbmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
> Labels: candidate_oak_1_6
> Fix For: 1.8.13, 1.10.3, 1.14.0
>
> Attachments: OAK-8273.diff
>
>
> {{createOrUpdate()}} with 1 or 2 operations works, but is handled by the
> fallback code that is supposed to handle failures during bulk updates.
> Thus:
> - misleading DEBUG logging ("update conflict on...")
> - unnecessary cache invalidation
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (OAK-8291) Update Oak 1.8 to Jackrabbit 2.16.4
[ https://issues.apache.org/jira/browse/OAK-8291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-8291. - bulk close 1.8.13 > Update Oak 1.8 to Jackrabbit 2.16.4 > --- > > Key: OAK-8291 > URL: https://issues.apache.org/jira/browse/OAK-8291 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Blocker > Fix For: 1.8.13 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OAK-8301) Ensure travis-ci uses trusty image
[ https://issues.apache.org/jira/browse/OAK-8301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-8301. - bulk close 1.8.13 > Ensure travis-ci uses trusty image > -- > > Key: OAK-8301 > URL: https://issues.apache.org/jira/browse/OAK-8301 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.8.13, 1.10.3, 1.14.0 > > > It seems travis-ci may choose to run a build with an image different than the > default trusty image. A recent feature branch build failed > (https://travis-ci.org/mreutegg/jackrabbit-oak/builds/528830705) because > travis-ci picked a xenial image and was unable to use Oracle JDK 8. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OAK-8214) RDBDocumentStore may not inherit ReadOnly flag from DocumentNodeStore
[
https://issues.apache.org/jira/browse/OAK-8214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-8214.
-
bulk close 1.8.13
> RDBDocumentStore may not inherit ReadOnly flag from DocumentNodeStore
> -
>
> Key: OAK-8214
> URL: https://issues.apache.org/jira/browse/OAK-8214
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk, rdbmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_oak_1_6
> Fix For: 1.8.13, 1.10.3, 1.14.0
>
> Attachments: OAK-8214.diff
>
>
> ...because RDBDocumentStore gets initialized early when the Datasource is set
> using {{RDBDocumentStoreBuilder.setRDBConnection}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (OAK-8296) DocumentNodeStoreBranchesTest uses javax.annotation.Nonnull
[ https://issues.apache.org/jira/browse/OAK-8296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-8296. - bulk close 1.8.13 > DocumentNodeStoreBranchesTest uses javax.annotation.Nonnull > --- > > Key: OAK-8296 > URL: https://issues.apache.org/jira/browse/OAK-8296 > Project: Jackrabbit Oak > Issue Type: Task > Components: documentmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Fix For: 1.8.13, 1.10.3, 1.14.0 > > > ...indirectly made available through osgi-mock dependency. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OAK-8258) Active deletion can delete blobs despite indexing cycle deleting them failed
[ https://issues.apache.org/jira/browse/OAK-8258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-8258. - bulk close 1.8.13 > Active deletion can delete blobs despite indexing cycle deleting them failed > > > Key: OAK-8258 > URL: https://issues.apache.org/jira/browse/OAK-8258 > Project: Jackrabbit Oak > Issue Type: Bug > Components: lucene >Affects Versions: 1.12.0, 1.8.12, 1.10.2 >Reporter: Vikas Saurabh >Assignee: Vikas Saurabh >Priority: Major > Fix For: 1.8.13, 1.10.3, 1.14.0 > > > Essentially OAK-6270 always reports successful commit even in case of failures -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OAK-8146) oak-run support for inspecting clusterNodeInfo
[ https://issues.apache.org/jira/browse/OAK-8146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-8146. - bulk close 1.8.13 > oak-run support for inspecting clusterNodeInfo > -- > > Key: OAK-8146 > URL: https://issues.apache.org/jira/browse/OAK-8146 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: documentmk, run >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Labels: candidate_oak_1_6 > Fix For: 1.8.13, 1.10.3, 1.14.0 > > Attachments: OAK-8146-1.patch, OAK-8146-2.diff, OAK-8146-3.diff, > OAK-8146.diff, OAK-8146.diff > > > - readable dump of cluster node info entries > - command to purge selected entries (later) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OAK-7902) Update osgi-mock to 2.3.10
[ https://issues.apache.org/jira/browse/OAK-7902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-7902. - bulk close 1.8.13 > Update osgi-mock to 2.3.10 > -- > > Key: OAK-7902 > URL: https://issues.apache.org/jira/browse/OAK-7902 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Affects Versions: 1.9.11 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.8.13, 1.10.3, 1.14.0 > > > The current version (2.3.6) has an indirect dependency on the findbugs > annotations that we already got rid of. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OAK-8139) DocumentDiscoveryLiteService hasBacklog silencing must support maven version format
[
https://issues.apache.org/jira/browse/OAK-8139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-8139.
-
bulk close 1.8.13
> DocumentDiscoveryLiteService hasBacklog silencing must support maven version
> format
> ---
>
> Key: OAK-8139
> URL: https://issues.apache.org/jira/browse/OAK-8139
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk
>Reporter: Stefan Egli
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_oak_1_6
> Fix For: 1.8.13, 1.10.3, 1.14.0
>
> Attachments: OAK-8139.diff, OAK-8139.patch2.diff, OAK-8139.patch3.diff
>
>
> OAK-3492 silences log warns when it encounters an 1.0 or 1.2 oak version (in
> the case where there is an inactive cluster node that doesn't have
> lastWrittenRootRev set).
> The silencing uses osgi Version to do the version comparison, however the
> actual version is stored in maven format. This breaks for eg the case where
> version is set to something like 1.0.10-SNAPSHOT where it expects
> 1.0.10.SNAPSHOT and the following exception would occur:
> {{org.apache.jackrabbit.oak.plugins.document.DocumentDiscoveryLiteService
> hasBacklog: couldn't parse version 1.0.10-SNAPSHOT :
> java.lang.IllegalArgumentException: invalid version "1.0.10-SNAPSHOT":
> non-numeric "10-SNAPSHOT"}}
> The silencing should be fixed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (OAK-8220) CommitRootUpdateTest creates malformed value
[ https://issues.apache.org/jira/browse/OAK-8220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-8220. - bulk close 1.8.13 > CommitRootUpdateTest creates malformed value > > > Key: OAK-8220 > URL: https://issues.apache.org/jira/browse/OAK-8220 > Project: Jackrabbit Oak > Issue Type: Bug > Components: documentmk >Affects Versions: 1.8.0, 1.10.0, 1.12.0 >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Trivial > Fix For: 1.8.13, 1.10.3, 1.14.0 > > > CommitRootUpdateTest.exceptionOnSingleUpdate() creates a malformed serialized > value. The test fails when executed with the CacheLIRS implementation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OAK-8201) RDBDocumentStore in ReadOnly mode should never modify persistence
[ https://issues.apache.org/jira/browse/OAK-8201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-8201. - bulk close 1.8.13 > RDBDocumentStore in ReadOnly mode should never modify persistence > - > > Key: OAK-8201 > URL: https://issues.apache.org/jira/browse/OAK-8201 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_6 > Fix For: 1.8.13, 1.10.3, 1.14.0 > > Attachments: OAK-8201.diff > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OAK-8140) UserPrincipalProvider support for full text search
[
https://issues.apache.org/jira/browse/OAK-8140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-8140.
-
bulk close 1.12.0
> UserPrincipalProvider support for full text search
> --
>
> Key: OAK-8140
> URL: https://issues.apache.org/jira/browse/OAK-8140
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Major
> Labels: principal-management-extensions
> Fix For: 1.12.0
>
>
> The {{UserPrincipalProvider}} related changes for OAK-8131.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (OAK-8021) PrivilegeBitsProvider.getBits(Privilege[],NameMapper) should use getOakNameOrNull
[
https://issues.apache.org/jira/browse/OAK-8021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-8021.
-
bulk close 1.12.0
> PrivilegeBitsProvider.getBits(Privilege[],NameMapper) should use
> getOakNameOrNull
> --
>
> Key: OAK-8021
> URL: https://issues.apache.org/jira/browse/OAK-8021
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: security-spi
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Fix For: 1.12.0
>
>
> just noticed that the implementation of
> {{PrivilegeBitsProvider.getBits(Privilege[], NameMapper)}} could call
> {{NameMapper.getOakNameOrNull}} instead of {{getOakName}}, which throws a
> {{RepositoryException}} in case of an invalid name.
> [~stillalex], fyi
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (OAK-8119) Let similarity search rerank use distance as exact score
[ https://issues.apache.org/jira/browse/OAK-8119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-8119. - bulk close 1.12.0 > Let similarity search rerank use distance as exact score > > > Key: OAK-8119 > URL: https://issues.apache.org/jira/browse/OAK-8119 > Project: Jackrabbit Oak > Issue Type: Task > Components: lucene >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili >Priority: Major > Fix For: 1.12.0, 1.10.2 > > > Currently the reranking algorithm for feature vector similarity search uses > an additive scoring mechanism so that the final score is the sum of the > original LSH query and the query - document feature vector distance. It turns > out that since LSH is supposed to approximate the fv distance it'd be more > effective to just use the exact distance as the final score instead of > performing the mentioned sum. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OAK-8118) Index selected properties to enhance feature vector similarity search results
[ https://issues.apache.org/jira/browse/OAK-8118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-8118. - bulk close 1.12.0 > Index selected properties to enhance feature vector similarity search results > - > > Key: OAK-8118 > URL: https://issues.apache.org/jira/browse/OAK-8118 > Project: Jackrabbit Oak > Issue Type: Task > Components: lucene >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili >Priority: Major > Fix For: 1.12.0, 1.10.2 > > > To improve the accuracy of results of the feature vector similarity search we > could include tokens from some configured properties to be treated as > keywords or tags. > Such tags would be used in the query to reduce the number of false positives > and improve the precision of search results. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OAK-8013) [Direct Binary Access] DataRecordDownloadOptions creates invalid Content-Disposition headers - Workaround
[ https://issues.apache.org/jira/browse/OAK-8013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-8013. - bulk close 1.12.0 > [Direct Binary Access] DataRecordDownloadOptions creates invalid > Content-Disposition headers - Workaround > - > > Key: OAK-8013 > URL: https://issues.apache.org/jira/browse/OAK-8013 > Project: Jackrabbit Oak > Issue Type: Bug > Components: blob-plugins >Reporter: Alexander Klimetschek >Assignee: Matt Ryan >Priority: Major > Fix For: 1.12.0, 1.10.2 > > > DataRecordDownloadOptions always adds the extended parameter filename* to the > header, [without any > escaping|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-blob-plugins/src/main/java/org/apache/jackrabbit/oak/plugins/blob/datastore/directaccess/DataRecordDownloadOptions.java#L130]. > Such extended parameters must not include spaces (and only a small predefined > list of basic ascii chars), otherwise they have to be percent encoded. The > RFC is https://tools.ietf.org/html/rfc5987 and note the definition of > value-chars in the grammar. > Because of this, if a filename includes a space or another character that > must be percent encoded, this currently creates an invalid header that fails > to be parsed by other clients. > See also https://github.com/jshttp/content-disposition/issues/24 > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OAK-8020) Create ImmutableACL from another AbstractAccessControlList
[
https://issues.apache.org/jira/browse/OAK-8020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-8020.
-
bulk close 1.12.0
> Create ImmutableACL from another AbstractAccessControlList
> --
>
> Key: OAK-8020
> URL: https://issues.apache.org/jira/browse/OAK-8020
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: security-spi
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Fix For: 1.12.0
>
>
> in order to make an existing {{AbstractAccessControlList}} immutable it would
> be handy to have a separate constructor like e.g. the following:
> {code}
> public ImmutableACL(@NotNull AbstractAccessControlList accessControlList) {
> this(accessControlList.getOakPath(), accessControlList.getEntries(),
> accessControlList.getRestrictionProvider(),
> accessControlList.getNamePathMapper());
> }
> {code}
> [~stillalex], fyi
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (OAK-8022) Update Oak trunk to Jackrabbit 2.19.0
[ https://issues.apache.org/jira/browse/OAK-8022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-8022. - bulk close 1.12.0 > Update Oak trunk to Jackrabbit 2.19.0 > - > > Key: OAK-8022 > URL: https://issues.apache.org/jira/browse/OAK-8022 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.12.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OAK-8168) Improve readability of AccessControlAction
[
https://issues.apache.org/jira/browse/OAK-8168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-8168.
-
bulk close 1.12.0
> Improve readability of AccessControlAction
> --
>
> Key: OAK-8168
> URL: https://issues.apache.org/jira/browse/OAK-8168
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: security-spi
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Fix For: 1.12.0
>
> Attachments: OAK-8168.patch
>
>
> [~stillalex], while working on a poc i came across the
> {{AccessControlAction}} again and found it a bit hard to read. I would
> appreciate if you could review the attached refactoring. Feedback welcome.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
