Re: Lucene Index property Definitions

> I am searching using SQL-2 to create queries, those examples don't look familiar to me. //element(*, app:Asset)[jcr:contains(., ‘image’)] in sql2 would look like select [jcr:path] from [app:Asset] where contains(*, 'image') //element(*, app:Asset)[jcr:contains(jcr:content/metadata/@format,

Re: Lucene Index property Definitions

On Thu, 28 Nov, 2019, 23:54 jorgeeflorez ., wrote: > from the reference < https://jackrabbit.apache.org/oak/docs/query/lucene.html#property-definitions >, it is not clear to me the difference between the fields analyzed, nodeScopeIndex, both says that should be set when using *contains* in

Re: Plugging an Observer with access to NodeStore

Hi Paul, On Tue, 29 Oct, 2019, 18:38 Paul Wilson, wrote: > I believe the best way to have my Observer access the NodeStore is > via @Reference injection from the OSGi container. I have no plans to use > OSGi however Admittedly, I'm not the best person to answer this... But I wonder

Re: Lucene index: getting empty result while query

On Mon, Oct 7, 2019 at 12:26 PM Sandeep Ambule wrote: > > I am trying to query with Lucene index but getting the empty result and > below errors in the log, > Traversal query (query without index): select [jcr:path] from [nt:base] > where isdescendantnode('/test') and name='World'; consider

Re: Intent to backport OAK-8449

+1 --Vikas (sent from mobile) On Thu, 5 Sep, 2019, 15:21 Marcel Reutegger, wrote: > Hi, > > I'd like to backport OAK-8449 to some maintenance branches to make > this functionality available to users of older Oak versions. I consider the > risk as low because the added functionality is in the

Re: Lucene Index Extraction

Sounds like a bug to me. Can you please open an issue? --Vikas (sent from mobile) On Thu, 5 Sep, 2019, 01:23 jorgeeflorez ., wrote: > Hello, > > I am trying to extract a Lucene index from a Repository stored in MongoDB. > I tried to use oak-run (1.12.0) as depicted in >

Re: About text extraction for index

> but I am having a problem: the thread that processes the pdf file keeps running, creating images and performing OCR. Is this supposed to happen? TL;DR: yes, because there is no safe way to kill a thread Yes that's supposed to happen. The reason this feature implemented was because in most

Re: About text extraction for index

Hi, > Is it possible to change the maximum time for that text extraction You should be able to configure timeout by setting -Doak.extraction.timeoutSeconds=120 [0] on ivm command line. Alternatively, you could also disable running in different thread by setting

Re: [VOTE] Release Apache Jackrabbit Oak 1.14.0

On Wed, Jun 5, 2019 at 9:25 PM Davide Giannella wrote: > ... [X] +1 Release this package as Apache Jackrabbit Oak 1.14.0 with [INFO] [INFO] Apache Maven 3.6.0 [INFO] OS name: "linux", version: "4.15.0-43-generic", arch:

Re: Query options in queries with OR

That sounds like a bug to me. Would love to hear Thomas Mueller's thoughts too though. --Vikas (sent from mobile) On Fri 22 Mar, 2019, 17:26 Piotr Tajduś, wrote: > Hi, > > Not sure if this is a bug, but when query with OR is divided into union > of queries, options (like index tag) are not

Missing fixed oak issue in 1.6.16 release notes

Hi, During the release vote for recently released 1.6.16 version we found OAK-7975 [0]. After some discussion, we restarted 1.6.16 release to include the fix for OAK-7975 [0]. But I had forgotten to update fix version on oak issue to capture 1.6.16 and hence the issue missed being part 1.6.16

Re: [VOTE] Release Apache Jackrabbit Oak 1.6.16

> On 09/01/2019 10:25, Vikas Saurabh wrote: > > I am tentatively voting -1 to bring up the discussion but I'm a fence > > sitter atm. > > > > [0]: https://issues.apache.org/jira/browse/OAK-7975 > > Thanks for bringing this one up Vikas. I'm tentatively going to cou

Re: [VOTE] Release Apache Jackrabbit Oak 1.6.16

[X] -1 Do not release this package because... 1.6.16 currently has a bunch of fixes/improvements wrt facets. We recently discovered and fixed another facet related bug (OAK-7975 [0]). It might be better to tag along this fix in 1.6.16 too. To give a bit of detail on the bug - the issue occurs

Re: [VOTE] Release Apache Jackrabbit Oak 1.9.13

> [X] +1 Release this package as Apache Jackrabbit Oak 1.9.13 with [INFO] [INFO] Apache Maven 3.5.2 [INFO] OS name: "linux", version: "4.13.0-46-generic", arch: "amd64", family: "unix" [INFO] Java version: 1.8.0_181,

Re: How to find out if similarity search is active - without doing a search

Hi Bertrand, > Would it be possible for Oak to provide this capability information in > a different way that does not require a JCR Session? I suppose the > functionality is available if a specific version of the oak-lucene > bundle is installed, so the following options come to mind: >

quick heads up (probably)

Hi, While running some tests today I hit surefire error to load its class [2], which after some digging led me to [1]. I was using jdk8u181. Using jdk8u192 fixed that for me. Hopefully, it can avoid some time for others. Thanks, Vikas [1]:

Re: [VOTE] Release Apache Jackrabbit Oak 1.9.7

Hi, > [X ] +1 Release this package as Apache Jackrabbit Oak 1.9.7 > [INFO] [INFO] ALL CHECKS OK [INFO] with; [INFO]

Re: Decide if a composite node store setup expose multiple checkpoint mbeans

Hi, sorry for getting back to this a bit late There was an off-list discussion among some core oak commiters which concluded that: * checkpoint bean should only be exposed by global node store (opened OAK-7699 [0] for this) * we should formalize responsibilities of a node store

Re: [VOTE] Release Apache Jackrabbit Oak 1.8.6

On Tue, Jul 31, 2018 at 9:17 PM, Manfred Baedke wrote: > [X] +1 Release this package as Apache Jackrabbit Oak 1.8.6 > with [INFO] [INFO] Apache Maven 3.5.0 [INFO] OS name: "linux", version: "4.13.0-45-generic", arch:

Re: Jackrabbit Oak 1.8.6 Release Plan

Hi Manfred, There's at least OAK-7630 which is about leaking open file handles due to suggestions indexes that's fixed in 1.8.6. I would want that we get a release having that fix out. --Vikas (sent from mobile) On Fri 27 Jul, 2018, 01:22 Manfred Baedke, wrote: > Hi all, > > Oak 1.8.6 is

Re: [VOTE] Release Apache Jackrabbit Oak 1.9.6

Hi, On Thu, Jul 19, 2018 at 4:36 PM, Julian Reschke wrote: > On 2018-07-19 12:42, Vikas Saurabh wrote: >> >> ... >> [INFO] Running >> org.apache.jackrabbit.oak.plugins.blob.UploadStagingCacheTest >> [ERROR] Tests run: 22, Failures: 1, Errors: 0, Skipped: 0, Time

Re: [VOTE] Release Apache Jackrabbit Oak 1.9.6

Hi, On Wed, Jul 18, 2018 at 7:15 PM, Davide Giannella wrote: > > > A candidate for the Jackrabbit Oak 1.9.6 release is available at: > > https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.9.6/ > > The release candidate is a zip archive of the sources in: > > >

Re: Decide if a composite node store setup expose multiple checkpoint mbeans

Hi Tomek, On Mon, Jul 9, 2018 at 2:06 PM, Tomek Rękawek wrote: > I think there was a similar case, described in OAK-5309 (multiple instances > of the RevisionGCMBean). We introduced an extra property there - “role” - > which can be used to differentiate the mbeans. It’s similar to the option 2

Decide if a composite node store setup expose multiple checkpoint mbeans

Hi, We recently discovered OAK-7610 [0] where ActiveDeletedBlobCollectorMBeanImpl got confused due to multiple implementations of CheckpointMBean being exposed in composite node store setups (since OAK-6315 [1] which implemented checkpoint bean for composite node store) While, for the time

Re: [VOTE] Release Apache Jackrabbit Oak 1.9.4

On Mon, Jun 18, 2018 at 10:08 PM, Julian Reschke wrote: > On 2018-06-18 17:39, Davide Giannella wrote: >> >> ... >> [INFO] 2. Check for the presence of the staged release candidate >> [INFO] >> [ERROR] NOT FOUND: jackrabbit-oak-1.9.4-src.zip >> [ERROR] >> [ERROR] See

Re: [VOTE] Release Apache Jackrabbit Oak 1.9.3

> [X] +1 Release this package as Apache Jackrabbit Oak 1.9.3 > > Best regards, Julian [INFO] [INFO] Apache Maven 3.5.0 [INFO] OS name: "linux", version: "4.13.0-19-generic", arch: "amd64", family: "unix" [INFO] Java

Re: Intent to backport OAK-6294

+1 --Vikas (sent from mobile) On Thu 31 May, 2018, 18:32 Marcel Reutegger, wrote: > Hi, > > I'd like to backport OAK-6294 to the 1.6 and 1.4 branch. The issue has > been reported a while ago and was also fixed in 1.8. I think it's time to > fix this also in the affected maintenance branches.

Re: oak-search module

+1. I'd add a comment to OAK-3336 for a few things we discussed off-list about things to take care and consider as well. On Wed, Apr 4, 2018 at 1:53 PM, Tommaso Teofili wrote: > Hi all, > > In the context of creating an (abstract) implementation for Oak full text >

Re: Oak related question

Hi, On Fri, Mar 16, 2018 at 9:07 AM, Kalach, Dmitry wrote: > Sometimes it causes a multiple versions of files in Oak, like this > > "jcr:data" : { > "r1622ec2af77-0-1" : >

Re: [VOTE] Release Apache Jackrabbit Oak 1.8.2

> [X] +1 Release this package as Apache Jackrabbit Oak 1.8.2 with [INFO] [INFO] Apache Maven 3.5.0 [INFO] OS name: "linux", version: "4.13.0-19-generic", arch: "amd64", family: "unix" [INFO] Java version: 1.8.0_151,

Re: Intent to backport OAK-7176

+1 On Thu, Jan 18, 2018 at 5:11 PM, Marcel Reutegger wrote: > Hi, > > I'd like to backport OAK-7176 to maintenance branches 1.8, 1.6 and 1.4. The > issue is only minor and is unlikely to occur in practice, but it is clearly a > violation of the RevisionVector

Re: Intent to backport OAK-7131 (xpath to sql2 conversion drops order by clause for some cases)

+1 --Vikas (sent from mobile) On 17-Jan-2018 18:37, "Thomas Mueller" wrote: > I want to backport OAK-7152 to all maintenance branches. The fix is simple > and low risk. > > Regards, > Thomas > > >

Re: Intent to backport to 1.8: OAK-7147

+1 --Vikas (sent from mobile) On 12-Jan-2018 11:03, "Chetan Mehrotra" wrote: > Need to backport OAK-7147 - Oak run LuceneIndexer indexes excluded parent > nodes > > regards > Chetan Mehrotra >

Re: OAK-7109: Facet counting for complex queries - example

Hi Dirk, First of all sorry for the delayed response - I wasn't working due to holidays last week. While, I've commented on the issue itself, but I thought maybe we can still discuss the comparable scoring across UNION-ed clauses in this chain. On Fri, Dec 29, 2017 at 9:31 PM, Dirk Rudolph

Re: [windows] Jenkins test failure - o.a.j.o.index.indexer.document.flatfile.FlatFileStoreTest.basicTest

Hi Robert, > I am not able to qualify whether this is a valid failure or not, > therefore I'm bringing it to the mailing list. > That should be independent of OS... for me, following failed: MAVEN_OPTS='-Xmx512m -Xms512m' mvn test -pl :oak-run -Dtest=FlatFileStoreTest#basicTest Opened OAK-7108

Re: [VOTE] Release Apache Jackrabbit Oak 1.7.14

On Wed, Dec 20, 2017 at 11:16 PM, Davide Giannella wrote: > > [X] +1 Release this package as Apache Jackrabbit Oak 1.7.14 with [INFO] [INFO] Apache Maven 3.5.0 [INFO] OS name: "linux", version:

Fw: [jira] [Created] (INFRA-15629) Git mirror not in sync with jackrabbit-oak svn

FYI On 2017-12-08 18:03, "Vikas Saurabh (JIRA)" <j...@apache.org> wrote: > Vikas Saurabh created INFRA-15629:> > -> > > Summary: Git mirror not in sync with jackrabbit-oak svn> > Key: IN

Re: Intent to backport OAK-4518

Too late +1... Btw, I guess we should also add a WARN for setups which might have explicit config for docChildrenCache in their DocumentNodeStore configuration... --Vikas (sent from mobile) On 22-Nov-2017 21:07, "Marcel Reutegger" wrote: > Hi, > > I'd like to

Intent to backport OAK-6750 and OAK-6792 to 1.6 and 1.4

Hi, Oak's facet implementation had these two issues [0], [1]. I would like to backport those to 1.6 and 1.4 branch. Thanks, Vikas [0]: OAK-6750 - Facet for relative properties not working [1]: OAK-6792 - xpath support for facet queries

Re: [VOTE] Release Apache Jackrabbit Oak 1.7.10

On Mon, Oct 23, 2017 at 10:02 PM, Davide Giannella wrote: > > [X] +1 Release this package as Apache Jackrabbit Oak 1.7.10 Thanks, Vikas

Re: [VOTE] Release Apache Jackrabbit 2.15.7

On Sun, Oct 22, 2017 at 1:58 PM, Julian Reschke wrote: > > [X] +1 Release this package as Apache Jackrabbit 2.15.7 Thanks, Vikas

Re: [VOTE] Release Apache Jackrabbit Oak 1.7.9

[X ] +1 Release this package as Apache Jackrabbit Oak 1.7.9 --Vikas (sent from mobile)

Re: Waiting for an async index to be updated

Hi On Fri, Oct 6, 2017 at 2:33 PM, Alex Deparvu wrote: > Hi Robert, > > You could use the IndexStatsMBean [0] to poll for the indexing status, > waiting until indexing is completed. > Alex, while this would most likely work in simple test scenarios - but there's a bit of lag

Re: [VOTE] Release Apache Jackrabbit Oak 1.7.8

> [X] +1 Release this package as Apache Jackrabbit Oak 1.7.8 Thanks, Vikas

Re: Intent to backport OAK-6685

+1 for backport. I've added a comment to the issue that we should probably also make background update a little more resilient. Thanks, Vikas On Wed, Sep 20, 2017 at 7:10 PM, Marcel Reutegger wrote: > Hi, > > I'd like to backport OAK-6685 to the maintenance

Re: Intent to backport OAK-6656 to 1.6 and 1.4 branch

Ack. Would continue with the backport then :). On Wed, Sep 13, 2017 at 2:22 PM, Chetan Mehrotra <chetan.mehro...@gmail.com> wrote: > Its was +0 ;) > Chetan Mehrotra > > > On Wed, Sep 13, 2017 at 2:15 PM, Vikas Saurabh <vikas.saur...@gmail.com> > wrote: >> Hi

Re: Intent to backport OAK-6656 to 1.6 and 1.4 branch

Hi Chetan, Was your concern a -1 or a +/- 0? Thanks, Vikas

Re: Intent to backport OAK-6656 to 1.6 and 1.4 branch

Hi, On Wed, Sep 13, 2017 at 9:32 AM, Chetan Mehrotra wrote: > Would the backport be of use now? As any upgrade I think would happen > first to initial release from that branch where this fix would not be > present Well, from arguments pov, I think one can always

Re: [VOTE] Release Apache Jackrabbit Oak 1.6.5

> [X] +1 Release this package as Apache Jackrabbit Oak 1.6.5 Thanks, Vikas

Re: Intent to backport OAK-5238 to 1.4 and 1.2 branch

+1 for backport. In fact, given that this gives rise to very unexpected issues, I'd argue that it should even go into 1.0 (afair, IndexCopier is on 1.0. though). But, sure, since this is big and backport to 1.0 might be tricky - maybe we can decouple backport-to-1.2-1.4 and backport-to-1.0.

Re: svn commit: r1798453 - in /jackrabbit/oak/trunk: oak-api/src/main/java/org/apache/jackrabbit/oak/api/jmx/package-info.java oak-store-composite/src/main/java/org/apache/jackrabbit/oak/composite/pac

Opened OAK-6337 to track this. In the meantime, re-added the method with deprecation flag and reverted version bump. Thanks, Vikas

Re: [VOTE] Release Apache Jackrabbit Oak 1.6.2

[X] +1 Release this package as Apache Jackrabbit Oak 1.6.2 Thanks, Vikas

Re: svn commit: r1798453 - in /jackrabbit/oak/trunk: oak-api/src/main/java/org/apache/jackrabbit/oak/api/jmx/package-info.java oak-store-composite/src/main/java/org/apache/jackrabbit/oak/composite/pac

> 1. Deprecate the method instead of removing it > The added method was part of 1.7.1 and is gone by 1.7.2. Deprecating seems overkill to me from that pov. > 2. Or better specify comparisonVersion to 1.6 via [1] > I like this idea ... although, it probably adds complexity while branching new

Re: [VOTE] Release Apache Jackrabbit Oak 1.7.1

I can't quite reproduce this - but, maybe, in the spirit of stability - ignore the test for now and investigate in a new issue? On Wed, Jun 7, 2017 at 4:01 PM, Thomas Mueller wrote: > Ah, same as Alex! > > > On 06.06.17, 18:06, "Alex Parvulescu"

Re: Intent to backport to 1.6: OAK-6267

+1 as it affects version management on those setups. --Vikas (sent from mobile) On 31-May-2017 16:16, "Chetan Mehrotra" wrote: https://issues.apache.org/jira/browse/OAK-6267 This is required to fix a bug for setups where bundling is enabled. It affects

Re: failure building oak-upgrade

Hi Angela, > do others experience the same issue? and if yes, is anybody working on > this? > Yes, this seems to affecting generally (OAK-6273). I guess Tomek would check it out. Thanks, Vikas

Re: Oak indexes

Hi Roy, On Mon, May 8, 2017 at 6:52 PM, Roy Teeuwen wrote: > Invalid directory at the location, check console for more information. Last > Exception: java.lang.IllegalArgumentException: A SPI class of type > org.apache.lucene.codes.Codec with name 'oakCodec' does not exist.

Re: Intent to backport to 1.6: OAK-6116

potentially illegimate +1 to backport from my side (as I was the one who reviewed and already +1-ed backporting on the issue itself) Thanks, Vikas

Re: moving nodes in bulk

Hi Alex, If you can, then definitely use JCR API (Node, Session,etc). Btw, what's missing in your snippet is essentially that you aren't committing the changes. You can use NodeStore.merge to do that. But, that is very low level access - e.g that won't make callbacks to the various editors that

Re: [VOTE] Release Apache Jackrabbit Oak 1.6.1

[X] +1 Release this package as Apache Jackrabbit Oak 1.6.1 Thanks, Vikas

Re: Strong all documents under Root - severe slowness on start-up

> Are you saying that forcing the read of all root children is an > *unintended* effect of "builder.setProperty(JCR_PRIMARYTYPE, NT_REP_ROOT, > Type.NAME);"? > > Is there anything that can be configured or overridden to combat this side > effect? Well, I didn't write a test to actually see this,

Re: Strong all documents under Root - severe slowness on start-up

To me, the culprit seems like first line of `org.apache.jackrabbit.oak.plugins.nodetype.write.InitialContent.initialize`: builder.setProperty(JCR_PRIMARYTYPE, NT_REP_ROOT, Type.NAME); which would the force >org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.squeeze line: > 125 to

Re: Supporting "resumable" operations on a large tree

Hi, A quick side-question related to what Stefan mentioned earlier: > A stable traversal order at a given revision + node seems like a prerequisite to me. Javadoc of NodeState#getChildNodeEntries says: " Multiple iterations are guaranteed to return the child nodes in the same order, but the

Re: Two-instance Oak cluster problems - data visibility latency

Hi Eugene, >>> Is it possible for you to set up session/cookie based load balancer? > > This is probably possible, but before going through the trouble, I want to > confirm that the behavior I described is by design (I hope not). I.e. does > Jackrabbit Oak explicitly provides no guarantee on when

Re: Two-instance Oak cluster problems - data visibility latency

> We currently found a dirty workaround by > running DocumentNodewStore.runBackgroundOperations() on every new Session - > but this does seem like an intended way to work in a cluster. > Yes, that definitely is a bad idea - I don't recall the exact details atm, but I think background operations

Re: [Observation] Should listeners require constant inflow of commits to get all events?

Hi Stefan, Thanks for the response. >>* Another commit Cn+1 comes - this marks Cn as "external" and itself >>gets dropped > > Cn is not marked as external though, but yes, Cn+1 is dropped. > Ah!, I see now how that's working. >>* The listener can consume all events till Cn, but Cn+1 and future

[Observation] Should listeners require constant inflow of commits to get all events?

Hi, While working on a test failure (OAK-5668), I noticed that if incoming commits *stop* once observation queue is full, then the listeners won't get last changes that were added after the queue got full. What happens (at least afaiu): * Obs q fills up as [C1, C2, ..., Cn] * Another commit Cn+1

Re: ChangeProcessor potentially warns only once for queue being full during its lifetime (without CommitRateLimiter)

On Fri, Feb 10, 2017 at 4:55 PM, Stefan Egli wrote: > +1, looks like a bug to me. > Ok. Logged OAK-5626. I've some doubt if it's a good idea to simply always reset. Would discuss it on the issue Thanks, Vikas

ChangeProcessor potentially warns only once for queue being full during its lifetime (without CommitRateLimiter)

Hi, _Disclaimer_ : I get confused with change processor code, so not sure if this is an issue or PEBKAC ChangeProcessor#queueSizeChanged sets blocking flag to true if queue size is hit (or beyond). The warning "Revision queue is full. Further revisions will be compacted." is logged only when it

Re: [VOTE] Release Apache Jackrabbit Oak 1.5.18

[X] +1 Release this package as Apache Jackrabbit Oak 1.5.18 Thanks, Vikas

Re: [DocumentMK][LastRevRecovery] What should happen for indexing of commits that get recovered?

> That would be a bug. As part of the recovery for CN2, its _lastRev entry > will be updated to reflect the /tree/node2 change. Let's say previously it > was r7-0-2 and after the recovery is r9-0-2. The current > checkpoint for the async index update on CN1 does not yet see the updated > _lastRev.

Re: [VOTE] Release Apache Jackrabbit Oak 1.0.36

[X] +1 Release this package as Apache Jackrabbit Oak 1.0.36 Thanks, Vikas

Re: [VOTE] Release Apache Jackrabbit Oak 1.5.16

[X] +1 Release this package as Apache Jackrabbit Oak 1.5.16 Thanks, Vikas

Re: [VOTE] Release Apache Jackrabbit Oak 1.5.15

[X] +1 Release this package as Apache Jackrabbit Oak 1.5.15 ALL CHECKS OK Thanks, Vikas

Re: [VOTE] Release Apache Jackrabbit Oak 1.5.14

[X] +1 Release this package as Apache Jackrabbit Oak 1.5.14

Re: How does having lot of ACL (for different principals) on a single node affect performance

Thanks Angela and Michael. Angela, I've replied to a few part inline below. >>The most trivial idea was to have a >>synthetic-group-per-persona-per-such-node and add/remove members to >>these groups. This approach has obvious side-effects: >>* systems gets flooded with system-generated-groups

How does having lot of ACL (for different principals) on a single node affect performance

Hi, In a project I'm working, we have a some personas which represent the kind of operations member of those personas are allowed to do over a given node. The most trivial idea was to have a synthetic-group-per-persona-per-such-node and add/remove members to these groups. This approach has

Re: Possibility of making nt:resource unreferenceable

> At least in our DocumentStoreImplementations (Mongo and RDB), making the > UUID something indexed by the storage (so either Mongo or the relational > database) should be relatively cheap (after all, the UUID never changes once > assigned, right?). That would eliminate the indexing overhead in

Re: Oak HTTP binding README -> Error 500 OakConstraint0055

Hi Joe, > -> http -j -b localhost:8080/test jcr\\:primaryType=oak:Unstructured foo=abc > bar:=123 While I'm not completely sure of the whole type validation machinery (or auto-generation) etc. But doing this: ``` diff --git

Re: Infinite loop

Hi Thiago, > This issue start to appers after some problemas with disk space and some > force restarts on AEM. Just to confirm: does the drive which contains folder have sufficient space now? Any chance that AEM process can't write to /repository/index/* folders? > The Oak Core version is:

Re: Infinite loop

Hi Thiago, > By property indices did you mean the 'propertyIndex' attribute? No, I had meant value of "type" and "async" property on the index definition - in your case it's "lucene" and "async" respectively. > Caused by: java.io.FileNotFoundException: segments_3lxu > at >

Re: Infinite loop

Hi Thiago, That most often happens with async index updates. Logger name in this case for log message for the loop you're describing would have "AsyncIndexUpdate". You can enabled DEBUG log for "org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate" which should then log an exception the next

Re: backport OAK-4153 to 1.0/1.2/1.4

> are we OK to > backport this to all branches (1.0/1.2/1.4)? +1 for all branches mainly because side-effects arising out of OAK-4153 would be very hard to investigate/reason-about. On the same lines, keeping track of such difference in behavior across branch is hard. > Cheers, > Stefan > -- >

Re: normalising the rdb database schema

Hi Tomek, While at first glance I like the idea of normalizing the schema, but there are potential practical issues with the approach: * It'd incur a very heavy migration impact on upgrade or RDB setups - that, most probably, would translate to us having to support both schemas. I don't feel that

Re: Property index replacement / evolution

Hi Ian, On Mon, Aug 8, 2016 at 3:41 PM, Ian Boston wrote: > > If every successful commit writes the root node, due to every update > updating a sync prop index, this leaves me wondering how the delayed sync > reduces the writes to the root node ? > > I thought the justification

Re: Property index replacement / evolution

Hi Ian, On Sun, Aug 7, 2016 at 10:01 AM, Ian Boston wrote: > Also, IIRC, the root document is not persisted on every commit, but > synchronized periodically (once every second) similar to fsync on a disk. > So the indexes (in fact all Oak Documents) are synchronous on the local

Re: [suggestion] introduce oak compatibility levels

Hi, > But we could introduce a concept of > 'compatibility levels' which are a set of features/behaviours that a > particular oak version has and that application code relies upon. When > creating a session by default the 'newest compatibility level' would be > used, but applications could opt to

Re: Specifying threadpool name for periodic scheduled jobs (OAK-4563)

Hi, > Now should we use > > A - one single pool for all of the above > B - use the pool only for 1-3. The default pool would be of 5. So even > if #2 #3 are running > it would not hamper #1 While I'd want option#B to a better option, but I'd like to add one quick bit - we'd need to also

Re: [VOTE] Release Apache Jackrabbit Oak 1.4.5

On Wed, Jul 13, 2016 at 7:43 PM, Dominique Jaeggi wrote: > Please vote on releasing this package as Apache Jackrabbit Oak 1.4.5. > The vote is open for the next 72 hours and passes if a majority of at > least three +1 Jackrabbit PMC votes are cast. > ALL CHECKS OK +1 Release

Re: [VOTE] Release Apache Jackrabbit Oak 1.2.15

[X] +1 Release this package as Apache Jackrabbit Oak 1.2.15 Thanks, Vikas

Re: [VOTE] Release Apache Jackrabbit Oak 1.4.2

On Tue, May 3, 2016 at 8:52 PM, Davide Giannella wrote: > > A candidate for the Jackrabbit Oak 1.4.2 release is available at: > > https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.4.2/ > > The release candidate is a zip archive of the sources in: > > >

Re: [VOTE] Release Apache Jackrabbit Oak 1.2.14

On Wed, Apr 20, 2016 at 10:25 AM, Amit Jain wrote: > [X] +1 Release this package as Apache Jackrabbit Oak 1.2.14 Thanks, VIkas

Re: Extracting subpaths from a DocumentStore repo

Hi Robert, > The main inconvenient is that many times commmits which affect /foo and > /bar are have the commit root at '/', commit roots are required only at multi doc commit time (to track 2 phase commit logic's 'lock' document). So, node state for following 2 repo states is equiavelent (for a

Re: [Blocked] Re: Oak 1.3.17/1.4.0 release plan

> https://issues.apache.org/jira/browse/OAK-4066 This issue is resolved now.

Anchor tags on doc pages get positioned wrongly under top menu

Hi, I'm sure we all have noticed that our anchor tags scroll the page a little too much such that the actual position gets hidden under the same menu. With google and this link [0], it seems, we can just plug-in ``` :target:before { content:""; display:block; height:40px; /* fixed header

Re: OAK-4006 : Enable cloning of repo for shared data store and discovery-lite

> but that we'd otherwise have had to do for OAK-3935, right? True :) > As deleting sling.id.file is still required and > likely a separate task, as that's on a sling level and you can't combine > that into the oak-run tool from a separation of concern pov. > I just realised that most probably I

Re: [discuss] Optimise UNION (OAK-1617)

Hi Davide, I think 'OR' gets passed as constraints to underlying index engine (property, lucene, solr) etc. For lucene case (I guess solr too), I think having a bunch is of 'OR' is more useful than doing a union at query engine as: * single query to lucene would save multiple hops into index *

Re: jackrabbit-oak build #7189: Broken

Travis builds are failing intermittently due to: broadcastTCP(org.apache.jackrabbit.oak.plugins.document.persistentCache.BroadcastTest) Time elapsed: 4.012 sec <<< FAILURE! java.lang.AssertionError: min: 90 got: 80 at org.junit.Assert.fail(Assert.java:88) at

Re: [DISCUSS] avoid bad commits with mis-behaving clock

Opened OAK-3883 for this. Have added following: * We can start self-destrucut mode while updating lease * Revision creation should check that newly created revision isn't beyond leaseEnd time * Implementation done for OAK-2682 might be useful to summarize suggestions from this thread. @Julian, if

[DISCUSS] avoid bad commits with mis-behaving clock

Hi, Recently, in on one of our 3-node clusters, system clock on one server instance jumped ahead by 7.5 hours. The cluster is setup on OAK-1.0.22 so it had features which stall background read (OAK-3388 [0]) if repository seems to be ahead in time. But, it doesn't have lease check feature in

  1   2   >