[VOTE] Release Apache Jackrabbit Oak 1.0.21

2015-09-17 Thread Marcel Reutegger 
A candidate for the Jackrabbit Oak 1.0.21 release is available at:

https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.0.21/

The release candidate is a zip archive of the sources in:

https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.0.21/

The SHA1 checksum of the archive is b3d1d3d0f945715dcba4982a06d29932bd44e760.

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.0.21 b3d1d3d0f945715dcba4982a06d29932bd44e760

Please vote on releasing this package as Apache Jackrabbit Oak 1.0.21.
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.0.21
[ ] -1 Do not release this package because...

Regards
 Marcel

Re: [VOTE] Release Apache Jackrabbit Oak 1.2.6

2015-09-17 Thread Amit Jain 
On Thu, Sep 17, 2015 at 3:12 PM, Marcel Reutegger 
wrote:

> Please vote on releasing this package as Apache Jackrabbit Oak 1.2.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. All checks Ok.

Thanks
Amit

Re: [VOTE] Release Apache Jackrabbit Oak 1.0.21

2015-09-17 Thread Julian Reschke 

On 2015-09-17 11:09, Marcel Reutegger wrote:

...


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

Best regards, Julian

jackrabbit-oak build #6446: Passed

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

Build: #6446
Status: Passed

Duration: 1721 seconds
Commit: 337afd58b0986dfb7d16c085dea2f3256cfe55ba (jackrabbit-oak-1.2.6)
Author: Marcel Reutegger
Message: [maven-release-plugin]  copy for tag jackrabbit-oak-1.2.6

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

View the changeset: https://github.com/apache/jackrabbit-oak/commit/337afd58b098

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

--
sent by Jukka's Travis notification gateway

Re: [VOTE] Release Apache Jackrabbit Oak 1.0.21

2015-09-17 Thread Julian Sedding 
On Thu, Sep 17, 2015 at 11:09 AM, Marcel Reutegger  wrote:

> Please vote on releasing this package as Apache Jackrabbit Oak 1.0.21.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.

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

Regards
Julian

Re: [VOTE] Release Apache Jackrabbit Oak 1.2.6

2015-09-17 Thread Julian Reschke 

On 2015-09-17 11:42, Marcel Reutegger wrote:

...


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

Best regards, Julian

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

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

Status: Failure

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

Changes:
[chetanm] OAK-3395 - RevisionGC fails for JCR paths having line feed characters

 

Test results:
45 tests failed.
FAILED:  
org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditorTest.testIndexedProperties

Error Message:
No such core: oak

Stack Trace:
org.apache.solr.common.SolrException: No such core: oak
at 
org.apache.solr.client.solrj.embedded.EmbeddedSolrServer.request(EmbeddedSolrServer.java:112)
at 
org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:118)
at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:116)
at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:102)
at 
org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditor.leave(SolrIndexEditor.java:131)
at 
org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditorTest.testIndexedProperties(SolrIndexEditorTest.java:63)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
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.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.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:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
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.plugins.index.solr.index.SolrIndexEditorTest.testIgnoredPropertiesNotIndexed

Error Message:
No such core: oak

Stack Trace:
org.apache.solr.common.SolrException: No such core: oak
at 
org.apache.solr.client.solrj.embedded.EmbeddedSolrServer.request(EmbeddedSolrServer.java:112)
at 
org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:118)
at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:116)
at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:102)
at 
org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditor.leave(SolrIndexEditor.java:131)
at 
org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditorTest.testIgnoredPropertiesNotIndexed(SolrIndexEditorTest.java:95)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at

[VOTE] Release Apache Jackrabbit Oak 1.2.6

2015-09-17 Thread Marcel Reutegger 
A candidate for the Jackrabbit Oak 1.2.6 release is available at:

https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.2.6/

The release candidate is a zip archive of the sources in:

https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.2.6/

The SHA1 checksum of the archive is eba15954651c06026c10a196cc0fd5915b9e9041.

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.2.6 eba15954651c06026c10a196cc0fd5915b9e9041

Please vote on releasing this package as Apache Jackrabbit Oak 1.2.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.2.6
[ ] -1 Do not release this package because...

Regards
 Marcel

Re: [VOTE] Release Apache Jackrabbit Oak 1.0.21

2015-09-17 Thread Amit Jain 
On Thu, Sep 17, 2015 at 2:39 PM, Marcel Reutegger 
wrote:

> Please vote on releasing this package as Apache Jackrabbit Oak 1.0.21.
> 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. All checks Ok.

Thanks
Amit

Re: [VOTE] Release Apache Jackrabbit Oak 1.2.6

2015-09-17 Thread Julian Sedding 
On Thu, Sep 17, 2015 at 11:42 AM, Marcel Reutegger  wrote:

> Please vote on releasing this package as Apache Jackrabbit Oak 1.2.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.

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

Regards
Julian

issues ClusterNodeInfo (not) picking an existing entry on startup

2015-09-17 Thread Julian Reschke 

Hi there,

when the DocumentNodeStore starts up, it attempts to find an entry that 
matches the current instance (which is defined by something based on 
network interface address and the current working directory).


However, an additional check is done when the cluster lease end time 
hasn't been reached, in which case the entry is skipped (assuming it 
belongs to a different instance), and the scan continues. When no other 
entry is found, a new one is created.


So why would we *ever* consider instances with matching instance 
information to be different? As far as I can tell the answer is: for 
unit testing.


But...

With the current assignment very weird things can happen, and I believe 
I see exactly this happening in a customer problem I'm investigating. 
The sequence is:


1) First system startup, cluster node id 1 is assigned

2) System crashes or was crashed

3) System restarts within the lease time (120s?), a new cluster node id 
is assigned


4) System shuts down, and gets restarted after a longer interval: 
cluster id 1 is used again, and system starts MissingLastRevRecovery, 
despite the previous shutdown having been clean


So what we see is that the system starts up with varying cluster node 
ids, and recovery processes may run with no correlation to what happened 
before.


Proposal:

a) Make ClusterNodeInfo.createInstance() much more verbose, so that the 
default system log contains sufficient information to understand why a 
certain cluster node id was picked.


b) Drop the logic that skips entries with non-expired leases, so that we 
get a one-to-one relation between instance ids and cluster node ids. For 
the unit tests that currently rely on this logic, switch to APIs where 
the test setup picks the cluster node id.


Feedback appreciated,

Julian