[ANNOUNCE] Apache Jackrabbit Oak 1.2.27 released

[Amit Jain]

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

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

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

Release Notes -- Apache Jackrabbit Oak -- Version 1.2.27

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.

Apache Jackrabbit Oak 1.2.27 is a patch release that contains fixes and
improvements over Oak 1.2. Jackrabbit Oak 1.2.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.2.27
-


Bug

[OAK-3930] - Sysview import of single valued mv property creates sv
property
[OAK-4067] - AssertionError thrown for Lucene index with empty suggest
disctionary
[OAK-5949] - XPath: string literals parsed as identifiers
[OAK-6317] - LMSEstimator update amount depending on cost amount
[OAK-6391] - With FastQuerySize, getSize() returns -1 if there are
exactly 21 rows


In addition to the above-mentioned changes, this release contains
all changes included up to the Apache Jackrabbit Oak 1.2.26 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.2.27

[Amit Jain]

Hi,

The vote passes as follows:

+1 Julian Reschke
+1 Davide Giannella
+1 Andrei Dulceanu
+1 Amit Jain

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

Regards
Amit

Re: single node cluster

[Julian Reschke]

On 2017-08-07 18:48, Mostafa Mahdieh wrote:

OK, that was just an example. There are other reasonable scenarios, such as
the database temporarily being unavailable for 2-3 minutes. How can I
recover the connection in that situation.


In that case, you'll have to restart Oak.

Best regards, Julian

Re: single node cluster

[Mostafa Mahdieh]

OK, that was just an example. There are other reasonable scenarios, such as
the database temporarily being unavailable for 2-3 minutes. How can I
recover the connection in that situation.

On Mon, Aug 7, 2017 at 7:37 PM, Julian Reschke 
wrote:

> On 2017-08-07 16:11, Mostafa Mahdieh wrote:
>
>> Consider that for some reason the session lease is expired and cannot be
>> used. For example one scenario is that the the cluster node is removed from
>> the clusterNodes collection (I couldn't find out all scenarios that
>>
>
> That's not supposed to happen at all.
>
> ...
>>
>
> Best regards, Julian
>



-- 
Mostafa Mahdieh

BUILD FAILURE: Jackrabbit Oak - Build # 607 - Still Failing

[Apache Jenkins Server]

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

Status: Still Failing

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

Changes:
[frm] OAK-6507 - Additional tests for the old reclaimer predicate

 

Test results:
1 tests failed.
FAILED:  org.apache.jackrabbit.oak.segment.standby.StandbyTestIT.testSyncLoop

Error Message:
expected: org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { 
... }, root = { ... } }> but was: 
org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... }, 
root = { ... } }>

Stack Trace:
java.lang.AssertionError: expected: 
org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... }, 
root = { ... } }> but was: org.apache.jackrabbit.oak.segment.SegmentNodeState<{ 
checkpoints = { ... }, root = { ... } }>
at 
org.apache.jackrabbit.oak.segment.standby.StandbyTestIT.testSyncLoop(StandbyTestIT.java:126)

BUILD FAILURE: Jackrabbit Oak - Build # 606 - Still Failing

[Apache Jenkins Server]

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

Status: Still Failing

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

Changes:
[mduerig] OAK-6519: Properly handle tail compactions in deduplication caches
Remove FIXMEs as this has been fixed along with OAK-6504 in r1804332

 

Test results:
All tests passed

Re: single node cluster

[Julian Reschke]

On 2017-08-07 16:11, Mostafa Mahdieh wrote:
Consider that for some reason the session lease is expired and cannot be 
used. For example one scenario is that the the cluster node is removed 
from the clusterNodes collection (I couldn't find out all scenarios that 


That's not supposed to happen at all.


...


Best regards, Julian

BUILD FAILURE: Jackrabbit Oak - Build # 605 - Still Failing

[Apache Jenkins Server]

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

Status: Still Failing

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

Changes:
[frm] OAK-6507 - Fix Javadoc for 
org.apache.jackrabbit.oak.segment.file.tar.index.IndexWriter

[mduerig] OAK-6507: Cleanup incorrectly removes base state created by full 
compaction
Simplify segment reclamation logic

[frm] OAK-6518 - Add Javadoc for the 
org.apache.jackrabbit.oak.segment.file.tar.index package

 

Test results:
All tests passed

Re: single node cluster

[Mostafa Mahdieh]

Consider that for some reason the session lease is expired and cannot be
used. For example one scenario is that the the cluster node is removed from
the clusterNodes collection (I couldn't find out all scenarios that this
happens). What happens is that the background lease update thread finds
this out and starts writing out exceptions. If we could somehow detect this
status (e.g. with an observer), and reconnect the connection, I could
recover the application from this state again. Is this possible? I'm using
jackrabbit oak 1.6.1.

Regards

On Mon, Aug 7, 2017 at 6:30 PM, Mostafa Mahdieh  wrote:

> Can anyone please help me on Marcel's comment? Is it already implemented?
> I really need your help.
>
> On Sun, Aug 6, 2017 at 5:18 PM, Mostafa Mahdieh 
> wrote:
>
>> There is a comment here (https://issues.apache.org/jira/browse/OAK-3424)
>> from Marcel Reutegger
>> ,
>> suggesting that:
>>
>> *"I my view we should change the current behavior and prohibit a
>> deployment where two cluster nodes are running with the same working
>> directory and an > automatic clusterId is requested."*
>>
>> It seems that this behavior matches my scenario. How can I configure the
>> oak connection such that this happens?
>>
>> On Sun, Aug 6, 2017 at 4:37 PM, Julian Reschke 
>> wrote:
>>
>>> On 2017-08-06 09:08, Mostafa Mahdieh wrote:
>>>
 Thanks for your suggestions.

 I'm wondering what happens in the worst case if I disable the lease
 check.
 ...

>>>
>>> Repository corruption.
>>>
>>> What you need to find out is why the lease renewal fails, not how to
>>> turn it off. :-)
>>>
>>
>>
>>
>> --
>> Mostafa Mahdieh
>>
>
>
>
> --
> Mostafa Mahdieh
>



-- 
Mostafa Mahdieh

Re: single node cluster

[Julian Reschke]

On 2017-08-07 16:00, Mostafa Mahdieh wrote:

Can anyone please help me on Marcel's comment? Is it already implemented?
I really need your help.
...


See:


Fix Version/s:
1.2.10, 1.3.13, 1.4 



So, yes this has been changed long ago.

Once again: what you should try to find out is why the lease update 
fails on your machine.


Best regards, Julian

Re: single node cluster

[Mostafa Mahdieh]

Can anyone please help me on Marcel's comment? Is it already implemented?
I really need your help.

On Sun, Aug 6, 2017 at 5:18 PM, Mostafa Mahdieh  wrote:

> There is a comment here (https://issues.apache.org/jira/browse/OAK-3424)
> from Marcel Reutegger
> ,
> suggesting that:
>
> *"I my view we should change the current behavior and prohibit a
> deployment where two cluster nodes are running with the same working
> directory and an > automatic clusterId is requested."*
>
> It seems that this behavior matches my scenario. How can I configure the
> oak connection such that this happens?
>
> On Sun, Aug 6, 2017 at 4:37 PM, Julian Reschke 
> wrote:
>
>> On 2017-08-06 09:08, Mostafa Mahdieh wrote:
>>
>>> Thanks for your suggestions.
>>>
>>> I'm wondering what happens in the worst case if I disable the lease
>>> check.
>>> ...
>>>
>>
>> Repository corruption.
>>
>> What you need to find out is why the lease renewal fails, not how to turn
>> it off. :-)
>>
>
>
>
> --
> Mostafa Mahdieh
>



-- 
Mostafa Mahdieh

BUILD FAILURE: Jackrabbit Oak - Build # 604 - Still Failing

[Apache Jenkins Server]

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

Status: Still Failing

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

Changes:
[frm] OAK-6518 - Add tests for serializing the index

 

Test results:
All tests passed

Re: BUILD FAILURE: Jackrabbit Oak - Build # 603 - Still Failing

[Francesco Mari]

Actually the build succeeded, but the job failed due to an exception
thrown by Jenkins.

ERROR: Step ?JIRA: Create issue? aborted due to exception:
java.lang.ClassNotFoundException: com.atlassian.fugue.Effect
at jenkins.util.AntClassLoader.findClassInComponents(AntClassLoader.java:1374)
at jenkins.util.AntClassLoader.findClass(AntClassLoader.java:1327)
at jenkins.util.AntClassLoader.loadClass(AntClassLoader.java:1080)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
Caused: java.lang.NoClassDefFoundError: com/atlassian/fugue/Effect
at 
com.atlassian.httpclient.apache.httpcomponents.DefaultHttpClientFactory.doCreate(DefaultHttpClientFactory.java:68)
at 
com.atlassian.httpclient.apache.httpcomponents.DefaultHttpClientFactory.create(DefaultHttpClientFactory.java:35)
at 
com.atlassian.jira.rest.client.internal.async.AsynchronousHttpClientFactory.createClient(AsynchronousHttpClientFactory.java:63)
at 
com.atlassian.jira.rest.client.internal.async.AsynchronousJiraRestClientFactory.create(AsynchronousJiraRestClientFactory.java:35)
at 
com.atlassian.jira.rest.client.internal.async.AsynchronousJiraRestClientFactory.createWithBasicHttpAuthentication(AsynchronousJiraRestClientFactory.java:42)
at hudson.plugins.jira.JiraSite.createSession(JiraSite.java:280)
at hudson.plugins.jira.JiraSite.getSession(JiraSite.java:255)
at 
hudson.plugins.jira.JiraCreateIssueNotifier.getJiraSession(JiraCreateIssueNotifier.java:285)
at 
hudson.plugins.jira.JiraCreateIssueNotifier.getStatus(JiraCreateIssueNotifier.java:216)
at 
hudson.plugins.jira.JiraCreateIssueNotifier.currentBuildResultSuccess(JiraCreateIssueNotifier.java:387)
at 
hudson.plugins.jira.JiraCreateIssueNotifier.perform(JiraCreateIssueNotifier.java:159)
at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:45)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:735)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:676)
at 
hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.post2(MavenModuleSetBuild.java:1072)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:621)
at hudson.model.Run.execute(Run.java:1760)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:542)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:405)


On Mon, Aug 7, 2017 at 11:30 AM, Apache Jenkins Server
 wrote:
> The Apache Jenkins build system has built Jackrabbit Oak (build #603)
>
> Status: Still Failing
>
> Check console output at https://builds.apache.org/job/Jackrabbit%20Oak/603/ 
> to view the results.
>
> Changes:
> [frm] OAK-6518 - Remove unused member variable
>
>
>
> Test results:
> All tests passed

Re: frozen node modifications

[Marco Piovesana]

Hi Angela,
Thanks for your exhaustive reply. I do understand your point regarding
version management, however I do not totally agree when you say that
"*modification
to existing versions is neither intended nor desirable as it effectively
runs the version storage meaningless*". The final user of course should not
be able to modify the store version information, but talking about an
application that uses Oak as a library (my case), is i believe a different
story.
Let me use an example to explain what I mean: in a later version of the
application we want to extend the information available on a specific
custom type (e.g. the number of words in a text file), we weren't
interested in that value before, but we are now because of some new
features. We want to add that property to our custom type, but we also want
to add it to all its versions, because it's a time-consuming task and we
don't want to calculate it every time we access that type of node.
In this scenario we don't want to modify the meaning of the information
already stored in a version, but we want to extend the information with
something that was already there but was ignored. After the modification
the user can still go back to a previous version and the meaning of it is
preserved.
>From my point of view, blocking the modification of the history even for
the system that uses Oak as a library, makes its usage far more complicated
in terms of upgrade without any true benefit in terms of security.
What do you think?

Marco.

On Fri, Aug 4, 2017 at 9:25 AM, Angela Schreiber 
wrote:

> hi marco
>
> i think your problem is 2-folded:
>
> 1. you need modifications to your content structure to reflect the
> evolution of your app
> 2. you intend to adjust existing versions of the nodes with that node type
>
> As far as 1 is concerned there are different ways to achieve this. from my
> point of view changing an existing node type definition is not the
> preferred way as it ultimately leads to 2. Instead I would recommend you
> any of the following:
>
> a. create mixin types and add them to the nodes if your modifications are
> such that effectively "extends" the existing node type like
> annotations mentioned by chetan. that's exactly how the JCR specification
> defines mixin types
>
> b. if you have breaking changes in your application though, you may
> consider creating new node types and change the primary type of your nodes
> to the new types. if Oak works properly it should automatically adjust the
> child items of the node that gets the primary type changed: adding new
> autocreated items, redefine existing child items according to the new item
> definitions and removing all child items that don't have a applicable item
> definition in the new node type. please file a critical bug in case that
> wouldn't work.
>
> both a. and b. lead to the situation where you don't have to touch the
> version storage. the older versions of your nodes just reflect that state
> of that node at that point in the past and the newer versions reflect the
> updated state. that's how it is intended to work. modification to existing
> versions is neither intended nor desirable as it effectively runs the
> version storage meaningless. it's aim actually is to allow you to go back
> and look at and possible restore an previous state of a given node... if
> those get modified afterwards there is simply no sense at all in creating
> versions.
>
> as far as other comments regarding node types are concerned: i disagree
> with the statement that custom node types are evil and to be avoided. we
> are seeing plenty of issues with unstructured repository content in
> various areas last but not least when it comes to security. my
> recommendation would rather be as follows (short version):
>
> - use existing or custom node types whenever possible
> - use residual property and child item definitions in your custom node
> types for really residual, arbitrary data (e.g. your application doesn't
> know nor care about the attributes a given user will apply and you don't
> have to post-process, secure, observe them
> - use named property and child item definitions for everything that is
> application logic, is controlled/created/observed/processed by the
> application or has a special meaning to it.
>
> while this approach forces you to properly design not only your
> application but also your content model, it helps you explicitly
> establishing a contract for your application.
>
> hope that helps
> angela
>
>
> On 24/07/17 11:19, "Marco Piovesana"  wrote:
>
> >Hi all,
> >I'm working on the upgrade module for my application based on Oak. The
> >module modifies the custom node types to reflect the modifications in the
> >application.
> >Some of those modifications may be adding new properties to custom nodes,
> >and implicitly to all versions of that node.
> >Since frozen nodes are read-only we ended up recreating the node history.
> >This, 

BUILD FAILURE: Jackrabbit Oak - Build # 603 - Still Failing

[Apache Jenkins Server]

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

Status: Still Failing

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

Changes:
[frm] OAK-6518 - Remove unused member variable

 

Test results:
All tests passed

Re: BUILD FAILURE: Jackrabbit Oak - Build # 602 - Still Failing

[Robert Munteanu]

Jenkins was restarted recently and plugins upgraded.

  https://issues.apache.org/jira/browse/INFRA-14798

You might want to file an INFRA issue if this persists.

robert

On Mon, 2017-08-07 at 10:55 +0200, Alex Deparvu wrote:
> looks infra related:
> 
> [INFO] BUILD SUCCESS
> 
> channel stopped
> Archiving artifacts
> ERROR: Step ?JIRA: Create issue? aborted due to exception:
> java.lang.ClassNotFoundException: com.atlassian.fugue.Effect
> at
> jenkins.util.AntClassLoader.findClassInComponents(AntClassLoader.java
> :1374)
> at
> jenkins.util.AntClassLoader.findClass(AntClassLoader.java:1327)
> at
> jenkins.util.AntClassLoader.loadClass(AntClassLoader.java:1080)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> Caused: java.lang.NoClassDefFoundError: com/atlassian/fugue/Effect
> at
> com.atlassian.httpclient.apache.httpcomponents.DefaultHttpClientFacto
> ry.doCreate(DefaultHttpClientFactory.java:68)
> at
> com.atlassian.httpclient.apache.httpcomponents.DefaultHttpClientFacto
> ry.create(DefaultHttpClientFactory.java:35)
> at
> com.atlassian.jira.rest.client.internal.async.AsynchronousHttpClientF
> actory.createClient(AsynchronousHttpClientFactory.java:63)
> at
> com.atlassian.jira.rest.client.internal.async.AsynchronousJiraRestCli
> entFactory.create(AsynchronousJiraRestClientFactory.java:35)
> at
> com.atlassian.jira.rest.client.internal.async.AsynchronousJiraRestCli
> entFactory.createWithBasicHttpAuthentication(AsynchronousJiraRestClie
> ntFactory.java:42)
> at hudson.plugins.jira.JiraSite.createSession(JiraSite.java:280)

Re: BUILD FAILURE: Jackrabbit Oak - Build # 602 - Still Failing

[Alex Deparvu]

looks infra related:

[INFO] BUILD SUCCESS

channel stopped
Archiving artifacts
ERROR: Step ?JIRA: Create issue? aborted due to exception:
java.lang.ClassNotFoundException: com.atlassian.fugue.Effect
at 
jenkins.util.AntClassLoader.findClassInComponents(AntClassLoader.java:1374)
at jenkins.util.AntClassLoader.findClass(AntClassLoader.java:1327)
at jenkins.util.AntClassLoader.loadClass(AntClassLoader.java:1080)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
Caused: java.lang.NoClassDefFoundError: com/atlassian/fugue/Effect
at 
com.atlassian.httpclient.apache.httpcomponents.DefaultHttpClientFactory.doCreate(DefaultHttpClientFactory.java:68)
at 
com.atlassian.httpclient.apache.httpcomponents.DefaultHttpClientFactory.create(DefaultHttpClientFactory.java:35)
at 
com.atlassian.jira.rest.client.internal.async.AsynchronousHttpClientFactory.createClient(AsynchronousHttpClientFactory.java:63)
at 
com.atlassian.jira.rest.client.internal.async.AsynchronousJiraRestClientFactory.create(AsynchronousJiraRestClientFactory.java:35)
at 
com.atlassian.jira.rest.client.internal.async.AsynchronousJiraRestClientFactory.createWithBasicHttpAuthentication(AsynchronousJiraRestClientFactory.java:42)
at hudson.plugins.jira.JiraSite.createSession(JiraSite.java:280)

BUILD FAILURE: Jackrabbit Oak - Build # 602 - Still Failing

[Apache Jenkins Server]

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

Status: Still Failing

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

Changes:
[frm] OAK-6518 - Remove leftover print statement

[frm] OAK-6518 - Add tests for loading transparently different index formats

 

Test results:
All tests passed