[jira] [Comment Edited] (OAK-2476) Move our CI to Jenkins
[ https://issues.apache.org/jira/browse/OAK-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14305431#comment-14305431 ] Tommaso Teofili edited comment on OAK-2476 at 2/4/15 4:23 PM: -- We have now 3 different jobs: - [Oak trunk java 6|https://builds.apache.org/job/Oak%20trunk%20java%206/] - [Oak trunk java 7|https://builds.apache.org/job/Oak%20trunk%20java%207/] - [Oak trunk java 8|https://builds.apache.org/job/Oak%20trunk%20java%208/] they can execute on ubuntu or Windows, so we should have at least a good starting coverage. was (Author: teofili): I've created 3 different jobs: - [Oak trunk java 6|https://builds.apache.org/job/Oak%20trunk%20java%206/] - [Oak trunk java 7|https://builds.apache.org/job/Oak%20trunk%20java%207/] - [Oak trunk java 8|https://builds.apache.org/job/Oak%20trunk%20java%208/] they can execute on ubuntu or Windows, so we should have at least a good starting coverage. > Move our CI to Jenkins > -- > > Key: OAK-2476 > URL: https://issues.apache.org/jira/browse/OAK-2476 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > > We should strive for stabilization of our CI setup, as of now we had Buildbot > and Travis. > It seems ASF Jenkins can perform jobs on different environments (*nix, > Windows and others) so we can evaluate that and check if it better address > our needs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2476) Move our CI to Jenkins
[ https://issues.apache.org/jira/browse/OAK-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14305431#comment-14305431 ] Tommaso Teofili commented on OAK-2476: -- I've created 3 different jobs: - [Oak trunk java 6|https://builds.apache.org/job/Oak%20trunk%20java%206/] - [Oak trunk java 7|https://builds.apache.org/job/Oak%20trunk%20java%207/] - [Oak trunk java 8|https://builds.apache.org/job/Oak%20trunk%20java%208/] they can execute on ubuntu or Windows, so we should have at least a good starting coverage. > Move our CI to Jenkins > -- > > Key: OAK-2476 > URL: https://issues.apache.org/jira/browse/OAK-2476 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > > We should strive for stabilization of our CI setup, as of now we had Buildbot > and Travis. > It seems ASF Jenkins can perform jobs on different environments (*nix, > Windows and others) so we can evaluate that and check if it better address > our needs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2476) Move our CI to Jenkins
[ https://issues.apache.org/jira/browse/OAK-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14305413#comment-14305413 ] Robert Munteanu commented on OAK-2476: -- Looking at build #2 I see that it ran (and failed ) on solaris. I suggest that you restrict the build to the 'ubuntu' slaves, at least until you get it stable. > Move our CI to Jenkins > -- > > Key: OAK-2476 > URL: https://issues.apache.org/jira/browse/OAK-2476 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > > We should strive for stabilization of our CI setup, as of now we had Buildbot > and Travis. > It seems ASF Jenkins can perform jobs on different environments (*nix, > Windows and others) so we can evaluate that and check if it better address > our needs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2476) Move our CI to Jenkins
[ https://issues.apache.org/jira/browse/OAK-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14305388#comment-14305388 ] Tommaso Teofili commented on OAK-2476: -- bq. Tommaso Teofili the first build it's failing on solr yes I've seen it thanks, inspections underway :-) bq. plus can we do the same on a windows box? I think the best would be to set up a matrix as suggested by [~mduerig], with different java versions and slaves > Move our CI to Jenkins > -- > > Key: OAK-2476 > URL: https://issues.apache.org/jira/browse/OAK-2476 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > > We should strive for stabilization of our CI setup, as of now we had Buildbot > and Travis. > It seems ASF Jenkins can perform jobs on different environments (*nix, > Windows and others) so we can evaluate that and check if it better address > our needs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2476) Move our CI to Jenkins
[ https://issues.apache.org/jira/browse/OAK-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14305370#comment-14305370 ] Michael Dürig commented on OAK-2476: Ah and then we need another dimension for the OSs. I.e. run each fixture on Windows and *nix. > Move our CI to Jenkins > -- > > Key: OAK-2476 > URL: https://issues.apache.org/jira/browse/OAK-2476 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > > We should strive for stabilization of our CI setup, as of now we had Buildbot > and Travis. > It seems ASF Jenkins can perform jobs on different environments (*nix, > Windows and others) so we can evaluate that and check if it better address > our needs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2476) Move our CI to Jenkins
[ https://issues.apache.org/jira/browse/OAK-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14305352#comment-14305352 ] Michael Dürig commented on OAK-2476: According to the [Jenkins Wiki | http://wiki.apache.org/general/Jenkins] the PMC chair can grant committers access. So that would be me > Move our CI to Jenkins > -- > > Key: OAK-2476 > URL: https://issues.apache.org/jira/browse/OAK-2476 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > > We should strive for stabilization of our CI setup, as of now we had Buildbot > and Travis. > It seems ASF Jenkins can perform jobs on different environments (*nix, > Windows and others) so we can evaluate that and check if it better address > our needs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2476) Move our CI to Jenkins
[ https://issues.apache.org/jira/browse/OAK-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14305354#comment-14305354 ] Davide Giannella commented on OAK-2476: --- more than happy to help. [~teofili] the first build it's failing on solr. Seems it's not able to start-up/embed solr itself. plus can we do the same on a windows box? > Move our CI to Jenkins > -- > > Key: OAK-2476 > URL: https://issues.apache.org/jira/browse/OAK-2476 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > > We should strive for stabilization of our CI setup, as of now we had Buildbot > and Travis. > It seems ASF Jenkins can perform jobs on different environments (*nix, > Windows and others) so we can evaluate that and check if it better address > our needs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2476) Move our CI to Jenkins
[ https://issues.apache.org/jira/browse/OAK-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14305349#comment-14305349 ] Michael Dürig commented on OAK-2476: [~teofili] could you set it up as a matrix build for the various fixtures? [~edivad] would be able to help you with the individual command lines. > Move our CI to Jenkins > -- > > Key: OAK-2476 > URL: https://issues.apache.org/jira/browse/OAK-2476 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > > We should strive for stabilization of our CI setup, as of now we had Buildbot > and Travis. > It seems ASF Jenkins can perform jobs on different environments (*nix, > Windows and others) so we can evaluate that and check if it better address > our needs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2476) Move our CI to Jenkins
[ https://issues.apache.org/jira/browse/OAK-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14305343#comment-14305343 ] Tommaso Teofili commented on OAK-2476: -- I think I already have access because I was responsible for setting a Jenkins Job (for Apache UIMA, if I remember correctly) some years ago. > Move our CI to Jenkins > -- > > Key: OAK-2476 > URL: https://issues.apache.org/jira/browse/OAK-2476 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > > We should strive for stabilization of our CI setup, as of now we had Buildbot > and Travis. > It seems ASF Jenkins can perform jobs on different environments (*nix, > Windows and others) so we can evaluate that and check if it better address > our needs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2476) Move our CI to Jenkins
[ https://issues.apache.org/jira/browse/OAK-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14305340#comment-14305340 ] Michael Dürig commented on OAK-2476: See http://wiki.apache.org/general/Jenkins for information on the Apache Jenkins instance. According to this I am the person to grant you access. Ping me if you need access. > Move our CI to Jenkins > -- > > Key: OAK-2476 > URL: https://issues.apache.org/jira/browse/OAK-2476 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > > We should strive for stabilization of our CI setup, as of now we had Buildbot > and Travis. > It seems ASF Jenkins can perform jobs on different environments (*nix, > Windows and others) so we can evaluate that and check if it better address > our needs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2476) Move our CI to Jenkins
[ https://issues.apache.org/jira/browse/OAK-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14305287#comment-14305287 ] Tommaso Teofili commented on OAK-2476: -- created first Jenkins Job on [oak trunk|https://builds.apache.org/job/Oak%20trunk] executing _mvn clean install -PintegrationTesting -Ppedantic_ command, neither triggers nor notifications configured yet. > Move our CI to Jenkins > -- > > Key: OAK-2476 > URL: https://issues.apache.org/jira/browse/OAK-2476 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > > We should strive for stabilization of our CI setup, as of now we had Buildbot > and Travis. > It seems ASF Jenkins can perform jobs on different environments (*nix, > Windows and others) so we can evaluate that and check if it better address > our needs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-1356) Expose the preferred transient space size as repository descriptor
[
https://issues.apache.org/jira/browse/OAK-1356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14305284#comment-14305284
]
Marcel Reutegger commented on OAK-1356:
---
Large transaction work better now, but the problems mentioned by Thomas are
still the same. We still have multiple passes over the change set, which will
result in a lot of repeated uncached calls. Even if it is technically possible
to have large transactions, I wouldn't recommend them for performance reasons.
> Expose the preferred transient space size as repository descriptor
> ---
>
> Key: OAK-1356
> URL: https://issues.apache.org/jira/browse/OAK-1356
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, jcr
>Reporter: Tobias Bocanegra
>Assignee: Chetan Mehrotra
> Labels: api
> Fix For: 1.2
>
>
> The problem is that the different stores have different transient space
> characteristics. for example the MongoMK is very slow when handling large
> saves.
> suggest to expose a repository descriptor that can be used to estimate the
> preferred transient space, for example when importing content.
> so either a boolean like:
> {{option.infinite.transientspace}}
> or a number like:
> {{option.transientspace.preferred.size}}
> the later would denote the average number of modified node states that should
> be put in the transient space before the persistence starts to degrade.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-2476) Move our CI to Jenkins
Tommaso Teofili created OAK-2476: Summary: Move our CI to Jenkins Key: OAK-2476 URL: https://issues.apache.org/jira/browse/OAK-2476 Project: Jackrabbit Oak Issue Type: Task Reporter: Tommaso Teofili Assignee: Tommaso Teofili We should strive for stabilization of our CI setup, as of now we had Buildbot and Travis. It seems ASF Jenkins can perform jobs on different environments (*nix, Windows and others) so we can evaluate that and check if it better address our needs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-2475) Query Filter looses property constraints for multiple and conditions for same property
Chetan Mehrotra created OAK-2475:
Summary: Query Filter looses property constraints for multiple and
conditions for same property
Key: OAK-2475
URL: https://issues.apache.org/jira/browse/OAK-2475
Project: Jackrabbit Oak
Issue Type: Bug
Components: query
Reporter: Chetan Mehrotra
Priority: Minor
Fix For: 1.0.12, 1.1.7
Current while evaluating a query like following where {{propa}} is a multi
value property
{code}
select [jcr:path] from [nt:base] where propa = 'a' and propa = 'c'
{code}
Filter created by Query Engine only has one property restriction for _propa =
'a'_. This happens because FilterImpl uses a map to store the
propertyRestrictions.
Eventually query engine returns the right result as query engine evaluates both
restrictions on the result set returned by index. However index does not get to
know of other restrictions and would return more result than required.
Expected - Filter gets access to all property restrictions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-2474) Release Oak 1.1.6
Davide Giannella created OAK-2474: - Summary: Release Oak 1.1.6 Key: OAK-2474 URL: https://issues.apache.org/jira/browse/OAK-2474 Project: Jackrabbit Oak Issue Type: Task Reporter: Davide Giannella Assignee: Davide Giannella Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2460) Resolve the base directory path of persistent cache against repository home
[
https://issues.apache.org/jira/browse/OAK-2460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-2460:
--
Fix Version/s: (was: 1.1.6)
1.1.7
> Resolve the base directory path of persistent cache against repository home
> ---
>
> Key: OAK-2460
> URL: https://issues.apache.org/jira/browse/OAK-2460
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: mongomk
>Reporter: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.1.7
>
>
> Currently PersistentCache uses the directory path directly. Various other
> parts in Oak which need access to the filesystem currently make use of
> {{repository.home}} framework property in OSGi env [1]
> Same should also be used in PersistentCache
> [1] http://jackrabbit.apache.org/oak/docs/osgi_config.html#SegmentNodeStore
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-1962) Fix and Improve Locking
[ https://issues.apache.org/jira/browse/OAK-1962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-1962: -- Fix Version/s: (was: 1.1.6) 1.1.7 > Fix and Improve Locking > --- > > Key: OAK-1962 > URL: https://issues.apache.org/jira/browse/OAK-1962 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, jcr >Affects Versions: 1.0 >Reporter: angela > Fix For: 1.1.7 > > > as discussed during our biweekly planning session, we are having the > following locking related use case in our product: > a page (which is an aggregation of nodes and properties) must be freezed > (prevented from being edited/modified/deleted) during the period of a > dedicated review (which in our case is triggered by a workflow) before the > page then is either published or reopened for further changes. > for this feature locking would be a perfect match but with the current > implementation in oak it's not possible to remove the lock token from a > given session and make sure it's no longer recognizes as lock owner; in > particular with the simple-locking feature which we introduced in order to > cope with the situation that in our product sessions are living just for the > time of a single request. > is was therefore thinking about ways to address this, keeping the > simple-locking requirement in mind while at the same time improving > compliance with the JCR specification. my suggestion as follows: > - use a dedicated hidden and write protected location the repository to store > the lock information independent of the protected properties defined by > mix:lockable which are just for information purpose (that would be the > replacement for the lock-related file we had in jackrabbit 2.x) > - format: simple lookup consisting of userId + associated lock tokens > - in case of simple locking LockManager#getLockTokens would make use of that > map even if the lock tokens have NOT been explicitly added to the Session > either upon LockManager#lock or LockManager#addLockToken > - in the default (non-simple case) LockManager#getLockTokens would work as > specified and the lookup would only be used for maintaining and enforcing the > lock related information) > - LockManager#removeLockToken removes the token from the lookup thus > effectively revoking the lock ownership from the given Session and thus > preventing it from performing further editing... even in the simple-locking > case > - LockManager#addLockToken results in a modification of the lookup table as > well depending on the API contract (i.e. verifying if the lock token would be > shared... i don't remember exactly if that's accepted by the specification) > - LockManager#isLockOwner no longer needs to perform a cheap hack comparing > the jcr:lockOwner property with the sessions userId but could really enforce > ownership based on the internal lock information stored in the repository in > which case getLockTokens would really reflect the ownership for open-scoped > locks; furthermore the 'jcr:lockOwner' information could be to what is > specified by the API consumer upon LockManager#lock as it is no longer used > for enforcing the locks. > in addition: > - we could generated proper lock tokens instead of just using the node id > and again keep those in a hidden (or otherwise protected) location in the > system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2037) Define standards for plan output
[ https://issues.apache.org/jira/browse/OAK-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-2037: -- Fix Version/s: (was: 1.1.6) 1.1.7 > Define standards for plan output > > > Key: OAK-2037 > URL: https://issues.apache.org/jira/browse/OAK-2037 > Project: Jackrabbit Oak > Issue Type: Task > Components: query >Reporter: Justin Edelson > Fix For: 1.1.7 > > > Currently, the syntax for the plan output is chaotic as it varies > significantly from index to index. Whereas some of this is expected - each > index type will have different data to output, Oak should provide some > standards about how a plan will appear. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2444) Enable the persistent cache by default
[ https://issues.apache.org/jira/browse/OAK-2444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-2444: -- Fix Version/s: (was: 1.1.6) 1.1.7 > Enable the persistent cache by default > -- > > Key: OAK-2444 > URL: https://issues.apache.org/jira/browse/OAK-2444 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.2, 1.1.7 > > > The persistent cache (for MongoDB and RDBMS storage) should be enabled and > tested by default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2384) SegmentNotFoundException when keeping JCR Value references
[
https://issues.apache.org/jira/browse/OAK-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-2384:
--
Fix Version/s: (was: 1.1.6)
1.1.7
> SegmentNotFoundException when keeping JCR Value references
> --
>
> Key: OAK-2384
> URL: https://issues.apache.org/jira/browse/OAK-2384
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Critical
> Labels: gc
> Fix For: 1.0.12, 1.1.7
>
> Attachments: org.apache.sling.jcr.resource-2.4.0.jar
>
>
> With OAK-2192 revision gc started to remove segments older than a certain
> threshold. The underlying assumption was that old sessions would call refresh
> (i.e. auto refresh) anyway once they become active again. However, it turns
> out that refreshing a sessions does not affect JCR values as those are
> directly tied to the underlying record. Accessing those values after its
> segment has been gc'ed results in a {{SegmentNotFoundException}}.
> Keeping reference to JCR values is an important use case for Sling's
> {{JcrPropertyMap}}, which is widely used.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2262) Add metadata about the changed value to a PROPERTY_CHANGED event on a multivalued property
[ https://issues.apache.org/jira/browse/OAK-2262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-2262: -- Fix Version/s: (was: 1.1.6) 1.1.7 > Add metadata about the changed value to a PROPERTY_CHANGED event on a > multivalued property > -- > > Key: OAK-2262 > URL: https://issues.apache.org/jira/browse/OAK-2262 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, jcr >Affects Versions: 1.1.2 >Reporter: Tommaso Teofili >Assignee: Michael Dürig > Labels: observation > Fix For: 1.1.7 > > > When getting _PROPERTY_CHANGED_ events on non-multivalued properties only one > value can have actually changed so that handlers of such events do not need > any further information to process it and eventually work on the changed > value; on the other hand _PROPERTY_CHANGED_ events on multivalued properties > (e.g. String[]) may relate to any of the values and that brings a source of > uncertainty on event handlers processing such changes because there's no mean > to understand which property value had been changed and therefore to them to > react accordingly. > A workaround for that is to create Oak specific _Observers_ which can deal > with the diff between before and after state and create a specific event > containing the "diff", however this would add a non trivial load to the > repository because of the _Observer_ itself and because of the additional > events being generated while it'd be great if the 'default' events would have > metadata e.g. of the changed value index or similar information that can help > understanding which value has been changed (added, deleted, updated). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2295) Using "order by jcr:score" slows down queries by a few orders of magnitude
[ https://issues.apache.org/jira/browse/OAK-2295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-2295: -- Fix Version/s: (was: 1.1.6) 1.1.7 > Using "order by jcr:score" slows down queries by a few orders of magnitude > -- > > Key: OAK-2295 > URL: https://issues.apache.org/jira/browse/OAK-2295 > Project: Jackrabbit Oak > Issue Type: Bug > Components: oak-lucene >Affects Versions: 1.0.8 > Environment: Linux 2.6.32-431.23.3.el6.x86_64 VM, > 16GB RAM > 4 Core Intel(R) Xeon(R) CPU E5-4640 0 @ 2.40GHz >Reporter: Punyanjan Sen >Assignee: Thomas Mueller >Priority: Critical > Fix For: 1.0.12, 1.1.7 > > Attachments: OAK-2295.patch > > > The following query takes over 16 seconds to run on our QA system: > /jcr:root/content/help/en//*[jcr:contains(., 'illustrator')] order by > jcr:score > Removing the "order by jcr:score" reduces the query time to 14ms > The time taken increases linearly with the amount of content in our > repository. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2310) [Property Index] Adding new propertyName to an existing index doesn't update index to reflect the same
[
https://issues.apache.org/jira/browse/OAK-2310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-2310:
--
Fix Version/s: (was: 1.1.6)
1.1.7
> [Property Index] Adding new propertyName to an existing index doesn't update
> index to reflect the same
> --
>
> Key: OAK-2310
> URL: https://issues.apache.org/jira/browse/OAK-2310
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Affects Versions: 1.0.7
>Reporter: Vikas Saurabh
>Assignee: Thomas Mueller
>Priority: Critical
> Fix For: 1.1.7
>
>
> It seems intuitive to add multiple property names to a given property index.
> But, currently, adding a new {{propertyName}} to an existing index doesn't
> update indexed content to reflect the newly added property name.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2349) DiffCache based on persistent cache
[ https://issues.apache.org/jira/browse/OAK-2349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-2349: -- Fix Version/s: (was: 1.1.6) 1.1.7 > DiffCache based on persistent cache > --- > > Key: OAK-2349 > URL: https://issues.apache.org/jira/browse/OAK-2349 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, mongomk >Reporter: Marcel Reutegger >Assignee: Thomas Mueller > Fix For: 1.2, 1.1.7 > > > There is currently an in-memory and MongoDB based DiffCache implementation. > It would be good to replace them with an implementation based on the > persistent cache introduced with OAK-2191. This reduces traffic to MongoDB > and can also be used in combination with the RDB backend. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-2454) Upgrade: reduce implementation dependency
[ https://issues.apache.org/jira/browse/OAK-2454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-2454. - Resolution: Fixed sure... in fact i already committed the change and the issue should be marked resolved... in case we spot any issues with that, i will revert it. > Upgrade: reduce implementation dependency > - > > Key: OAK-2454 > URL: https://issues.apache.org/jira/browse/OAK-2454 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: upgrade >Reporter: angela > Fix For: 1.1.6 > > Attachments: OAK-2454-2.patch, OAK-2454.patch > > > the current upgrade code heavily relies on implementation details. i would > prefer to use existing functionality like privilege-mgt and node type > management instead of copying that code to the upgrade. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2176) Support for using query engine for search suggestions
[ https://issues.apache.org/jira/browse/OAK-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14305028#comment-14305028 ] Tommaso Teofili commented on OAK-2176: -- implemented _rep:suggest_ in the query engine and Lucene and Solr indexes. Async update of suggestion indexes and ACL checks still to be done. > Support for using query engine for search suggestions > - > > Key: OAK-2176 > URL: https://issues.apache.org/jira/browse/OAK-2176 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: oak-lucene, oak-solr, query >Affects Versions: 1.1.0 >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > Fix For: 1.1.7 > > > Related to OAK-2175 search engines are often used for term suggestions (e.g. > for autocompletion, search as you type, etc.) which I think would be good to > support also in Oak, especially having both Lucene > (https://lucene.apache.org/core/4_10_0/suggest/org/apache/lucene/search/suggest/Lookup.html) > and Solr (https://wiki.apache.org/solr/Suggester > https://wiki.apache.org/solr/TermsComponent) already implementing this > functionality. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2176) Support for using query engine for search suggestions
[ https://issues.apache.org/jira/browse/OAK-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated OAK-2176: - Fix Version/s: (was: 1.1.6) 1.1.7 > Support for using query engine for search suggestions > - > > Key: OAK-2176 > URL: https://issues.apache.org/jira/browse/OAK-2176 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: oak-lucene, oak-solr, query >Affects Versions: 1.1.0 >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > Fix For: 1.1.7 > > > Related to OAK-2175 search engines are often used for term suggestions (e.g. > for autocompletion, search as you type, etc.) which I think would be good to > support also in Oak, especially having both Lucene > (https://lucene.apache.org/core/4_10_0/suggest/org/apache/lucene/search/suggest/Lookup.html) > and Solr (https://wiki.apache.org/solr/Suggester > https://wiki.apache.org/solr/TermsComponent) already implementing this > functionality. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-2457) Suggestor support within Oak Lucene
[ https://issues.apache.org/jira/browse/OAK-2457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili resolved OAK-2457. -- Resolution: Fixed Fix Version/s: (was: 1.2) 1.1.6 Assignee: Tommaso Teofili fixed in r1657163. Documentation node: added configuration options for properties to be used for suggestions (e.g. useInSuggest : true) and similarly for spellcheck (e.g. useInSpellcheck : true). > Suggestor support within Oak Lucene > --- > > Key: OAK-2457 > URL: https://issues.apache.org/jira/browse/OAK-2457 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: oak-lucene >Reporter: Chetan Mehrotra >Assignee: Tommaso Teofili > Fix For: 1.1.6 > > Attachments: OAK-2457.0.patch > > > Suggestor support within Oak Lucene -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-2473) ACL checks on suggestions
Tommaso Teofili created OAK-2473: Summary: ACL checks on suggestions Key: OAK-2473 URL: https://issues.apache.org/jira/browse/OAK-2473 Project: Jackrabbit Oak Issue Type: Sub-task Components: query Reporter: Tommaso Teofili Fix For: 1.1.7 Support for ACL check suggestions needs to be added to avoid providing suggestions coming from index data whose source nodes / properties were not meant to be readable from the calling user. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-2467) Suggestor support within Oak Solr
[ https://issues.apache.org/jira/browse/OAK-2467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili resolved OAK-2467. -- Resolution: Fixed fixed in r1657132 > Suggestor support within Oak Solr > - > > Key: OAK-2467 > URL: https://issues.apache.org/jira/browse/OAK-2467 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: oak-solr >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > Fix For: 1.1.6 > > Attachments: OAK-2467.0.patch > > > Suggestor support for Oak Solr -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-2455) Support for invoking suggestor via Query
[
https://issues.apache.org/jira/browse/OAK-2455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili resolved OAK-2455.
--
Resolution: Fixed
Assignee: Tommaso Teofili
fixed in r1657128
> Support for invoking suggestor via Query
>
>
> Key: OAK-2455
> URL: https://issues.apache.org/jira/browse/OAK-2455
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: query
>Reporter: Chetan Mehrotra
>Assignee: Tommaso Teofili
> Fix For: 1.1.6
>
> Attachments: OAK-2455.0.patch, OAK-2455.1.patch
>
>
> Similar to planned support for spell check OAK-2175 we need to provide
> support for suggestor via the Query engine. It should be possible to various
> parameters as supported by Lucene suggestor impl [1]
> {code}
> SELECT rep:suggest() FROM nt:base WHERE jcr:path = '/' AND SUGGEST('fox is')
> {code}
> Such an approach should allow
> # Selecting the right suggestor index via path
> # Ability to pass parameter like number of suggestions required, context etc
> ## search phrase
> ## Set of contexts - contexts to filter the lookup by
> ## onlyMorePopular - return only more popular results
> ## num - maximum number of results to return
> [1]
> https://github.com/apache/lucene-solr/blob/trunk/lucene/suggest/src/java/org/apache/lucene/search/suggest/Lookup.java#L252
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2182) Specify collection to be used by Solr index
[ https://issues.apache.org/jira/browse/OAK-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated OAK-2182: - Fix Version/s: (was: 1.1.6) 1.1.7 > Specify collection to be used by Solr index > --- > > Key: OAK-2182 > URL: https://issues.apache.org/jira/browse/OAK-2182 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: oak-solr >Affects Versions: 1.1.0 >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > Fix For: 1.1.7 > > > Currently all the information to hit a Solr server is hold by the singleton > SolrServerProvider while there are some use cases where more than one query > index definition for a Solr index may be done, targeting different content, > and therefore it'd be good to be able to specify which collection should be > used by each of these indexes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-2220) Support for atomic counters (non-clustered)
[ https://issues.apache.org/jira/browse/OAK-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14301403#comment-14301403 ] Davide Giannella edited comment on OAK-2220 at 2/4/15 10:42 AM: committed in trunk the support for non-clustered solutions. * http://svn.apache.org/r1656506 * http://svn.apache.org/r1657112 was (Author: edivad): committed in trunk @ http://svn.apache.org/r1656506 the support for non-clustered solutions. > Support for atomic counters (non-clustered) > --- > > Key: OAK-2220 > URL: https://issues.apache.org/jira/browse/OAK-2220 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: core >Reporter: Michael Dürig >Assignee: Davide Giannella > Fix For: 1.1.6 > > Attachments: oak-atomic-counter.md > > > For several use cases (think +1/-1 votes on forum posts) it would be good to > have some basic support for atomic counters in Oak. Such counters must: > # correctly reflect increments/decrements by integral parts across threads / > cluster nodes, > # exhibit some well defined consistency characteristics amongst each other, > # not require cluster wide coordination. > 1. is required so in the forum post example the correct number of votes is > recorded for each post. > 2. is important so in the forum post example sorting by votes results in the > correct order. > 3. is important as global cluster synchronisation run contrary to out overall > scalability goals. > Additionally such counters should allow the user to trade off the consistency > characteristics from 2 for availability. I.e. scarifying some availability > results in hight consistency. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-2469) Restrict the maximum number of terms that will be indexed for a single field
[
https://issues.apache.org/jira/browse/OAK-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved OAK-2469.
--
Resolution: Fixed
Fix Version/s: (was: 1.2)
1.1.6
Required changes done in trunk
> Restrict the maximum number of terms that will be indexed for a single field
>
>
> Key: OAK-2469
> URL: https://issues.apache.org/jira/browse/OAK-2469
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: oak-lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.1.6
>
> Attachments: OAK-2469.patch
>
>
> JR2 used support a {{maxFieldLength}} [1] to limit the numbers of terms
> indexed per field with default value of 1. Similar support should be
> provided in Oak Lucene
> [1]
> https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/query/lucene/SearchIndex.java#L299
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-1990) Utility js methods to manage Oak data in Mongo
[
https://issues.apache.org/jira/browse/OAK-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved OAK-1990.
--
Resolution: Fixed
Fix Version/s: 1.1.6
Resolving this issue now as oak-mongo.js has some real useful methods now.
Later changes to that can be done under dedicated issues
> Utility js methods to manage Oak data in Mongo
> --
>
> Key: OAK-1990
> URL: https://issues.apache.org/jira/browse/OAK-1990
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: mongomk
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.1.6
>
> Attachments: oak-mongo.js
>
>
> To simplify making sense of data created by Oak in Mongo it would be helpful
> to have a collection of utility js methods. This method can then be used
> within Mongo shell
> As a start I have put up some methods in [1]. These can be used as shown below
> {noformat}
> $ wget
> https://gist.githubusercontent.com/chetanmeh/836ca8fffc4c410daed2/raw/oak-mongo.js
> $ mongo localhost/oak --shell oak-mongo.js
> MongoDB shell version: 2.6.3
> connecting to: localhost/oak
> type "help" for help
> > oak.countChildren('/oak:index/')
> 356787
> > oak.getChildStats('/oak:index')
> { "count" : 356788, "size" : 127743372, "simple" : "121.83 MB" }
> > oak.getChildStats('/')
> { "count" : 593191, "size" : 302005011, "simple" : "288.01 MB" }
> >
> {noformat}
> [1] https://gist.github.com/chetanmeh/836ca8fffc4c410daed2
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-1356) Expose the preferred transient space size as repository descriptor
[
https://issues.apache.org/jira/browse/OAK-1356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14304860#comment-14304860
]
Chetan Mehrotra commented on OAK-1356:
--
[~mreutegg] Given the recent work of yours around supporting large transactions
what should we do about this issue. Is this change required?
> Expose the preferred transient space size as repository descriptor
> ---
>
> Key: OAK-1356
> URL: https://issues.apache.org/jira/browse/OAK-1356
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, jcr
>Reporter: Tobias Bocanegra
>Assignee: Chetan Mehrotra
> Labels: api
> Fix For: 1.2
>
>
> The problem is that the different stores have different transient space
> characteristics. for example the MongoMK is very slow when handling large
> saves.
> suggest to expose a repository descriptor that can be used to estimate the
> preferred transient space, for example when importing content.
> so either a boolean like:
> {{option.infinite.transientspace}}
> or a number like:
> {{option.transientspace.preferred.size}}
> the later would denote the average number of modified node states that should
> be put in the transient space before the persistence starts to degrade.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2083) Add metatype info for Document and Segment services
[
https://issues.apache.org/jira/browse/OAK-2083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-2083:
-
Fix Version/s: (was: 1.2)
1.1.7
> Add metatype info for Document and Segment services
> ---
>
> Key: OAK-2083
> URL: https://issues.apache.org/jira/browse/OAK-2083
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.1.7
>
>
> Currently the OSGi service {{SegmentNodeStoreService}} and
> {{DocumentNodeStoreService}} do not provide metatype information for the
> possible configuration options and those config options then need to be
> documented as part of Oak Docs. To simiplify that we should add required
> metatype information to the two services
> One implication of that would be that user would be editing it directly from
> within Felix Web Console and that might cause some stablity as the repository
> would be restarted due to such a change however the benifit of having all
> details about config options at one place is much higher.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-2296) Update sql2.txt test to account for name property presence in non test nodes
[
https://issues.apache.org/jira/browse/OAK-2296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved OAK-2296.
--
Resolution: Fixed
> Update sql2.txt test to account for name property presence in non test nodes
>
>
> Key: OAK-2296
> URL: https://issues.apache.org/jira/browse/OAK-2296
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.1.6
>
> Attachments: OAK-2296.patch
>
>
> Test executed from sql2.txt [1] fail for some cases if property names used in
> test data are also used in non test data. For example when running with
> oak-lucene where the index definition also uses {{name}} property then test
> case fails as Lucene search also includes index related nodes.
> As a fix testcase should be modified to include testdata path restriction
> {noformat}
> select [jcr:path]
> from [nt:base]
> where [name] is not null union all select [jcr:path]
> from [nt:base]
> where [name] is not null
> /oak:index/test-index/indexRules/nt:base/properties/allProps
> /oak:index/test-index/indexRules/nt:base/properties/allProps
> /oak:index/test-index/indexRules/nt:base/properties/prop1
> /oak:index/test-index/indexRules/nt:base/properties/prop1
> /test/a
> /test/a
> /test/b
> /test/b
> {noformat}
> [1]
> https://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/test/resources/org/apache/jackrabbit/oak/query/sql2.txt
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2296) Update sql2.txt test to account for name property presence in non test nodes
[
https://issues.apache.org/jira/browse/OAK-2296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-2296:
-
Fix Version/s: (was: 1.2)
1.1.6
> Update sql2.txt test to account for name property presence in non test nodes
>
>
> Key: OAK-2296
> URL: https://issues.apache.org/jira/browse/OAK-2296
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.1.6
>
> Attachments: OAK-2296.patch
>
>
> Test executed from sql2.txt [1] fail for some cases if property names used in
> test data are also used in non test data. For example when running with
> oak-lucene where the index definition also uses {{name}} property then test
> case fails as Lucene search also includes index related nodes.
> As a fix testcase should be modified to include testdata path restriction
> {noformat}
> select [jcr:path]
> from [nt:base]
> where [name] is not null union all select [jcr:path]
> from [nt:base]
> where [name] is not null
> /oak:index/test-index/indexRules/nt:base/properties/allProps
> /oak:index/test-index/indexRules/nt:base/properties/allProps
> /oak:index/test-index/indexRules/nt:base/properties/prop1
> /oak:index/test-index/indexRules/nt:base/properties/prop1
> /test/a
> /test/a
> /test/b
> /test/b
> {noformat}
> [1]
> https://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/test/resources/org/apache/jackrabbit/oak/query/sql2.txt
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2374) Sporadic test failure of OSGiIT.listBundles on Buildbot
[ https://issues.apache.org/jira/browse/OAK-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated OAK-2374: - Fix Version/s: 1.1.7 > Sporadic test failure of OSGiIT.listBundles on Buildbot > --- > > Key: OAK-2374 > URL: https://issues.apache.org/jira/browse/OAK-2374 > Project: Jackrabbit Oak > Issue Type: Bug > Components: it >Reporter: Michael Dürig >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: 1.1.7 > > Attachments: OAK-2374.patch > > > See http://markmail.org/message/idx2y2dwpkaxchsp for previous mention. > I suggest to use the mechanism from OAK-2371 to exclude the tests on that CI > environment for now. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-2415) Improve logging in repository migration in upgrade
[ https://issues.apache.org/jira/browse/OAK-2415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved OAK-2415. -- Resolution: Fixed > Improve logging in repository migration in upgrade > -- > > Key: OAK-2415 > URL: https://issues.apache.org/jira/browse/OAK-2415 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: upgrade >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: 1.1.6, 1.0.12 > > > At time repository migration take long time (upward of 40 hrs). To get better > insight into what is happening it would be good to provide additional logging > like which commit hook is being executed and what time it took -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2432) Allow querying on jcr:primaryType property if that property is indexed
[
https://issues.apache.org/jira/browse/OAK-2432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-2432:
-
Fix Version/s: (was: 1.1.6)
1.1.7
> Allow querying on jcr:primaryType property if that property is indexed
> --
>
> Key: OAK-2432
> URL: https://issues.apache.org/jira/browse/OAK-2432
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: oak-lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.1.7
>
>
> Currently {{LucenePropertyIndex}} does not evaluate {{PropertyRestrictions}}
> based on {{jcr:primaryType}}. This logic can be relaxed to evaluate this
> property if user has enabled {{propertyIndex}} for {{jcr:primaryType}}
> If no such config is enabled then anyway logic would not create Lucene query
> for that
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2399) Custom scorer for modifying score per documents
[ https://issues.apache.org/jira/browse/OAK-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated OAK-2399: - Fix Version/s: (was: 1.1.6) 1.1.7 > Custom scorer for modifying score per documents > --- > > Key: OAK-2399 > URL: https://issues.apache.org/jira/browse/OAK-2399 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: oak-lucene >Reporter: Rishabh Maurya >Assignee: Chetan Mehrotra > Fix For: 1.1.7 > > Attachments: OAK-2399_scorer.patch > > > We have search enhancements requests based on search results relevance like - > 1. boosting score of recently modified documents. > 2. boosting documents which are created/last updated by current session > user.(OR boosting on basis specific field value). > 3. boosting documents with a field value in certain range. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2187) Document cache invalidation logic generating lots of garbage
[
https://issues.apache.org/jira/browse/OAK-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-2187:
-
Fix Version/s: (was: 1.1.6)
1.1.7
> Document cache invalidation logic generating lots of garbage
>
>
> Key: OAK-2187
> URL: https://issues.apache.org/jira/browse/OAK-2187
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: core
>Affects Versions: 1.0.7
> Environment: CQ6SP1+HF5176(Oak 1.0.7), 3 authors, 2 mongo in replica
> set with another arbiter.
>Reporter: Vikas Saurabh
>Assignee: Chetan Mehrotra
> Fix For: 1.1.7
>
>
> We are observing around 2GB of temporary objects getting created every 20-30
> seconds
> Following is the result from
> {{/system/console/jmx/org.apache.jackrabbit.oak%3Aid%3D8%2Cname%3D"Consolidated+Cache+statistics"%2Ctype%3D"ConsolidatedCacheStats"}}:
> ||averageLoadPenalty||elementCount||evictionCount||hitCount||hitRate||loadCount||loadExceptionCount||loadSuccessCount||maxWeight||missCount||missRate||name||requestCount||totalLoadTime||totalWeight||
> |2ms|136054|14855|8293718384|0.96|222767|0|222767|612.0
> MB|372951359|0.043|Document-Documents|869743|8 min, 0 sec|611.2 MB|
> |0ms|95600|262264|146336|0.19|0|0|0|53.7
> MB|609878|0.81|Document-Diff|756214|0 min, 0 sec|53.7 MB|
> |0ms|1|0|31212|0.17|0|0|0|32.2 MB|156684|0.83|Document-DocChildren|187896|0
> min, 0 sec|4.8 kB|
> |3ms|78781|110556|25953581|0.98|181461|0|181461|107.4
> MB|508826|0.019|Document-NodeChildren|26462407|11 min, 29 sec|107.2 MB|
> |0ms|201619|2542876|440737116|0.99|2744495|0|2744495|268.4
> MB|2866721|0.0065|Document-NodeState|443603837|8 min, 36 sec|268.4 MB|
> Following is the thread-dump:
> {code}
> 2014-10-14 12:57:20
> Full thread dump OpenJDK 64-Bit Server VM (24.65-b04 mixed mode):
> "Thread-8668" - Thread t@18303
>java.lang.Thread.State: TIMED_WAITING
> at java.lang.Object.wait(Native Method)
> - waiting on <400eb4d3> (a java.lang.Object)
> at EDU.oswego.cs.dl.util.concurrent.LinkedQueue.poll(Unknown Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.getTask(Unknown
> Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown
> Source)
> at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
> - None
> "Thread-8667" - Thread t@18302
>java.lang.Thread.State: TIMED_WAITING
> at java.lang.Object.wait(Native Method)
> - waiting on <400eb4d3> (a java.lang.Object)
> at EDU.oswego.cs.dl.util.concurrent.LinkedQueue.poll(Unknown Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.getTask(Unknown
> Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown
> Source)
> at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
> - None
> "Thread-8666" - Thread t@18301
>java.lang.Thread.State: TIMED_WAITING
> at java.lang.Object.wait(Native Method)
> - waiting on <400eb4d3> (a java.lang.Object)
> at EDU.oswego.cs.dl.util.concurrent.LinkedQueue.poll(Unknown Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.getTask(Unknown
> Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown
> Source)
> at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
> - None
> "Thread-8665" - Thread t@18300
>java.lang.Thread.State: TIMED_WAITING
> at java.lang.Object.wait(Native Method)
> - waiting on <400eb4d3> (a java.lang.Object)
> at EDU.oswego.cs.dl.util.concurrent.LinkedQueue.poll(Unknown Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.getTask(Unknown
> Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown
> Source)
> at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
> - None
> "Thread-8664" - Thread t@18299
>java.lang.Thread.State: TIMED_WAITING
> at java.lang.Object.wait(Native Method)
> - waiting on <400eb4d3> (a java.lang.Object)
> at EDU.oswego.cs.dl.util.concurrent.LinkedQueue.poll(Unknown Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.getTask(Unknown
> Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown
> Source)
> at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
> - None
> "Thread-8663" - Thread t@18298
>java.lang.Thread.State: TIMED_WAITING
> at java.lang.Object.wait(Native Method)
> - waiting on <400eb4d3> (a java.lang.Object)
> at EDU.oswego.cs.dl.util.concurrent.LinkedQueue.poll(Unknown Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.getTask(Unknown
> Source
[jira] [Resolved] (OAK-2464) Optimize read of known non-existing children
[
https://issues.apache.org/jira/browse/OAK-2464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved OAK-2464.
--
Resolution: Fixed
Resolving for trunk for now. Would merge it later to branch
> Optimize read of known non-existing children
>
>
> Key: OAK-2464
> URL: https://issues.apache.org/jira/browse/OAK-2464
> Project: Jackrabbit Oak
> Issue Type: Improvement
>Reporter: Vikas Saurabh
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.1.6
>
> Attachments:
> 0001-OAK-2464-Optimize-read-of-known-non-existing-childre.patch,
> OAK-2464-Sort order test case.patch, OAK-2464-Take2.patch
>
>
> Reading a non-existing node always queries down to {{DocumentStore}}.
> {{DocumentNodeStore}} should consider {{nodeChildrenCache}} to see if it
> already knows about non-existence and avoid a look up into {{DocumentStore}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2263) Avoid unnecessary reads on index lookup
[ https://issues.apache.org/jira/browse/OAK-2263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-2263: -- Fix Version/s: (was: 1.1.6) 1.1.7 > Avoid unnecessary reads on index lookup > --- > > Key: OAK-2263 > URL: https://issues.apache.org/jira/browse/OAK-2263 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.1.7 > > > The PropertyIndex looks up the matching index definitions multiple times. > This means each time all definitions are read to find out which one matches > the given property restriction. AFAICS this happens at least six times. The > first two times when the cost is calculated: 1) check if the property is > indexed and 2) calculate the cost. The next four times when the query is > executed: 3) check if the property is indexed, 4) calculate the cost, 5) > check if the property is indexed, 6) lookup index to create cursor for query. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2455) Support for invoking suggestor via Query
[
https://issues.apache.org/jira/browse/OAK-2455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili updated OAK-2455:
-
Attachment: OAK-2455.1.patch
second patch, added xpath support
> Support for invoking suggestor via Query
>
>
> Key: OAK-2455
> URL: https://issues.apache.org/jira/browse/OAK-2455
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: query
>Reporter: Chetan Mehrotra
> Fix For: 1.1.6
>
> Attachments: OAK-2455.0.patch, OAK-2455.1.patch
>
>
> Similar to planned support for spell check OAK-2175 we need to provide
> support for suggestor via the Query engine. It should be possible to various
> parameters as supported by Lucene suggestor impl [1]
> {code}
> SELECT rep:suggest() FROM nt:base WHERE jcr:path = '/' AND SUGGEST('fox is')
> {code}
> Such an approach should allow
> # Selecting the right suggestor index via path
> # Ability to pass parameter like number of suggestions required, context etc
> ## search phrase
> ## Set of contexts - contexts to filter the lookup by
> ## onlyMorePopular - return only more popular results
> ## num - maximum number of results to return
> [1]
> https://github.com/apache/lucene-solr/blob/trunk/lucene/suggest/src/java/org/apache/lucene/search/suggest/Lookup.java#L252
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
