Re: Lucene Index property Definitions

[Vikas Saurabh]

> 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,
‘image’)] in sql2 would look like select [jcr:path] from [app:Asset] where
contains(jcr:content/metadata/format, 'image')

Basically, nodeScopeIndex does a fulltext search on the whole selected node
(that is the indexed property is indexed as if the node has the value being
indexed). Otoh, analyzed would do fulltext search on the property being
indexed itself.

All that said, could you please open a doc issue to improve the language
and add sql2 examples.

--Vikas
(sent from mobile)

Re: Lucene Index property Definitions

[Vikas Saurabh]

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
queries. But it is not clear the difference or the specific situation, I
think. Any additional reference or explanation is appreciated.

The details of each field have examples to show the difference. Pasting
from the docs:
---
nodeScopeIndex
Control whether the value of a property should be part of fulltext
index. That is, you can do a jcr:contains(., ‘foo’) and it will return
nodes that have a string property that contains the word foo. Example

//element(*, app:Asset)[jcr:contains(., ‘image’)]

In case of aggregation all properties would be indexed at node level by
default if the property type is part of includePropertyTypes. However if
there is an explicit property definition provided then it would only be
included if nodeScopeIndex is set to true.

analyzed
Set this to true if the property is used as part of contains. Example

//element(*, app:Asset)[jcr:contains(type, ‘image’)]
//element(*, app:Asset)[jcr:contains(jcr:content/metadata/@format,
‘image’)]
---

--Vikas
(sent from mobile)

Re: Plugging an Observer with access to NodeStore

[Vikas Saurabh]

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 if you
can take cue from LucenePropertyIndexTest which sets up repository sans
osgi. While creating Oak instance, you can do .with(Observer) to inject
your own observer.

--Vikas
(sent from mobile)

Re: Lucene index: getting empty result while query

[Vikas Saurabh]

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 creating an index
> [async] The index update failed
> org.apache.jackrabbit.oak.api.CommitFailedException: OakAsync0002: Missing
> index provider detected for type [counter] on index [/oak:index/counter]
>
> can you help me to find what wrong I am doing here,
>

I pasted your code as is at my end and the test passes with following
in console output

Path=/test/a


For me indexing wasn't failing:

19:10:06.044 INFO  [async-index-update-async]
FulltextBinaryTextExtractor.java:332 Loaded default Tika Config from
classpath 
file:/home/vsaurabh/depot/git/CQ-misc/jackrabbit-oak/oak-search/target/classes/org/apache/jackrabbit/oak/plugins/index/search/spi/editor/tika-config.xml
19:10:06.328 INFO  [async-index-update-async]
IndexingProgressReporter.java:123 Indexing report
- /oak:index/counter*(4)
- /oak:index/lucene*(2)

19:10:06.328 INFO  [async-index-update-async]
IndexingProgressReporter.java:124 Reindexing completed
19:10:06.332 INFO  [async-index-update-async]
AsyncIndexUpdate.java:778 [async] Reindexing completed for indexes:
[/oak:index/counter*(4), /oak:index/lucene*(2)] in 2.407 s (2407 ms)


I'm at:

commit fcefd93d08040cac6726ba35d1188dd59698ae62 (HEAD -> trunk,
origin/trunk, origin/HEAD)
Author: Julian Reschke 
Date:   Wed Oct 9 11:10:08 2019 +

OAK-8685: Deprecate Guava based APIs in WhiteboardUtils

git-svn-id:
https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1868176
13f79535-47bb-0310-9956-ffa450edef68


Could you double check that you're indeed running things correctly?

Thanks,
Vikas

Re: Intent to backport OAK-8449

[Vikas Saurabh]

+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 DocumentNodeStore
> MBean and must be triggered manually by a user.
>
> Regards
>  Marcel
>
>

Re: Lucene Index Extraction

[Vikas Saurabh]

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
> https://jackrabbit.apache.org/oak/docs/query/lucene.html#luke (I
> downloaded
> the jar) but no luck so far.
>
> This is what I get when I try to get index info:
>
> C:\Users\Jorge Eduardo\Desktop>java -jar oak-run-1.12.0.jar console
> --read-write mongodb://localhost:37017/rRepo4
> Apache Jackrabbit Oak 1.12.0
> Jackrabbit Oak Shell (Apache Jackrabbit Oak 1.12.0, JVM: 1.8.0_191)
> Type ':help' or ':h' for help.
>
> ---
> /> lc info /oak:index/LuceneFullText
> ERROR groovy.lang.GroovyRuntimeException:
> Could not find matching constructor for:
>
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.OakDirectory(org.apache.jackrabbit.oak.spi.state.ReadOnlyBuilder,
> org.apache.jackrabbit.oak.plugins.index.search.IndexDefinition,
> java.lang.Boolean)
> at
> org.apache.jackrabbit.oak.console.commands.LuceneCommand.getDirectory
> (LuceneCommand.groovy:132)
> at
> org.apache.jackrabbit.oak.console.commands.LuceneCommand$_closure1.doCall
> (LuceneCommand.groovy:54)
> at java_lang_Runnable$run.call (Unknown Source)
> at org.apache.jackrabbit.oak.console.GroovyConsole$OakSh.run
> (GroovyConsole.groovy:265)
> at org.apache.jackrabbit.oak.console.GroovyConsole.run
> (GroovyConsole.groovy:74)
> at org.apache.jackrabbit.oak.console.Console.main (Console.java:74)
> at org.apache.jackrabbit.oak.run.ConsoleCommand.execute
> (ConsoleCommand.java:27)
> at org.apache.jackrabbit.oak.run.Main.main (Main.java:49)
> />
>
> Similiar error if I try to dump the index:
> C:\Users\Jorge Eduardo\Desktop>java -jar oak-run-1.12.0.jar console
> mongodb://localhost:37017/rRepo4
> Apache Jackrabbit Oak 1.12.0
> Repository connected in read-only mode. Use '--read-write' for write
> operations
> Jackrabbit Oak Shell (Apache Jackrabbit Oak 1.12.0, JVM: 1.8.0_191)
> Type ':help' or ':h' for help.
>
> ---
> /> lc dump "C:\Users\Jorge Eduardo\Desktop\lc" /oak:index/LuceneFullText
> ERROR groovy.lang.GroovyRuntimeException:
> Could not find matching constructor for:
>
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.OakDirectory(org.apache.jackrabbit.oak.spi.state.ReadOnlyBuilder,
> org.apache.jackrabbit.oak.plugins.index.search.IndexDefinition,
> java.lang.Boolean)
> at
> org.apache.jackrabbit.oak.console.commands.LuceneCommand.getDirectory
> (LuceneCommand.groovy:132)
> at
> org.apache.jackrabbit.oak.console.commands.LuceneCommand$_closure2.doCall
> (LuceneCommand.groovy:77)
> at java_lang_Runnable$run.call (Unknown Source)
> at org.apache.jackrabbit.oak.console.GroovyConsole$OakSh.run
> (GroovyConsole.groovy:265)
> at org.apache.jackrabbit.oak.console.GroovyConsole.run
> (GroovyConsole.groovy:74)
> at org.apache.jackrabbit.oak.console.Console.main (Console.java:74)
> at org.apache.jackrabbit.oak.run.ConsoleCommand.execute
> (ConsoleCommand.java:27)
> at org.apache.jackrabbit.oak.run.Main.main (Main.java:49)
>
> I am pretty certain that I am missing or misusing something, or just
> ignoring some necessary condition that makes it work.
>
> Anyway, any help is greatly appreciated.
>
> Regards,
>
> Jorge Flórez
>

Re: About text extraction for index

[Vikas Saurabh]

>  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 cases text extraction should finish within a reasonable
time. But, at times, due to a bad file or a bug in parser the extraction
process keeps on running - that used to hold up indexing for the whole
setup. Since the assumption with a timed out extraction is that tika or
whichever parser is in play might be stuck and Thread.stop could leave
things in incorrect state potentially affecting subsequent operations.

-Vikas
(sent from mobile)

Re: About text extraction for index

[Vikas Saurabh]

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 -Doak.extraction.inCallerThread=true

Hope that helps.

[0]:
http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/ExtractedTextCache.java?view=markup=1814745#l61

--Vikas
(sent from mobile)

Re: [VOTE] Release Apache Jackrabbit Oak 1.14.0

[Vikas Saurabh]

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: "amd64",
family: "unix"
[INFO] Java version: 11.0.3, vendor: Oracle Corporation, runtime:
/usr/lib/jvm/java-11-openjdk-amd64
[INFO] MAVEN_OPTS: -Xmx4096m -Xms4096m
[INFO] 
[INFO] ALL CHECKS OK
[INFO] 

Thanks,
Vikas

Re: Query options in queries with OR

[Vikas Saurabh]

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 passed into subqueries. I
> have fixed it in my copy of sources in
> org.apache.jackrabbit.oak.query.QueryImpl.copyOf() by copying options too.
>
>
> Best regards,
>
> Piotr Tajduś
>
>
>

Missing fixed oak issue in 1.6.16 release notes

[Vikas Saurabh]

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 release notes. The
current fix version field is set to contain both 1.6.16 (to capture
reality) and 1.6.17 (to get part of release notes for 1.6.17).

Re-tagging a published release note to include it would be problematic
- so, I'm just notifying the dev list about it (the issue also
captures these details).

[0]: https://issues.apache.org/jira/browse/OAK-7975

Thanks,
Vikas

Re: [VOTE] Release Apache Jackrabbit Oak 1.6.16

[Vikas Saurabh]

> 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 count
> the votes next Monday so you have until then to either confirm or deny
> this -1.

Thinking further and some discussion off-list, I think releasing with
some high-sev (query fails with no work-around) although low-prio (due
to low chances of hitting the situation) known issue is probably not a
good idea.

I'm confirming my -1. We should re-start release with OAK-7975 included.

Thanks,
Vikas

Re: [VOTE] Release Apache Jackrabbit Oak 1.6.16

[Vikas Saurabh]

 [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 when multiple
faceted properties are requested (common scenario) but one of those
properties doesn't exist in the repository. e.g. we ask for
facet(title) and facet(tags) but "tags" property doesn't exist
anywhere in the index/repository.

Imo, the issue is bad - but I don't expect the scenario to unfold in a
real life production instance (with sufficient variance of data) and
non-existent value for a property which is configured for faceting.

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,
Vikas

Re: [VOTE] Release Apache Jackrabbit Oak 1.9.13

[Vikas Saurabh]

> [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, vendor: Oracle Corporation
[INFO] 
[INFO] ALL CHECKS OK
[INFO] 

Thanks,
Vikas

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

[Vikas Saurabh]

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:
>

Disclaimer: I've assumed that "similarity search is active" meant it's
being used in current system and not just the capability - if that
assumption is incorrect, then just ignore this mail.

While what Matt said could likely answer how to implement the
potential solution you mentioned. But, just having the capability to
support similarity search isn't enough for similarity search to be
active. You would have to have some index definition which is indexing
some data for similarity (what Tommaso's suggestion was looking for).

So, if an index def has {{useInSimilarity}} then that index definition
would be doing similarity search based indexiing and queries for some
property. I assume the index provisioning code would be aware of
"availability" of similarity search before it provisioned the
definition. So, I would probably lean towards Tommaso's suggestion -
although I think final check might have to cleaned up according to
what exactly you want to verify.

Thanks,
Vikas

quick heads up (probably)

[Vikas Saurabh]

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]: 
https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1638969.html
[2]:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.22.0:test
(default-test) on project oak-commons: There are test failures.
[ERROR]
[ERROR] Please refer to
/home/vsaurabh/depot/git/CQ-misc/jackrabbit-oak/oak-commons/target/surefire-reports
for the individual test results.
[ERROR] Please refer to dump files (if any exist)
[date]-jvmRun[N].dump, [date].dumpstream and
[date]-jvmRun[N].dumpstream.
[ERROR] The forked VM terminated without properly saying goodbye. VM
crash or System.exit called?
[ERROR] Command was /bin/sh -c cd
/home/vsaurabh/depot/git/CQ-misc/jackrabbit-oak/oak-commons &&
/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java -Xmx512m
-XX:+HeapDumpOnOutOfMemoryError -Dupdate.limit=100
-Djava.awt.headless=true -jar
/home/vsaurabh/depot/git/CQ-misc/jackrabbit-oak/oak-commons/target/surefire/surefirebooter1205900898949015751.jar
/home/vsaurabh/depot/git/CQ-misc/jackrabbit-oak/oak-commons/target/surefire
2018-11-04T17-56-45_235-jvmRun1 surefire7462720948606186742tmp
surefire_06938085570281395129tmp
[ERROR] Error occurred in starting fork, check output in log
[ERROR] Process Exit Code: 1
[ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException:
The forked VM terminated without properly saying goodbye. VM crash or
System.exit called?
[ERROR] Command was /bin/sh -c cd
/home/vsaurabh/depot/git/CQ-misc/jackrabbit-oak/oak-commons &&
/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java -Xmx512m
-XX:+HeapDumpOnOutOfMemoryError -Dupdate.limit=100
-Djava.awt.headless=true -jar
/home/vsaurabh/depot/git/CQ-misc/jackrabbit-oak/oak-commons/target/surefire/surefirebooter1205900898949015751.jar
/home/vsaurabh/depot/git/CQ-misc/jackrabbit-oak/oak-commons/target/surefire
2018-11-04T17-56-45_235-jvmRun1 surefire7462720948606186742tmp
surefire_06938085570281395129tmp
[ERROR] Error occurred in starting fork, check output in log
[ERROR] Process Exit Code: 1
[ERROR] at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:671)
[ERROR] at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:533)
[ERROR] at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:278)
[ERROR] at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:244)
[ERROR] at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1194)
[ERROR] at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1022)
[ERROR] at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:868)
[ERROR] at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
[ERROR] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
[ERROR] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
[ERROR] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
[ERROR] at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
[ERROR] at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
[ERROR] at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
[ERROR] at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
[ERROR] at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
[ERROR] at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
[ERROR] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
[ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:955)
[ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:290)
[ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:194)
[ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[ERROR] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[ERROR] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[ERROR] at java.lang.reflect.Method.invoke(Method.java:498)
[ERROR] at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
[ERROR] at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
[ERROR] at

Re: [VOTE] Release Apache Jackrabbit Oak 1.9.7

[Vikas Saurabh]

Hi,
> [X ] +1 Release this package as Apache Jackrabbit Oak 1.9.7
>

[INFO] 
[INFO] ALL CHECKS OK
[INFO] 

with;
[INFO] 
[INFO] Apache Maven 3.5.0
[INFO] OS name: "linux", version: "4.13.0-46-generic", arch: "amd64",
family: "unix"
[INFO] Java version: 1.8.0_171, vendor: Oracle Corporation

Thanks,
Vikas

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

[Vikas Saurabh]

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 implementation
instead of discovering issues after the fact (opened OAK-7700 [1] for
this)

[0]: https://issues.apache.org/jira/browse/OAK-7699
[1]: https://issues.apache.org/jira/browse/OAK-7700

Thanks,
Vikas

Re: [VOTE] Release Apache Jackrabbit Oak 1.8.6

[Vikas Saurabh]

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: "amd64",
family: "unix"
[INFO] Java version: 1.8.0_171, vendor: Oracle Corporation
[INFO] 
[INFO] ALL CHECKS OK
[INFO] 

Thanks,
Vikas

Re: Jackrabbit Oak 1.8.6 Release Plan

[Vikas Saurabh]

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 scheduled for release on next Monday. If there are no
> reported issues, it's planned to skip that release, so if you have any
> issues, please report them by Monday.
>
> Best regards,
> Manfred
>

Re: [VOTE] Release Apache Jackrabbit Oak 1.9.6

[Vikas Saurabh]

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
>> elapsed: 15.595 s <<< FAILURE! - in
>> org.apache.jackrabbit.oak.plugins.blob.UploadStagingCacheTest
>> [ERROR]
>> testConcurrentSameAddRequest(org.apache.jackrabbit.oak.plugins.blob.UploadStagingCacheTest)
>>   Time elapsed: 0.214 s  <<< FAILURE!
>> java.lang.AssertionError: expected:<2> but was:<1>
>>  at
>> org.apache.jackrabbit.oak.plugins.blob.UploadStagingCacheTest.assertCacheStats(UploadStagingCacheTest.java:843)
>>  at
>> org.apache.jackrabbit.oak.plugins.blob.UploadStagingCacheTest.testConcurrentSameAddRequest(UploadStagingCacheTest.java:456)
>>
>> [INFO]
>> [INFO] Results:
>> [INFO]
>> [ERROR] Failures:
>> [ERROR]
>> UploadStagingCacheTest.testConcurrentSameAddRequest:456->assertCacheStats:843
>> expected:<2> but was:<1>
>
>
> I've seen this at least once recently (on trunk), but it wasn't reproducible
> over here.
>
Ok, even for me it was a transient issue (Created a test issue OAK-7646)


[INFO]OK: mvn clean verify -Ppedantic
[INFO]
[INFO] 
[INFO] Apache Maven 3.5.0
[INFO] OS name: "linux", version: "4.13.0-45-generic", arch: "amd64",
family: "unix"
[INFO] Java version: 1.8.0_171, vendor: Oracle Corporation
[INFO] 
[INFO] ALL CHECKS OK
[INFO] 


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

Thanks,
Vikas

Re: [VOTE] Release Apache Jackrabbit Oak 1.9.6

[Vikas Saurabh]

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:
>
>
> https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.9.6/
>
> The SHA1 checksum of the archive is
> 751251a67669e8e211275b767b78927a7f7963ab.
>
> A staged Maven repository is available for review at:
>
> https://repository.apache.org/
>
> The command for running automated checks against this release candidate is:
>
> # run in SVN checkout of
> https://dist.apache.org/repos/dist/dev/jackrabbit
> $ sh check-release.sh oak 1.9.6 751251a67669e8e211275b767b78927a7f7963ab
>
> Please vote on releasing this package as Apache Jackrabbit Oak 1.9.6.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.
>
> [ ] +1 Release this package as Apache Jackrabbit Oak 1.9.6
> [ ] -1 Do not release this package because...
> D.

I got following error (re-running build in the mean time)



[INFO] Running org.apache.jackrabbit.oak.plugins.blob.UploadStagingCacheTest
[ERROR] Tests run: 22, Failures: 1, Errors: 0, Skipped: 0, Time
elapsed: 15.595 s <<< FAILURE! - in
org.apache.jackrabbit.oak.plugins.blob.UploadStagingCacheTest
[ERROR] 
testConcurrentSameAddRequest(org.apache.jackrabbit.oak.plugins.blob.UploadStagingCacheTest)
 Time elapsed: 0.214 s  <<< FAILURE!
java.lang.AssertionError: expected:<2> but was:<1>
at 
org.apache.jackrabbit.oak.plugins.blob.UploadStagingCacheTest.assertCacheStats(UploadStagingCacheTest.java:843)
at 
org.apache.jackrabbit.oak.plugins.blob.UploadStagingCacheTest.testConcurrentSameAddRequest(UploadStagingCacheTest.java:456)

[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR]   
UploadStagingCacheTest.testConcurrentSameAddRequest:456->assertCacheStats:843
expected:<2> but was:<1>
[INFO]
[ERROR] Tests run: 179, Failures: 1, Errors: 0, Skipped: 0
[INFO]
[INFO] 
[INFO] Reactor Summary:
[INFO]
[INFO] Oak Parent POM . SUCCESS
[01:22 min]


[INFO] Oak Blob Plugins ... FAILURE [
38.111 s]
[INFO] Oak Core ... SKIPPED


[INFO] Jackrabbit Oak . SKIPPED
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 03:34 min
[INFO] Finished at: 2018-07-19T14:59:14+05:30
[INFO] Final Memory: 128M/4032M
[INFO] 
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.22.0:test
(default-test) on project oak-blob-plugins: There are test failures.
[ERROR]
[ERROR] Please refer to
/home/vsaurabh/depot/svn/check-releases/target/jackrabbit-oak-1.9.6/zip/jackrabbit-oak-1.9.6/oak-blob-plugins/target/surefire-reports
for the individual test results.
[ERROR] Please refer to dump files (if any exist)
[date]-jvmRun[N].dump, [date].dumpstream and
[date]-jvmRun[N].dumpstream.
[ERROR] -> [Help 1]


-

My setup looks like:
$ mvn -version
Apache Maven 3.5.0
Maven home: /usr/share/maven
Java version: 1.8.0_171, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_IN, platform encoding: UTF-8
OS name: "linux", version: "4.13.0-45-generic", arch: "amd64", family: "unix

Thanks,
Vikas

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

[Vikas Saurabh]

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 
> in your email. The empty role means that the mbean is related to the “main” 
> node store, while non-empty one is only used for the partial node stores, 
> gathered together by CNS. Maybe we can use similar approach here?
>

Indeed the problem statement is exactly same for
ActiveDeletedBlobCollectorMBeanImpl. I've 2 subsequent questions:
* why was it still useful to expose multiple instances of
RevisionGCMBean - should it not have been more useful/backward
compatible [0] (or maybe it's already there but I'm unable to see
where it is happening) to have single exposed implementation which
multiplexes as it seems fit
** Basically, afaict, repository level/checkpoint operations are
implicitly singleton per repository - that the composite node store is
multiplexing across multiple underlying store should not, imo, affect
what's being exposed.
* I can't quite find where "role" is being set for DocumentNodeStore
(I think I can see where seg store is doing it). Also, does it mean
that any new store needs to be aware that it needs to expose role?

[0]: 
https://issues.apache.org/jira/browse/OAK-5309?focusedCommentId=16020939=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16020939

Thanks,
Vikas

Decide if a composite node store setup expose multiple checkpoint mbeans

[Vikas Saurabh]

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 being, we are going to avoid that confusion by
changing ActiveDeletedBlobCollectorMBeanImpl to keep on returning
oldest checkpoint timestamp if all CheckpointMBean implementations
report the same oldest checkpoint timestamp. But that "work-around"
works currently because composite node store uses global node store to
list checkpoint to get oldest timestamp... but the approach is
incorrect in general as there's no such guarantee.

So, here's the question for the discussion: how should the situation
be handled correctly. Afaict, there are a few options (in decreasing
order of my preference):
1. there's only a single checkpoint mbean exposed (that implies that
mounted node store services need to "know" that they are mounted
stores and hence shouldn't expose their own bean)
2. composite node store's checkpointMBean implementation can expose
some metadata (say implement a marker interface) - discovering such
implementation can mean "use this implementation for repository level
functionality"
3. keep the work-around to be implemented in OAK-7610 [0] but document
(ensure??) that the assumption that "all implementations would have
same oldest checkpoint timestamp"

Would love to get some feedback.

[0]: https://issues.apache.org/jira/browse/OAK-7610
[1]: https://issues.apache.org/jira/browse/OAK-7315


Thanks,
Vikas

Re: [VOTE] Release Apache Jackrabbit Oak 1.9.4

[Vikas Saurabh]

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 ./target/jackrabbit-oak-1.9.4.log for full details.

I'm also seeing the same issue.

Thanks,
Vikas

Re: [VOTE] Release Apache Jackrabbit Oak 1.9.3

[Vikas Saurabh]

> [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 version: 1.8.0_162, vendor: Oracle Corporation
[INFO] 
[INFO] ALL CHECKS OK
[INFO] 

Thanks,
Vikas

Re: Intent to backport OAK-6294

[Vikas Saurabh]

+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. The effect of the issue
> is rather severe because it can cause a repository inconsistency.
>
> Regards
>  Marcel
>
>

Re: oak-search module

[Vikas Saurabh]

+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
> indexes [1], I'd like to create a new module called _oak-search_.
> Such module will contain:
> - implementation agnostic utilities for full text search (e.g. aggregation
> utilities)
> - implementation agnostic SPIs to be extended by implementors (currently we
> expose SPIs in oak-lucene whose signatures include Lucene specific APIs)
> - abstract full text editor / query index implementations
> - text extraction utilities
>
> Please share your feedback / opinions / concerns.
>
> Regards,
> Tommaso
>
> [1] : https://issues.apache.org/jira/browse/OAK-3336

Re: Oak related question

[Vikas Saurabh]

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" : 
> "\":blobId:0100c49320202c3c0269aea8e3cf205f4765e4c4e55a7102fae9d09a4307c05f0aafdac20954\"",
> "r1622ed13bac-0-c8" : 
> "\":blobId:0100c59320201328a6ecda51a2a57ab20e5d86173711f60ed07de212d2a81c918b3b56aecb63\"",
> "r1622ef69b14-0-ca" : 
> "\":blobId:0100cb932020be60317852ad8925c2c51d5c6df4092f6bdfbc961666e64779642a04146e70dd\""
> },
>
> We have nodes with 30+ available versions. But we do not need them. Oak run 
> shows this old versios as garbage, but revisions gc and blobs gc do not 
> deleted them.
>
> It is possible to delete all old versions for each node and leave only one 
> actual version?

While, I don't know of any way of "forcing" only 1 version to remain
for a binary reference - BUT,
https://issues.apache.org/jira/browse/OAK-5205 might be useful to drop
the reference rather early so that it can be garbage collected.

Thanks,
Vikas

Re: [VOTE] Release Apache Jackrabbit Oak 1.8.2

[Vikas Saurabh]

> [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, vendor: Oracle Corporation
[INFO] 
[INFO] ALL CHECKS OK
[INFO] 

Thanks,
Vikas

Re: Intent to backport OAK-7176

[Vikas Saurabh]

+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 contract. The fix is easy and low risk.
>
> Regards
>  Marcel
>

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

[Vikas Saurabh]

+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

[Vikas Saurabh]

+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

[Vikas Saurabh]

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
 wrote:
> ...
> In my naive assumption I would say that the fulltext constraint, if splitting 
> into multiple queries will be part of any on the disjunctive statements (or 
> unions) and with that the queryNorm(q) according to 
> https://lucene.apache.org/core/4_7_0/core/org/apache/lucene/search/similarities/TFIDFSimilarity.html
>  
> 
>  will be the same for each of the queries. Property constraints and even path 
> constraints could potentially be boosted to 0 to not have any impact on the 
> score - anyway from what I could observe in our tests scores are, if coming 
> from the same index, comparable across (similar) queries with the same 
> fulltext constraint but different property constraints.
>

While your argument for TFIDF similarity is correct for the fulltext
clauses. But complete score also account for other clauses in the
query. Consider following example

(A AND B AND contains('test')) OR (C AND contains('test'))

when lucene would score first sub-query, the fulltext similarity would
get 1/3rd because there are 2 more matches (assuming score for A, B
and C be boosted to 0 as you said). Otoh, for the second sub-query, it
would only get halved. Also, documents from first clause that might
alst have C as true would also not get scored for that (assuming we
don't boost to 0 and have better matches above).

Otoh, if we could send the whole query to lucene (which is
unfortunately not possible today) then all resulting documents would
have got scored on equal footing.

(of course, btw, this is a trivial example but I guess it would bring
out the point why UNION scores aren't necessarily comparable even if
they get answered by the same index).

Thanks,
Vikas

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

[Vikas Saurabh]

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 and fixed in r1818991.

Thanks,
Vikas

Re: [VOTE] Release Apache Jackrabbit Oak 1.7.14

[Vikas Saurabh]

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: "4.13.0-19-generic", arch: "amd64",
family: "unix"
[INFO] Java version: 1.8.0_151, vendor: Oracle Corporation
[INFO] 

Thanks,
Vikas

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

[Vikas Saurabh]

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: INFRA-15629>
>  URL: https://issues.apache.org/jira/browse/INFRA-15629>
>  Project: Infrastructure>
>   Issue Type: Bug>
>       Components: Git, Github>
> Reporter: Vikas Saurabh>
>
>
> The Apache git [1] and GitHub [2] mirrors of the svn repo for jackrabbit-oak 
> is not in sync anymore.>
>
> The last synced commit is:>
> git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1817274 
> 13f79535-47bb-0310-9956-ffa450edef68>
> which is from more than 2 weeks ago.>
>
> Note: jackrabbit [3] git synchronization does seem to be working properly and 
> there have been a lot of commits to svn since then (so, blank commit trick 
> likely won't work).>
>
> \[1] git://git.apache.org/jackrabbit-oak.git>
> \[2] https://github.com/apache/jackrabbit>
> \[3] git://git.apache.org/jackrabbit.git>
>
>
>
> -->
> This message was sent by Atlassian JIRA>
> (v6.4.14#64029)>
>

Re: Intent to backport OAK-4518

[Vikas Saurabh]

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 backport OAK-4518 to maintenance branches 1.4 and older. Stale
> entries in the docChildrenCache can cause inconsistencies in the
> repository. As mentioned in the issue data from test and production systems
> show a low hit rate on this cache and disabling the cache does not show
> significant changes in oak-benchmark results. Impact on performance is
> therefore low.
>
> Regards
>  Marcel
>
>

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

[Vikas Saurabh]

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

[Vikas Saurabh]

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

[Vikas Saurabh]

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

[Vikas Saurabh]

  [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

[Vikas Saurabh]

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 between indexing cycle commits updated indexed
data and when the readers(tracker) updates itself to this new index.

> [0]
> https://github.com/stillalex/jackrabbit-oak/blob/trunk/oak-api/src/main/java/org/apache/jackrabbit/oak/api/jmx/IndexStatsMBean.java#L26
>
> On Thu, Oct 5, 2017 at 4:49 PM, Robert Munteanu  wrote:
>
>> In Sling we have some tests which validate that full text search is
>> working. Occasionaly this test times out because the full-text lucene
>> index is not updated and a traversal query is used. More details at
>> [1].
>>
While, I agree, oak doesn't currently have a fool proof way of
providing this data. As a work-around though, what can be done is
commit a simple data and then query (in a loop with some sleep... and
maybe some timeout) until this new data is available. Availability of
indexed data on reader side, while asynchronous, would still follow
chronological order.

>>
>> [1]: https://issues.apache.org/jira/browse/SLING-7169
>>

Thanks,
Vikas

Re: [VOTE] Release Apache Jackrabbit Oak 1.7.8

[Vikas Saurabh]

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

Thanks,
Vikas

Re: Intent to backport OAK-6685

[Vikas Saurabh]

+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 branches. The fix is simple
> and I consider the risk as very low.
>
> Regards
>  Marcel

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

[Vikas Saurabh]

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 Chetan,
>>
>> Was your concern a -1 or a +/- 0?
>>
>> Thanks,
>> Vikas

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

[Vikas Saurabh]

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

[Vikas Saurabh]

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 package upgraded
setup with latest oak (yes, I understand that's not the case for AEM).
But, my hidden agenda is that "this is a bad bug + the fix is simple
=> we should fix it".
But, sure, if it doesn't feel right, then I agree it's a not a major
bug from backport pov.

Thanks,
Vikas

Re: [VOTE] Release Apache Jackrabbit Oak 1.6.5

[Vikas Saurabh]

> [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

[Vikas Saurabh]

+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.

Thanks,
Vikas

On Fri, Aug 18, 2017 at 1:41 PM, Chetan Mehrotra
 wrote:
> At time index corruption is being seen which can be attributed to
> issue fixed in OAK-5238. To address them I need to backport this to
> 1.4 and 1.2 branch.
>
> This change is slightly bigger so need to be done carefully
>
> Chetan Mehrotra

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

[Vikas Saurabh]

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

[Vikas Saurabh]

[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

[Vikas Saurabh]

> 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 version (whenever we'd have 1.9.*... someone would have
to remember to bump base version to 1.8)

> [1] 
> http://felix.apache.org/components/bundle-plugin/baseline-mojo.html#comparisonVersion

That said, is it fair to expect clients bumping to major version of
oak AND depend on o.a.j.o.api.jmx AND not have compile their own
bundles against the upgraded version?

Thanks,
Vikas

Re: [VOTE] Release Apache Jackrabbit Oak 1.7.1

[Vikas Saurabh]

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"  wrote:
>
> [X] +1 Release this package as Apache Jackrabbit Oak 1.7.1
>
>
> I had a transient error on
> 'ActiveDeletedBlobCollectorTest.multiThreadedCommits:230' but it went away
> on the second run.
>
> alex
>
>
> On Tue, Jun 6, 2017 at 2:27 PM, Davide Giannella  
> wrote:
>
> > A candidate for the Jackrabbit Oak 1.7.1 release is available at:
> >
> > https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.7.1/
> >
> > The release candidate is a zip archive of the sources in:
> >
> >
> > 
> https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.7.1/
> >
> > The SHA1 checksum of the archive is
> > 4109f37f1533b6aa23f667fbd8d0ef213e67d6aa.
> >
> > A staged Maven repository is available for review at:
> >
> > https://repository.apache.org/
> >
> > The command for running automated checks against this release candidate 
> is:
> >
> > $ sh check-release.sh oak 1.7.1 4109f37f1533b6aa23f667fbd8d0ef
> > 213e67d6aa
> >
> > Please vote on releasing this package as Apache Jackrabbit Oak 1.7.1.
> > The vote is open for the next 72 hours and passes if a majority of at
> > least three +1 Jackrabbit PMC votes are cast.
> >
> > [ ] +1 Release this package as Apache Jackrabbit Oak 1.7.1
> > [ ] -1 Do not release this package because...
> >
> > Davide
> >
>
>

Re: Intent to backport to 1.6: OAK-6267

[Vikas Saurabh]

+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 DocumentNodeStore based setups

Chetan Mehrotra

Re: failure building oak-upgrade

[Vikas Saurabh]

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

[Vikas Saurabh]

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. You need 
> to add the corresponding jar file supporting this SPI to your classpath.
>
I use:
java -cp "oak-lucene-1.X.Y.jar;luke-with-deps.jar" org.getopt.luke.Luke
which resolves the codec.

Thanks,
Vikas

Re: Intent to backport to 1.6: OAK-6116

[Vikas Saurabh]

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

[Vikas Saurabh]

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
you might be plugging in. It'd definitely be better to utilise JCR API...
Session.save() would persist the changes.

--Vikas
(sent from mobile)

On Mar 4, 2017 03:36, "Alex Benenson"  wrote:

> Hi all
>
> Following an earlier discussion about storing a large number of nodes at
> root, I am trying to move content nodes from root into a hierarchy
> /documents/xx/yy/{id}
>
> Hitting some issues:
>
> 1 - loop over all nodes in root,  move each content node
>
> root.getChildNodeEntries().forEach(entry -> {
>   NodeState nodeState = entry.getNodeState();
>
>   if (isMyContentNode(nodeState)) {
>  String name = entry.getName();
>
>  // get or create parent folder
> NodeBuilder parent = getParent(name);
>
> NodeBuilder builder = rootBuilder.child(name);
> boolean result = builder.moveTo(parent, name);
>
> if (result)
>   counter++;
> else
>   logger.warn('not moved");
>   }
> });
>
>
> after executing this with no warnings, all nodes are stil in the root
> folder (inspected using oak-mongo.js)
>
>
> 2 - run garbage collection
> nodeStore.getVersionGarbageCollector().gc(1, TimeUnit.SECONDS);
>
> all nodes are still in the root
>
>
>
>
> Questions:
>
> 1 - Is this the right approach to move nodes in the repository? Or should I
> create a repository and use either Session.move or Workspace.move?
>
>
> 2 - how do I force old revisions out of root?
>
> Thanks in advance
>
> -- Alex
>
>
>
>
>
>
> --
> Alex Benenson
>

Re: [VOTE] Release Apache Jackrabbit Oak 1.6.1

[Vikas Saurabh]

[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

[Vikas Saurabh]

> 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, but in the whole
initialize method, that line seems like the only candidate that should
be "changing" anything - other ones are already guarded to be working
well in a pre-initialized repository afaics.

Thanks,
Vikas

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

[Vikas Saurabh]

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 read all children of root node.

While this could probably be done as an improvement in oak to
check-then-set behavior. But, as others noted, may be creating a very
flat hierarchy might lead to more troubles down the line.

Thanks,
Vikas

Re: Supporting "resumable" operations on a large tree

[Vikas Saurabh]

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 specific order used is implementation
dependent and may change across different states of the same node."

I'm not entirely sure if that's completely ambiguous - but afaik the
behavior of current stores (Tar - both versions, MongoMK and RDB),
they'd indeed to do stable iterations at a given revision even on
multiple calls to getChildNodeEntries. I wonder if we should call it
out explicitly too.

Btw, I think we'd still need to make a checkpoint to safeguard against
rev-gc/compaction.

Also, afaiu,
[Marcel]
> An intermediate commit (OAK-2556) would have to be annotated with the
> current path, while the checkpoint stays the same. For the re-index use case
> this probably also means an indirection for the index data tree is
> necessary.

and

[Thomas]
> For example use a "fromPath"
> .. "toPath" range, and only re-index part of the repository at a time

are different ideas. Marcel probably meant an intermediate commit with
some prop making current_path while Thomas is probably saying that we
should do indexing on sub-trees and hence have kind-of shards of the
index.

I don't think we should do shard-approach at least on lucene indices
as doing post-query-merge won't give right relevance ordering.
Also, I don't think we have a good heuristic to assert a shard-depth
(e.g. if we shard at each children of root node and most of the
content is under /content, then we won't save much)

Thanks,
Vikas

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

[Vikas Saurabh]

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 the data is
> available in multi-instance cluster?

That (eventually consistent changes across cluster nodes) is indeed by
design. The background operations, that you were explicitly calling,
by default run in 1 s intervals. There are 2 background operations in
reality - backgroundUpdate and backgroundRead. "backgroundUpdate" one
essentially "publishes" (loosely speaking) the changes to be consumed
by other cluster nodes. "backgroundRead" one pull in "published"
changes by other cluster nodes. So, in a normally running system, in
worst cases, you can see 2s latency before the changes are visible
everywhere. The reason I said "normally running" is that background
threads might not get a chance every second on a busy setup.

Thanks,
Vikas

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

[Vikas Saurabh]

> 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 take exclusive locks so it'd
drop concurrent access performance a lot. Moreover, I don't think
background operations are supposed to be run concurrently - so, there
might be other issue too.

> HTTP servers are load balanced.
>
Is it possible for you to set up session/cookie based load balancer?
For example the dispatcher (in AEM setups) sets up a rendid cookie so
that related requests are sent same AEM instance.

Thanks,
Vikas

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

[Vikas Saurabh]

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
>>ones don't get to listener
>
>>Is this expected?
>
> Good point. I think this might have been known but not really acknowledged
> as a bug. I guess the reason being that in reality, for a large n,
> consuming the queue while no new change is coming in sounds unrealistic.
>
Yeah, I realized why this was never a big deal/remained undiscovered.

> But agreed, this is a bug and we should fix it.
>
Actually, I'm not too sure as long as we concretely document the
behavior and potentially have a sample abstract
commit-creator/listener which does the job well (may be similar to the
hack I used)

> A fix could perhaps be to keep track of the Cn+1 (the overflow change)
> more explicitly - and check for that also when polling from the queue.
>
I really don't want to change a behavior unless I can guarantee that
nothing un-expected happen. Observation being so core, I wonder how
easily/confidently can we give that guarantee.

>>I was under the assumption that on arrival of Cn+1,
>>Cn gets dropped and Cn+1 is put in. Cn+1 is also marked external.
>
> No, only in case Cn was external and Cn+1 is also external does Cn get
> dropped and Cn+1 added instead.
>
Ack.

Thanks,
Vikas

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

[Vikas Saurabh]

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 comes - this marks Cn as "external" and itself
gets dropped
* The listener can consume all events till Cn, but Cn+1 and future
ones don't get to listener
* Add another Cn+w after listener has consumed some events
* The listener would now consume event by diff(Cn, Cn+w)

(patch which updates an existing test to show this at [0]. That patch
would make ObservationQueueFullWarnTest#warnOnQueueFull fail.)

Is this expected? I was under the assumption that on arrival of Cn+1,
Cn gets dropped and Cn+1 is put in. Cn+1 is also marked external.

Thanks,
Vikas

[0]:
diff --git 
a/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/observation/ObservationQueueFullWarnTest.java
b/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/observation/ObservationQueueFullWarnTest.java
index dda8eab..3fddac5 100644
--- 
a/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/observation/ObservationQueueFullWarnTest.java
+++ 
b/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/observation/ObservationQueueFullWarnTest.java
@@ -115,6 +115,7 @@ public class ObservationQueueFullWarnTest extends
AbstractRepositoryTest {
 try {
 customLogs.starting();
 addNodeToFillObsQueue();
+emptyObsQueue();
 assertTrue("Observation queue full warning must get
logged", customLogs.getLogs().size() > 0);
 customLogs.finished();
 } finally {
@@ -196,7 +197,7 @@ public class ObservationQueueFullWarnTest extends
AbstractRepositoryTest {
 throws RepositoryException {
 blockObservation.acquireUninterruptibly();
 try {
-for (int i = 0; i <= OBS_QUEUE_LENGTH; i++) {
+for (int i = 0; i <= OBS_QUEUE_LENGTH+1; i++) {
 addANode("n");
 }
 } finally {
@@ -222,6 +223,7 @@ public class ObservationQueueFullWarnTest extends
AbstractRepositoryTest {
 //up in case last few event were dropped due to full
observation queue
 //(which is ok as the next event that comes in gets
diff-ed with last
 //processed revision)
+/*
 if (numAddedNodes.get() < numObservedNodes.get() +
OBS_QUEUE_LENGTH) {
 try {
 addANode("addedWhileWaiting");
@@ -229,6 +231,7 @@ public class ObservationQueueFullWarnTest extends
AbstractRepositoryTest {
 LOG.warn("exception while adding during wait: {}", e);
 }
 }
+*/
 Thread.sleep(OBS_TIMEOUT_PER_ITEM/10);//The constant is exaggerated
 remaining = end - System.currentTimeMillis();
 }

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

[Vikas Saurabh]

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)

[Vikas Saurabh]

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 *wasn't*
blocking.

BUT, when queue empties, blocking flag is reset inside if block for
commitRateLimiter!=null. That, to me seems like
qFull->log->qEmpties->qFull won't log another warn. This sounds wrong
to me.

Thanks,
Vikas

Re: [VOTE] Release Apache Jackrabbit Oak 1.5.18

[Vikas Saurabh]

[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?

[Vikas Saurabh]

> 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. E.g. it could be at r10-0-1,r7-0-2. On the next index update
> (after the recovery), the head revision used to compare against the
> checkpoint will be r10-0-1,r9-0-2. Now CN1 will update the index with
> changed that happened between r7-0-2 and r9-0-2.
>
Oh, yes. You're right. I was investigating some issue where last rev
update were lost (still haven't gotten around to see why recovery
didn't work). But that led my thoughts astray. Would write a test and
validate - I still have a bit of nagging feeling.

Thanks,
Vikas

Re: [VOTE] Release Apache Jackrabbit Oak 1.0.36

[Vikas Saurabh]

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

Thanks,
Vikas

Re: [VOTE] Release Apache Jackrabbit Oak 1.5.16

[Vikas Saurabh]

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

Thanks,
Vikas

Re: [VOTE] Release Apache Jackrabbit Oak 1.5.15

[Vikas Saurabh]

[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

[Vikas Saurabh]

[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

[Vikas Saurabh]

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 thus requiring
>>special UI for user/group management
>
> Are you talking about real users/groups as defined by the Jackrabbit
> user management or about simple principals as we discussed during the
> last Oakathon? For the latter the UI is limited to crx-explorer which
> is the only UI Adobe provides that exposes the principal management UI.
>

I meant groups via jackrabbit user management. I was leaning out of
this option due to point#3 (eerie feeling)

>>* can potentially affect login performance - I haven't checked how
>>OAK-3003 works.. maybe, it's a non-issue
>
> Without knowing the exact details of your use-case: depending on how your
> synthetic-groups are envisioned to work and whether or not this member
> is really intended to be edited and managed through the CQ user management
> UI, you may consider solving this with principal management rather than
> user management... see above and also referring to the conversation
> we had last time.
>

To elaborate a bit on use-case: consider 2 personas like ""
and "". Where  (or ) is essentially a
"synonym" of what type of privileges do s have (it might be
more that read... it might be read on current node + some more privs
for content-structure under it.
All  need to have same type of access on the content.
Similarly  have same perms. The group idea was to create
"content-1-viewer" and "content-1-editor" group, give relevant access
on "content-1" to these groups, and then make actual users member of
these groups depending on if they are viewer or editor
(there's another persona "author" who is stronger that editor in the
sense that they are allowed to make others , , etc...
I kept to 2 for simplification.

>>The other end of the spectrum is to provide explicit ACLs on the node
>>per principal. It's ok for us to go this way... but we ended up with
>>an open question on the subject the mail. Do we know how ACL
>>evaluation performance behave wrt number-of-ACLs on a node - assuming
>>ACLs-per-principal won't be a big number?
>
> The access control content as stored with the individual nodes in ACLs
> and ACEs is _not_ used for the evaluation at all. Permission evaluation
> and thus performance of permission evaluation of the default authorization
> model is purely defined by the performance of compiling effective
> permissions from the data stored in the permission store at
> /jcr:system/rep:permissionStore.
>
> In other words: the permission evaluation is based on the following
> pieces:
>
> 1. the set of principals as pushed to the subject upon authentication
> 2. permission-entries stored separately for each principal in the
> perm-store
> 3. separation of the 2 types of principals as defined by java (Principal
> and java.security.acl.Group)
>
> Based on the original design goals we laid out for Oak promising that
> flat hierarchies of non-ordered nodes is supported, I would not expect
> issues with a huge amount of permission entries in the store for a single
> principal.

That's good to know :). So, unless we're talking about editing
permissions on the node, it should be ok for having large number of
ACL/Es.

>
> On the other hand: access control entries as edited by the default
> user facing access control management implementation are collected in
> a list which be definition has an order. this is reflected by the
> content structure storing ACEs as nodes below a policy node that is defined
> to have orderable children. Since support for huge flat hierarchies
> of _orderable_ nodes was a explicit non-goal of Oak, I would expect
> to see limitations here when it comes to tens of thousands of ACEs
> for a given single ACL.

Good point. This reminds me that we might also hit document size limit
(or maybe not!!) as :childorder is a single array and huge value can
befuddle mongomk in some cases (e.g. OAK-4322.. but then 16MB is a big
number)


> My take is: if a given application ends up with
> tens of thousands of access control entries within a given list this
> may either highlight design issues with the content modelling wrt
> security or it may give us a hint that a different authorization model
> might be more suited for that use-case.

I posted a few details on the use-case a bit above in this reply.
Would you please comment on how to have persona based authorization
for say some flat content structure. As an analogy, I can think of say
google docs... how should one go about managing content structure and
privileges. It might be a digression on this thread. I'd be happy to
fork this discussion out.

>
>>I was thinking of writing a benchmark to see but wanted to copy some
>>closely related existing benchmark. It'd great if there are some
>>pointers for this 

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

[Vikas Saurabh]

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 obvious side-effects:
* systems gets flooded with system-generated-groups thus requiring
special UI for user/group management
* can potentially affect login performance - I haven't checked how
OAK-3003 works.. maybe, it's a non-issue
* eerie feeling to require additional groups :)

The other end of the spectrum is to provide explicit ACLs on the node
per principal. It's ok for us to go this way... but we ended up with
an open question on the subject the mail. Do we know how ACL
evaluation performance behave wrt number-of-ACLs on a node - assuming
ACLs-per-principal won't be a big number?

I was thinking of writing a benchmark to see but wanted to copy some
closely related existing benchmark. It'd great if there are some
pointers for this :).

Thanks,
Vikas

Re: Possibility of making nt:resource unreferenceable

[Vikas Saurabh]

> 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 Oak itself
> completely.

That'd just shift the storage from collection/table to
index/rdb_index. At least mongo tries to keep its indices in memory,
so the memory overhead would probably remain similar (well, in terms
of order of magnitude at least).

I think avoiding un-necessary uuid and optimizing uuid index are 2
separate problems. Chetan and Thomas, afaics, are discussing the
former.

Thanks,
Vikas

Re: Oak HTTP binding README -> Error 500 OakConstraint0055

[Vikas Saurabh]

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 
a/oak-http/src/main/java/org/apache/jackrabbit/oak/http/OakServlet.java
b/oak-http/src/main/java/org/apache/jackrabbit/oak/http/OakServlet.java
index c6bcd3b..5947980 100644
--- a/oak-http/src/main/java/org/apache/jackrabbit/oak/http/OakServlet.java
+++ b/oak-http/src/main/java/org/apache/jackrabbit/oak/http/OakServlet.java
@@ -33,12 +33,15 @@ import com.fasterxml.jackson.core.JsonFactory;
 import com.fasterxml.jackson.databind.JsonNode;
 import com.fasterxml.jackson.databind.ObjectMapper;
 import com.fasterxml.jackson.dataformat.smile.SmileFactory;
+import org.apache.jackrabbit.JcrConstants;
 import org.apache.jackrabbit.oak.api.CommitFailedException;
 import org.apache.jackrabbit.oak.api.ContentRepository;
 import org.apache.jackrabbit.oak.api.ContentSession;
 import org.apache.jackrabbit.oak.api.Root;
 import org.apache.jackrabbit.oak.api.Tree;
+import org.apache.jackrabbit.oak.api.Type;
 import org.apache.jackrabbit.oak.commons.PathUtils;
+import org.apache.jackrabbit.oak.plugins.memory.PropertyStates;
 import org.apache.jackrabbit.util.Base64;
 import org.apache.tika.mime.MediaType;

@@ -192,6 +195,8 @@ public class OakServlet extends HttpServlet {
 tree.setProperty(name, value.asDouble());
 } else if (value.isBigDecimal()) {
 tree.setProperty(name, value.decimalValue());
+} else if (JcrConstants.JCR_PRIMARYTYPE.equals(name)) {
+tree.setProperty(name, value.asText(), Type.NAME);
 } else {
 tree.setProperty(name, value.asText());
 }
```

(that is assume jcr:primaryType to always be of type NAME) lets the
stuff through. May be, that's good enough to un-block you (assuming
you're compiling your own oak-run jar to play around)

Thanks,
Vikas

Re: Infinite loop

[Vikas Saurabh]

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: org.apache.jackrabbit.oak-core 1.2.11

Good to know... but, I'm afraid my knowledge is almost already
exhausted. Someone else on the list might come up with better ideas
:).

Thanks,
Vikas

Re: Infinite loop

[Vikas Saurabh]

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
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopier$CopyOnWriteDirectory.openInput(IndexCopier.java:718)
> at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:324)

That would usually indicate some discrepancy between file content
stored in the repository and on filesystem (ignore the details if
you're new to this as you said earlier).

Would you remember what action caused this issue to appear? In the
past, we've seen cases where index definitions were installed using
AEM's package manager leading to such issues. Another reason has been
using ACS Common's Ensure oak index tool (btw, that issue has been
since resolved in ensure oak index).

BTW, which oak version are you using? (in your AEM installation, you
can go to /system/console and find version for oak-core)

Thanks,
Vikas

Re: Infinite loop

[Vikas Saurabh]

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 time around it restarts
(Actually, it would have logged some error the first time around it
hit the exception).

Otoh, if the index is covering property indices, then you might be
hitting some other issue(s).

Thanks,
Vikas

On Thu, Sep 15, 2016 at 12:29 AM, Thiago Sanches  wrote:
> Hello guys,
>
> I'm new with oak indexes and I'm using it with Adobe AEM. Here we created
> some indexes that it's seems that they are stucked in a infinite looping
> for example:
>
> Reindexing Traversed #4 ...
> Reindexing Traversed #5 ...
> Reindexing Traversed #6 ...
>
> This process are decreasing the system performance.
> I could not find any information about that.
> Could you have any advice?
>
> Thanks.

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

[Vikas Saurabh]

> 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
> --
> https://issues.apache.org/jira/browse/OAK-4153

Thanks,
Vikas

Re: normalising the rdb database schema

[Vikas Saurabh]

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 it'd easy to flip the switch for existing
setups.
* DocumentNodeStore implementation very freely touches prop:rev=value
for a given id... i.e it assumes there's no cost (at least minimal)
cost involved in persisting those (a commit would tentatively set the
value and flip it to null (which in new schema would be same as
deleting the row) if the commit fails). I think this would get
expensive for index (_id+propName+rev) maintenance - note, in current
scheme of things a document gets deleted only on revision gc ... so,
index cost is really very minimal (well, apart from _modified one)...

Btw, I like the basic idea (and the advantages that you mentioned)...
just that I think we probably need to be careful if we go ahead with
this.

Thanks,
Vikas

On Tue, Aug 16, 2016 at 12:25 PM, Tomek Rekawek  wrote:
> Hello,
>
> I was wondering whether it’d make sense to normalise the RDB Document Store 
> schema - get rid of the JSON/JSOP concatenated strings and store each 
> key/value in a separate database row. Something like this:
>
> id  STRING
> key STRING
> revisionSTRING (nullable)
> value   (LONG) STRING
> modcountINTEGER
>
> The id+key+revision would make an unique primary key.
>
> So, an example node from the DocumentMK documentation [1]:
>
> {
> "_id" : "1:/node",
> "_deleted" : {
> "r13f3875b5d1-0-1" : "false"
> },
> "_lastRev" : {
> "r0-0-1" : "r13f3875b5d1-0-1"
> },
> "_modified" : NumberLong(274208361),
> "_modCount" : NumberLong(1),
> "_children" : Boolean(true),
> "_revisions" : {
> "r13f3875b5d1-0-1" : "c"
> }
> }
>
> Would transform to following database rows:
>
> (id, key, revision, value, modcount)
> (“1:/node”, “_deleted”, "r13f3875b5d1-0-1”, “false”, 1)
> (“1:/node”, “_lastRev”, "r0-0-1”, “r13f3875b5d1-0-1”, 1)
> (“1:/node”, “_modified”, null, “274208361”, 1)
> (“1:/node”, “_children”, null, “true”, 1)
> (“1:/node”, “_revisions”, "r13f3875b5d1-0-1", “c”, 1)
>
> Creating a new document would require batching a few INSERTs. Updating a 
> document will combine INSERTs (for the new properties) and UPDATEs (for the 
> modified ones). Each update would end with a modcount increment for all rows 
> related to the given document. Fetching a document will require reading all 
> rows for given id. I think all of these reads and writes can be done in 
> batches, so we’ll end up with a single database call anyway.
>
> Advantages I can see here are:
>
> * no need to parse/serialize JSONs and JSONPs (less load on the Oak instance),
> * no need to periodically compact the JSONPs,
> * more granular updates are possible, we can properly implement all the 
> UpdateOp cases,
> * we can better use the database features, as now the DBE is aware about the 
> document internal structure (it’s not a blob anymore). Eg. we can fetch only 
> a few properties.
>
> For me such design looks more natural and RDB-native. The schema is just a 
> draft and probably I’m missing something, but I wanted to ask about a general 
> feedback on this approach. WDYT?
>
> Regards,
> Tomek
>
> --
> Tomek Rękawek | Adobe Research | www.adobe.com
> reka...@adobe.com
>

Re: Property index replacement / evolution

[Vikas Saurabh]

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 of the 1s sync operation was to reduce the
> writes to the root node to n/s where n is the number of instances in the
> cluster, however based on what you are telling me the rate is (m+n)/s where
> m is the total commits per second of the whole cluster. I understand that
> the update to test for a conflicted commit may not be the same as the
> update of _lastRevs, but in MongoDB both update the MongoDB document.
>

I'm not sure of the exact numbers around how MongoDB would perform for
lots of edits to the same document. There's a bit of difference
between _lastRev write and commit-root conditional update -
commit-root update is a change on a sub-document... so, something like
'set "_revision.rX"="c" on _id=0:/ iff "_conflict.rX"' doesn't exist.
While last rev updates change the same key across commits from the
same cluster node - something like 'set "_lastRevs.r0-0-X"="rY-0-X" '.
I think the idea is to avoid any conflict on MongoDB's update
statements. I'm not sure if such edits (edits to same doc but at a
different sub-doc/key) degrade performance badly.

Thanks,
Vikas
PS: I wonder if we should open a different thread as it seems to be
digressing from the subject :)

Re: Property index replacement / evolution

[Vikas Saurabh]

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 Oak
> instance and are synchronous on remote Oak instances but with a minimum
> data latency of the root document sync rate (1s). IIUC the 1 second sync
> period is a performance optimisation as the root document must be updated
> by every commit and hence is a global singleton in an Oak cluster, and
> already hot as you point out in 3.
>

Just to clarify a bit. There are potentially 2 updates that can modify
root document.
With every commit, oak (document mk) defines a document to be
commit-root. That's root of the sub-tree which changes. A commit is
successful if commit-root could be conditionally updated (condition to
see if the commit conflicted with something else or not). With
synchronous prop indices, commit root usually is at root - so each
successful commit would write to root. That's what Michael was
pointing to in point3.
The other update is about asynchronous update of _lastRevs - _lastRevs
control visibility horizon. For local nodes, a pending list of updates
is kept in memory so local sessions/builders get to see committed
changes. These are pushed to persistence mongo during background
update which defaults at 1 s interval. So, other cluster nodes don't
see changes immediately.

Thanks,
Vikas

Re: [suggestion] introduce oak compatibility levels

[Vikas Saurabh]

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 use an older, compatibility level 1.2
> for example, when they still rely on the feature-set/behaviour oak had at
> that time.

My defensive side feels that doing compatibility type feature is
harder to maintain than to implement. Primary point being that such
cross cutting configurations affect code flows at arbitrary places.
That along with linear growth of compatibilities would, imo, be harder
to test and certify (to think at unit level, it might still work out
with really going rigorous with parametrized tests... but doing ITs
specially on stuff like part of repo was done at vX and run with
compatibility at vY... is vZ still ok with it?). I think being server
side (enterprisey??), oak does have a small luxury of relying on
acceptance testing type of processes with hard
deprecations/removal/changes.

I mean, I understand the requirement for such cases... but we should
probably don't add a feature for this... a hack to remain backward
compatible (e.g. session refresh due to apps used to relying on jr2)
should probably treated as such and removed going forward with a blunt
hammer. And, even if we don't remove this, this should probably just
remain as limited hack-specific thing.

Thanks,
Vikas

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

[Vikas Saurabh]

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 take care of that async indexing itself
could "potentially" require multiple tasks (lanes?? in async indexing
terminology).

While 5 threads would still take care of 3 async indexing lanes +
task#2 + task#3. But, I wonder, if we should further split as
async-index-pool (tasks for #1), background-jobs-pool (#2, #3, maybe
more??), #4 probably goes into default-pool.

Thanks,
Vikas
PS: the assumption is that async indexing task can "potentially" take
time (e.g. if there's binary extraction in the picture) + number of
async indexing lanes is configurable at repository creation time

Re: [VOTE] Release Apache Jackrabbit Oak 1.4.5

[Vikas Saurabh]

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 this package as Apache Jackrabbit Oak 1.4.5

Thanks,
Vikas

Re: [VOTE] Release Apache Jackrabbit Oak 1.2.15

[Vikas Saurabh]

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

Thanks,
Vikas

Re: [VOTE] Release Apache Jackrabbit Oak 1.4.2

[Vikas Saurabh]

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:
>
>
> https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.4.2/
>
> The SHA1 checksum of the archive is
> 7ff7036b4d9e2acc45af07688145a6914166f4a0.
>
> A staged Maven repository is available for review at:
>
> https://repository.apache.org/
>
> The command for running automated checks against this release candidate is:
>
> $ sh check-release.sh oak 1.4.2 7ff7036b4d9e2acc45af07688145a6914166f4a0
>
> Please vote on releasing this package as Apache Jackrabbit Oak 1.4.2.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.
>
> [ ] +1 Release this package as Apache Jackrabbit Oak 1.4.2
> [ ] -1 Do not release this package because...
>
> Davide
>

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

Thanks,
Vikas

Re: [VOTE] Release Apache Jackrabbit Oak 1.2.14

[Vikas Saurabh]

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

[Vikas Saurabh]

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 committed revision R1):
1. "/node1"->_commitRoot.R1="0" AND "/"->_revision.R1="c"
2. "/node1"->_revision.R1="c"

Since, you'd be working at persistence level, you can always map
_commitRoot.RX=N to _revision.RX="c" where RX is validated to be
already committed.

Although, this rewrite won't change document node state but it indeed
changes document state... but that should be OK for your case and
document cache is an in-memory cache while node state cache is backed
by pers. cache.

> so the collections extracted
> using something like oak-run.js' printMongoExportCommand will not work.

'printMongoExportCommand' currently is really dumb... in the sense
that it doesn't care about revisions etc. For a given path, it simply
gets it path elements and prints a mongo export command for each of
those paths (ie input path and its ancestors) as well as their split
doc counterparts. Since output of such exports are usually used by us
for debug purposes (and hence we'd have the idea if multiplexing doc
store is in play or not), we might simply document the expected
behavior and not care much about exactness of export. Otoh, we might
want to add some intelligence about multiplexing... but, I think that
should be towards lower priority.

> 1) Manually create a new commit for each sub-path ( e.g. 1 for /foo and
> 1 for /bar ) and re-write the commit references for each node document
> so that they point to the new commits

So, I'd like approach 1 except that we don't create new commits.. just
sew the current state to break commit root dependency

> Approach 1) is probably going to get me in trouble with the
> DocumentNodeStore caches, so the Oak instance might not be usable after
> I perform these changes ( which can be fine, since I'm going to spin it
> up just for that ).

See above (part 1 for cache)

Thanks,
Vikas

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

[Vikas Saurabh]

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

Anchor tags on doc pages get positioned wrongly under top menu

[Vikas Saurabh]

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 height*/
margin:-40px 0 0; /* negative fixed header height */
}
```
in oak-doc/src/site/resources/site.css to fix the issue.

But, since I suck at html/css, I wasn't sure if this is fine. '40px'
is manual hit-and-trial. Is there something better?

Thanks,
Vikas

[0]: 
https://www.itsupportguides.com/tech-tips-tricks/how-to-offset-anchor-tag-link-using-css/

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

[Vikas Saurabh]

> 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 mis-understood sling id file as
cluster id... while I think that's persistent instance id, right? In
that case, it of course won't be a good idea to connect those 2
concepts -- cluster id and instance id (even if it was all being done
inside oak)

Thanks,
Vikas

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

[Vikas Saurabh]

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
* lucene's default relevance sort is very useful (as it orders more
matched 'OR's over less matches)

So, while agree, that the result would be same at the end of day but
we 'might' get less performant.

Disclaimer: I'm assuming UNION implies 'solving each query
indepedently and provide union-ed result'. Ignore this mail, if that's
not the case.

Thanks,
Vikas

On Wed, Feb 3, 2016 at 4:25 PM, Davide Giannella  wrote:
> Hello team,
>
> back in 1.3.9 we introduced
> https://issues.apache.org/jira/browse/OAK-1617 which indirectly
> addressed https://issues.apache.org/jira/browse/OAK-2660 and
> https://issues.apache.org/jira/browse/OAK-2539.
>
> This has been proven to work out fine. However if we come from an xpath
> query which has been already converted into UnionImpl, it won't be
> optimised. With optimisation it's meant: converting, as of now, OR into
> UNION.
>
> There are some cases where the two issues could appear within one or
> more of the queries of UnionImpl.
>
> So my idea is: could we attempt a generation of UnionImpl off Query
> within UnionImpl? It's a kind-of recursive thing.
>
> On paper I don't see any problem as something like
>
> select * from [nt:base] where [a] = 1 OR [b] = 2
> union
> select * from [nt:base] where [c] = 3 OR [d] = 4
>
> would be translated into
>
> select * from [nt:base] where [a] = 1
> union
> select * from [nt:base] where [b] = 2
> union
> select * from [nt:base] where [c] = 3
> union
> select * from [nt:base] where [d] = 4
>
> It should give the same resultset. Shouldn't it?
>
> The framework in place with OAK-1617 already adopt a cost oriented
> model. So with little changes we could generate more than one
> alternatives and peak the cheapest one.
>
> thoughts?
>
> Davide
>
>

Re: jackrabbit-oak build #7189: Broken

[Vikas Saurabh]

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 org.junit.Assert.assertTrue(Assert.java:41)
at 
org.apache.jackrabbit.oak.plugins.document.persistentCache.BroadcastTest.broadcast(BroadcastTest.java:219)
at 
org.apache.jackrabbit.oak.plugins.document.persistentCache.BroadcastTest.broadcastTCP(BroadcastTest.java:146)
...


@Thomas, should we disable the test?

Thanks,
Vikas

On Fri, Jan 15, 2016 at 4:32 PM, Travis CI  wrote:
> Build Update for apache/jackrabbit-oak
> -
>
> Build: #7189
> Status: Broken
>
> Duration: 859 seconds
> Commit: d0e5a75921c452ae370036ea02026cb4205fe6f6 (trunk)
> Author: Tommaso Teofili
> Message: OAK-3847 - added FacetResult API for easily retrieving facets
>
> git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1724767 
> 13f79535-47bb-0310-9956-ffa450edef68
>
> View the changeset: 
> https://github.com/apache/jackrabbit-oak/compare/3d7583b7ded8...d0e5a75921c4
>
> View the full build log and details: 
> https://travis-ci.org/apache/jackrabbit-oak/builds/102566453
>
> --
> sent by Jukka's Travis notification gateway

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

[Vikas Saurabh]

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 I understand correctly, OAK-2682 currently is about
warning, right? It mentions a self-desctruct option but I think it
wasn't implemented.

Thanks,
Vikas

[DISCUSS] avoid bad commits with mis-behaving clock

[Vikas Saurabh]

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 place (OAK-2739 [1] and friends)

The issue:
Once the rogue instance committed with future time, other instances
reacted with pausing background reads for 7.5 hours leading to
(expected) CommitFailedException in the logs and more importantly (and
missing in logs) that the instances were out of sync.

While generally speaking, this is an operational issue and clocks
should remain in sync - but I think it's fair to say that once the
instance is restarted after synchronizing clock things should work
out. That's not the case currently as the instances would want to wait
7.5 hours.

There's a bit of respite on trunk (due to [1] and friends) and a
sequence of events like {{t1 -> update lease}}, {{t2=t1+7.5hrs ->
commit}} would lead to a shutdown as a big jump like 7.5 hours would
be beyond lease end time. BUT, if there's lease update before a commit
after a clock jump, then even on trunk there's no safeguard.
If we update lease update logic to shut down as well in case it can't
update lease for a long time then an instance with forward jumping
clock would self-destruct.

BTW, the approach mentioned above saves only agains a clock which
jumps ahead directly. We'd still have similar issue for a clock slowly
skews forward. But, even then I think it's worth it to have to solve
the particular case.

Note, this doesn't really add any incosistency in the repository -
just makes instances on correct clock to not operate well.

Thanks,
Vikas

[0]: https://issues.apache.org/jira/browse/OAK-3388
[1]: https://issues.apache.org/jira/browse/OAK-2739