Oak 1.3.6 release plan

2015-09-10 Thread Marcel Reutegger 
Hi,

I plan to release 1.3.6 on Monday. And this time I really hope
I will have the time to actually perform the release. Thanks
Amit for taking care of the previous 1.3.5 release!

We currently have 86 issues scheduled for the release [0]. This
is roughly twice as many we had pending before the 1.3.5 release.
I assume this is because we recently grouped issues into themes
and scheduled them rather tightly. Please adjust fix versions
for issues you are familiar with already before the release
on Monday.

There are currently two critical issue unresolved for 1.3.6:

- OAK-2835: TARMK Cold Standby inefficient cleanup
- OAK-3235: Deadlock when closing a concurrently used FileStore

Please resolve or reschedule issues until Monday or let me know
if you need more time for a release blocking issue.

Regards
Marcel

[0] 
https://issues.apache.org/jira/issues/?jql=fixVersion%20%3D%201.3.6%20AND%20project%20%3D%20OAK%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC

Re: Oak 1.3.6 release plan

2015-09-10 Thread Tomek Rekawek 
Hello,

Can I ask some committer to merge two issues before the release?

OAK-3148
Allows to migrate one blobstore to another during normal Oak operations. 
Already reviewed by the Thomas Mueller.

OAK-2171
The command line interface for all the upgrade/sidegrade features in Oak with a 
bunch of unit tests.

Thanks,
Tomek


On 10/09/15 09:19, "Marcel Reutegger"  wrote:

>Hi,
>
>I plan to release 1.3.6 on Monday. And this time I really hope
>I will have the time to actually perform the release. Thanks
>Amit for taking care of the previous 1.3.5 release!
>
>We currently have 86 issues scheduled for the release [0]. This
>is roughly twice as many we had pending before the 1.3.5 release.
>I assume this is because we recently grouped issues into themes
>and scheduled them rather tightly. Please adjust fix versions
>for issues you are familiar with already before the release
>on Monday.
>
>There are currently two critical issue unresolved for 1.3.6:
>
>- OAK-2835: TARMK Cold Standby inefficient cleanup
>- OAK-3235: Deadlock when closing a concurrently used FileStore
>
>Please resolve or reschedule issues until Monday or let me know
>if you need more time for a release blocking issue.
>
>Regards
>Marcel
>
>[0] 
>https://issues.apache.org/jira/issues/?jql=fixVersion%20%3D%201.3.6%20AND%20project%20%3D%20OAK%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC

Re: JCR TCK tests on DOCUMENT_RDB

2015-09-10 Thread Julian Reschke 

On 2015-09-09 17:59, Julian Reschke wrote:

On 2015-09-09 17:49, Michael Dürig wrote:



On 9.9.15 3:55 , Julian Reschke wrote:

On 2015-09-09 15:27, Michael Dürig wrote:



On 8.9.15 2:49 , Julian Reschke wrote:

We'd need

   -Dnsfixtures=DOCUMENT_RDB -Prdb-derby
-Drdb.jdbc-url=jdbc:derby:foo\;create=true



You should be able to login to that Jenkins instance and edit its
configuration using your ASF U/P.

Michael


OK, I added these as global maven parameters (is there a way to specify
them for just a specific nsfixture?). Let's see what will come out of
it.



Test results:
44 tests failed.
...

https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/403/
...


But on JDK 1.8 only? Strange.

I'm reverting the config change and will investigate...


Tested on my machine and did not reproduce. Re-enabled on Jenkins, and 
got a single (different) test failure: 



So I'll leave this in, and will look at this individual test soonish.

Best regards, Julian

[Oak origin/trunk] Apache Jackrabbit Oak matrix - Build # 408 - Failure

2015-09-10 Thread Apache Jenkins Server 
The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build 
#408)

Status: Failure

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

Changes:
[chetanm] OAK-3375 - RepositoryManager doesn't perform a shutdown of 
OsgiRepository on deactivation

 

Test results:
1 tests failed.
FAILED:  
org.apache.jackrabbit.oak.plugins.document.blob.RDBBlobStoreTest.testBigBlob[1]

Error Message:
Java heap space

Stack Trace:
java.lang.OutOfMemoryError: Java heap space
at 
org.apache.jackrabbit.oak.plugins.document.blob.RDBBlobStoreTest.testBigBlob(RDBBlobStoreTest.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:483)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:24)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
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)

jackrabbit-oak build #6389: Broken

2015-09-10 Thread Travis CI 
Build Update for apache/jackrabbit-oak
-

Build: #6389
Status: Broken

Duration: 1213 seconds
Commit: 92d51da02f48842f6df2c433261d7e6fe13f1e1b (trunk)
Author: Marcel Reutegger
Message: OAK-3388: Inconsistent read in cluster with clock differences

Add tests (currently ignored)

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

View the changeset: 
https://github.com/apache/jackrabbit-oak/compare/225389f81c9f...92d51da02f48

View the full build log and details: 
https://travis-ci.org/apache/jackrabbit-oak/builds/79662305

--
sent by Jukka's Travis notification gateway

jackrabbit-oak build #6391: Fixed

2015-09-10 Thread Travis CI 
Build Update for apache/jackrabbit-oak
-

Build: #6391
Status: Fixed

Duration: 1548 seconds
Commit: 39bf2ef248e7c3c1f3ce581dec7b0de9e7794058 (trunk)
Author: Julian Reschke
Message: OAK-2986: RDBDataSourceFactory: switch to tomcat datasource 
implementation

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

View the changeset: 
https://github.com/apache/jackrabbit-oak/compare/92d51da02f48...39bf2ef248e7

View the full build log and details: 
https://travis-ci.org/apache/jackrabbit-oak/builds/79675179

--
sent by Jukka's Travis notification gateway

Re: System.exit()???? , was: svn commit: r1696202 - in /jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document: ClusterNodeInfo.java DocumentMK.java DocumentNodeStore.j

2015-09-10 Thread Stefan Egli 
On 09/09/15 18:11, "Stefan Egli"  wrote:

>On 09/09/15 18:01, "Stefan Egli"  wrote:
>
>>I think if the observers would all be 'OSGi-ified' then this could be
>>achieved. But currently eg the BackgroundObserver is just a pojo and not
>>an osgi component (thus doesn't support any activate/deactivate method
>>hooks).
>
>.. I take that back - going via OsgiWhiteboard should work as desired - so
>perhaps implementing deactivate/activate methods in the
>(Background)Observer(s) would do the trick .. I'll give it a try ..

ootb this wont work as the BackgroundObserver, as one example, is not an
OSGi component, so wont get any deactivate/activate calls atm. so to
achieve this, it would have to be properly OSGi-ified - something which
sounds like a bigger task and not only limited to this one class - which
means making DocumentNodeStore 'restart capable' sounds like a bigger task
too and the question is indeed if it is worth while ('will it work?') or
if there are alternatives..

which brings me back to the original question as to what should be done in
case of a lease failure - to recap the options left (if System.exit is not
one of them) are:

a) 'go read-only': prevent writes by throwing exceptions from this moment
until eternity

b) 'stop oak': stop the oak-core bundle (prevent writes by throwing
exceptions for those still reaching out for the nodeStore)

c) 'try harder': try to reactivate the lease - continue allowing writes -
and make sure the next backgroundWrite has correctly updated the
'unsavedLastRevisions' (cos others could have done a recover of this node,
so unsavedLastRevisions contains superfluous stuff that must no longer be
written). this would open the door for edge cases ('change of longer time
window with multiple leaders') but perhaps is not entirely impossible...

additionally/independently:

* in all cases the discovery-lite descriptor should expose this lease
failure/partitioning situation - so that anyone can react who would like
to, esp should anyone no longer assume that the local instance is leader
or part of the cluster - and to support that optional Sling Health Check
which still does a System.exit :)

* also, we should probably increase the lease thread's priority to reduce
the likelihood of the lease timing out (same would be true for
discovery.impl's heartbeat thread)


* plus increasing the lease time from 1min to perhaps 5min as the default
would also reduce the number of cases that hit problems dramatically

wdyt?

Cheers,
Stefan

[Oak origin/1.0] Apache Jackrabbit Oak matrix - Build # 412 - Failure

2015-09-10 Thread Apache Jenkins Server 
The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build 
#412)

Status: Failure

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

Changes:
[reschke] OAK-2986: RDBDataSourceFactory: switch to tomcat datasource 
implementation (ported to 1.0)

[reschke] OAK-3391: RDBBlobStore: speed up testBigBlob(), also improve memory 
usage (ported to 1.0)

[reschke] OAK-2986: revert previous changes

 

Test results:
3 tests failed.
FAILED:  org.apache.jackrabbit.oak.jcr.query.SuggestTest.testSuggestSql

Error Message:
expected:<[[{term=in 2015 a red fox is still a fox,weight=1}, {term=in 2015 my 
fox is red, like mike's fox and john's fox,weight=1}]]> but was:<[]>

Stack Trace:
junit.framework.ComparisonFailure: expected:<[[{term=in 2015 a red fox is still 
a fox,weight=1}, {term=in 2015 my fox is red, like mike's fox and john's 
fox,weight=1}]]> but was:<[]>
at junit.framework.Assert.assertEquals(Assert.java:85)
at junit.framework.Assert.assertEquals(Assert.java:91)
at 
org.apache.jackrabbit.oak.jcr.query.SuggestTest.testSuggestSql(SuggestTest.java:50)
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:483)
at junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at 
org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:464)
at junit.framework.TestSuite.runTest(TestSuite.java:243)
at junit.framework.TestSuite.run(TestSuite.java:238)
at 
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
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:483)
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)


FAILED:  org.apache.jackrabbit.oak.jcr.query.SuggestTest.testSuggestXPath

Error Message:
expected:<[[{term=in 2015 a red fox is still a fox,weight=1}, {term=in 2015 my 
fox is red, like mike's fox and john's fox,weight=1}]]> but was:<[]>

Stack Trace:
junit.framework.ComparisonFailure: expected:<[[{term=in 2015 a red fox is still 
a fox,weight=1}, {term=in 2015 my fox is red, like mike's fox and john's 
fox,weight=1}]]> but was:<[]>
at junit.framework.Assert.assertEquals(Assert.java:85)
at junit.framework.Assert.assertEquals(Assert.java:91)
at 
org.apache.jackrabbit.oak.jcr.query.SuggestTest.testSuggestXPath(SuggestTest.java:67)
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:483)
at junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at 
org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:464)
at junit.framework.TestSuite.runTest(TestSuite.java:243)
at junit.framework.TestSuite.run(TestSuite.java:238)
at 
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
at

jackrabbit-oak build #6400: Broken

2015-09-10 Thread Travis CI 
Build Update for apache/jackrabbit-oak
-

Build: #6400
Status: Broken

Duration: 292 seconds
Commit: 3b18bf77c6004a7c12382e85e0472a08373a0288 (trunk)
Author: Amit Jain
Message: OAK-3184: Consistency checker for data/blob store

Reports the number of missing blobs if any and logs the blobId and the node 
path from where referenced.

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

View the changeset: 
https://github.com/apache/jackrabbit-oak/compare/bc125ec096c2...3b18bf77c600

View the full build log and details: 
https://travis-ci.org/apache/jackrabbit-oak/builds/79787943

--
sent by Jukka's Travis notification gateway

Release plan Oak 1.0.20 & 1.2.5

2015-09-10 Thread Amit Jain 
Hi,

I plan to cut the release early morning Monday (14th September).
There are 2 issues unresolved for 1.0.20 [0] and 3 issues for 1.2.5 [1] and
none of them critical which should block the release. I'll reschedule them
for the next releases.

As always if anything comes up which should block the release let me know.

Thanks
Amit

[0]
https://issues.apache.org/jira/browse/OAK-3126?jql=project%20%3D%20OAK%20AND%20fixVersion%20%3D%201.0.20%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC

[1]
https://issues.apache.org/jira/browse/OAK-3176?jql=project%20%3D%20OAK%20AND%20fixVersion%20%3D%201.2.5%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC