[Oak origin/1.4] Apache Jackrabbit Oak matrix - Build # 1239 - Still Failing

[Apache Jenkins Server]

The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build 
#1239)

Status: Still Failing

Check console output at 
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1239/ to view 
the results.

Changes:
[reschke] OAK-4997: RevisionGCTest.teardown() may fail with NPE when store == 
null

[reschke] OAK-4980: remove JournalGCIT - not needed anymore (ported to 1.4)

[reschke] OAK-4986: RDBDocumentStore: potential NPE in document read (ported to

 

Test results:
1 tests failed.
FAILED:  
org.apache.jackrabbit.oak.plugins.segment.standby.ExternalPrivateStoreIT.testProxySkippedBytes

Error Message:
expected:<{ root = { ... } }> but was:<{ root : { } }>

Stack Trace:
java.lang.AssertionError: expected:<{ root = { ... } }> but was:<{ root : { } }>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:144)
at 
org.apache.jackrabbit.oak.plugins.segment.standby.DataStoreTestBase.useProxy(DataStoreTestBase.java:193)
at 
org.apache.jackrabbit.oak.plugins.segment.standby.DataStoreTestBase.testProxySkippedBytes(DataStoreTestBase.java:127)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at 
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at 
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)

Issues waiting for changes in DocumentStore API

[Chetan Mehrotra]

We currently have few open issues which are dependent on updating the
DocumentStore API

OAK-3878 - Avoid caching of NodeDocument while iterating in
BlobReferenceIterator
OAK-3001 - Simplify JournalGarbageCollector using a dedicated timestamp property

It would be good if we can decide what the api should be now such that
these issues can be addressed in 1.6 release.

May be we go for usecase specific api?

Chetan Mehrotra

[ANNOUNCE] Apache Jackrabbit Oak 1.4.9 released

[Davide Giannella]

The Apache Jackrabbit community is pleased to announce the release of
Apache Jackrabbit Oak 1.4.9 The release is available for download at:

http://jackrabbit.apache.org/downloads.html

See the full release notes below for details about this release:


Release Notes -- Apache Jackrabbit Oak -- Version 1.4.9

Introduction


Jackrabbit Oak is a scalable, high-performance hierarchical content
repository designed for use as the foundation of modern world-class
web sites and other demanding content applications.

Jackrabbit Oak 1.4.9 is a patch release that contains fixes and
improvements over Oak 1.4. Jackrabbit Oak 1.4.x releases are
considered stable and targeted for production use.

The Oak effort is a part of the Apache Jackrabbit project.
Apache Jackrabbit is a project of the Apache Software Foundation.

Changes in Oak 1.4.9
-

Technical task

[OAK-4885] - RDB*Store: update mysql JDBC driver reference to
5.1.40
[OAK-4905] - RDB*Store: update postgresql JDBC driver reference to
9.4.1211
[OAK-4964] - UpdateOp.set("_id", ...) should do a sanity check on
the id

Bug

[OAK-4082] - RDBDocumentStore on MySQL may fail when using
useServerPrepStmts=true
[OAK-4860] - Backport OAK-4301 and OAK-4825
[OAK-4879] - Proper implementation of getOrCreateReferenceKey in
CachingFDS
[OAK-4894] - Potential NPE in Commit.apply()
[OAK-4930] - External Principal Management: DynamicSyncContext
makes redundant calls to IdentityProvider.getIdentity()
[OAK-4931] - LdapIdentityProvider doesn't use configured custom
attributes for all searches
[OAK-4937] - JournalGC failing with RDB DocumentStore

Improvement

[OAK-4674] - Log a message when asynchronous persistent cache is
enabled
[OAK-4825] - Support disabling of users instead of removal in
DefaultSyncHandler

Test

[OAK-4976] - AcquireRecoveryLockTest fails occasionally

In addition to the above-mentioned changes, this release contains
all changes included up to the Apache Jackrabbit Oak 1.4.x release.

For more detailed information about all the changes in this and other
Oak releases, please see the Oak issue tracker at

  https://issues.apache.org/jira/browse/OAK

Release Contents


This release consists of a single source archive packaged as a zip file.
The archive can be unpacked with the jar tool from your JDK installation.
See the README.md file for instructions on how to build this release.

The source archive is accompanied by SHA1 and MD5 checksums and a PGP
signature that you can use to verify the authenticity of your download.
The public key used for the PGP signature can be found at
http://www.apache.org/dist/jackrabbit/KEYS.

About Apache Jackrabbit Oak
---

Jackrabbit Oak is a scalable, high-performance hierarchical content
repository designed for use as the foundation of modern world-class
web sites and other demanding content applications.

The Oak effort is a part of the Apache Jackrabbit project. 
Apache Jackrabbit is a project of the Apache Software Foundation.

For more information, visit http://jackrabbit.apache.org/oak

About The Apache Software Foundation


Established in 1999, The Apache Software Foundation provides organizational,
legal, and financial support for more than 140 freely-available,
collaboratively-developed Open Source projects. The pragmatic Apache License
enables individual and commercial users to easily deploy Apache software;
the Foundation's intellectual property framework limits the legal exposure
of its 3,800+ contributors.

For more information, visit http://www.apache.org/

[RESULT][VOTE] Release Apache Jackrabbit Oak 1.4.9

[Davide Giannella]

Hello Team,

the vote passes as follows:

+1 Davide Giannella
+1 Julian Reschke
+1 Marcel Reutegger
+1 Alex Parvulescu

Thanks for voting. I'll push the release out.

-- Davide

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

[Michael Marth]

Here are some benchmarks, some of the on benchmarking access control 
performance:
https://github.com/apache/jackrabbit-oak/tree/trunk/oak-run/src/main/java/org/apache/jackrabbit/oak/benchmark

HTH
Michael




On 24/10/16 17:01, "Vikas Saurabh"  wrote:

>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: segment-tar depending on oak-core

[Michael Dürig]

On 25.10.16 11:05 , Davide Giannella wrote:

On 24/10/2016 14:30, Julian Reschke wrote:

On 2016-10-24 15:10, Davide Giannella wrote:

Wow, quite some replies :)
...
However we still have the original problem to address: how are we
planning to solve segment depending on oak depending on segment on third
party applications? I have two proposals here that we could vote on if
we want

1) Going back to monolithic? Read it as, segment-tar won't be released
any more on its own cycle.

2) We correctly address dependencies. For example adding oak-core-api.
...


If I had to do Oak releases, I'd clearly vote for 1) - this model has
drawbacks, but it's simple and easy to understand.


yes from a release pov it's way easier. However I'd like to ask to the
people who decided to go for the independent segment-tar release. What's
the rationale behind the decision? Why did we go in that direction that
was not possible to do with a monolithic?

Again, to be clear: I'm not championing neither one or the other
solution. I simply would like to a a solution done properly, and
hopefully quickly so that we ease our lives later on rather than
complicate it.


See my earlier reply to Julian Sedding where I stated the requirement to 
that respect.


Michael

Re: segment-tar depending on oak-core

[Davide Giannella]

On 24/10/2016 14:30, Julian Reschke wrote:
> On 2016-10-24 15:10, Davide Giannella wrote:
>> Wow, quite some replies :)
>> ...
>> However we still have the original problem to address: how are we
>> planning to solve segment depending on oak depending on segment on third
>> party applications? I have two proposals here that we could vote on if
>> we want
>>
>> 1) Going back to monolithic? Read it as, segment-tar won't be released
>> any more on its own cycle.
>>
>> 2) We correctly address dependencies. For example adding oak-core-api.
>> ...
>
> If I had to do Oak releases, I'd clearly vote for 1) - this model has
> drawbacks, but it's simple and easy to understand.

yes from a release pov it's way easier. However I'd like to ask to the
people who decided to go for the independent segment-tar release. What's
the rationale behind the decision? Why did we go in that direction that
was not possible to do with a monolithic?

Again, to be clear: I'm not championing neither one or the other
solution. I simply would like to a a solution done properly, and
hopefully quickly so that we ease our lives later on rather than
complicate it.

Davide

[Oak origin/trunk] Apache Jackrabbit Oak matrix - Build # 1238 - Still Failing

[Apache Jenkins Server]

The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build 
#1238)

Status: Still Failing

Check console output at 
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1238/ to view 
the results.

Changes:
[amitj] OAK-4979: Caching sub-system implementation for DataStore

[chetanm] OAK-4862 - Provide a MemoryNodeStoreService

 

Test results:
1 tests failed.
FAILED:  
org.apache.jackrabbit.oak.plugins.segment.standby.ExternalPrivateStoreIT.testProxySkippedBytes

Error Message:
expected:<{ root = { ... } }> but was:<{ root : { } }>

Stack Trace:
java.lang.AssertionError: expected:<{ root = { ... } }> but was:<{ root : { } }>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:144)
at 
org.apache.jackrabbit.oak.plugins.segment.standby.DataStoreTestBase.useProxy(DataStoreTestBase.java:193)
at 
org.apache.jackrabbit.oak.plugins.segment.standby.DataStoreTestBase.testProxySkippedBytes(DataStoreTestBase.java:127)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at 
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at 
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)

Re: segment-tar depending on oak-core

[Thomas Mueller]

Hi,

There are two "extreme" cases, and both are used and work fine (please
nobody says "it's a joke", and "monolithic" is worse):

* "Monolithic": Linux, Apache Lucene, and so on: one version for everything

* "Fine grained": Apache Sling: separate, independent versions for
everything

(actually I don't know more examples of "Fine grained")

Apache Sling doesn't really maintain multiple branches in the same way we
do in Oak. I argue that having to maintain multiple branches is easier
with the "monolithic" approach.