BUILD FAILURE: Jackrabbit Oak - Build # 598 - Failure

[Apache Jenkins Server]

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

Status: Failure

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

Changes:
[rombert] OAK-6505 - Ensure mounted node stores don't contain referenceable 
nodes

Add missing license

 

Test results:
1 tests failed.
FAILED:  
org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT.testProxyFlippedStartByte

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

Stack Trace:
java.lang.AssertionError: expected:<{ root = { ... } }> but was:<{ root : { } }>

Re: [VOTE] Release Apache Jackrabbit Oak 1.2.27

[Andrei Dulceanu]

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

Regards,
Andrei

2017-08-02 7:05 GMT+03:00 Amit Jain :

> A candidate for the Jackrabbit Oak 1.2.27 release is available at:
>
> https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.2.27/
>
> The release candidate is a zip archive of the sources in:
>
>
> https://svn.apache.org/repos/asf/jackrabbit/oak/tags/
> jackrabbit-oak-1.2.27/
>
> The SHA1 checksum of the archive is
> 4a5731c0edac11b1376112e4dc382e77f13c490c.
>
> 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.27
> 4a5731c0edac11b1376112e4dc382e77f13c490c
>
> Please vote on releasing this package as Apache Jackrabbit Oak 1.2.27.
> 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.27
> [ ] -1 Do not release this package because...
>
> Thanks
> Amit
>

Re: single node cluster

[Stefan Egli]

Hi Mostafa,

I'd suggest to narrow down why that lease update failed, esp if you have
it reproducible. By default a lease is updated every 10 seconds and is
valid for 2min (and could in theory be changed but that's not recommended
necessarily).

Besides mentioned DB issues, other cases where lease updates failed were
JVMs running low on memory thus doing too long GC-stop-the-worlds.

If you can rule out both, then here's some more ideas to investigate:

a) check for warnings in the form of: "BackgroundLeaseUpdate.execute: time
since last renewClusterIdLease() call longer than expected" to see if the
lease update became slow already before it finally expired. Perhaps that
gives some clues already.

b) enable trace logging for
'org.apache.jackrabbit.oak.plugins.document.ClusterNodeInfo' to see all
details about lease updates happening (or not).

c) analyse thread dumps to rule out blocked lease update thread

Cheers,
Stefan

On 01/08/17 15:45, "Mostafa Mahdieh"  wrote:

>Hi,
>
>I'm using jackrabbit oak as the content repository of a document
>management
>system product. Currently there is no need to scale out, therefore I'm
>using jackrabbit oak in a single node environment. However, I'm
>experiencing issues related to clustering and lease time, such as the
>following exception which is appearing all over my tomcat logs:
>
>WARN: Background operation failed:
>org.apache.jackrabbit.oak.plugins.document.DocumentStoreException: This
>oak
>instance failed to update the lease in time and can therefore no longer
>access this DocumentNodeStore.
>
>After some research, It seems that there is no way to use jackrabbit oak
>forcing it to use a single node and not having any concerns related to
>clustering.
>
>Am I using the right tool? I thought maybe jackrabbit 2 might be better
>for
>my current use case, however oak seemed as the future of jackrabbit, and
>attracted me (adding scalability is also in my future vision). Do you
>suggest oak for my usecase or jackrabbit 2? How can I adapt oak for a
>single node environment without getting issues regarding lease time and
>clustering?
>
>Best Regards
>-- 
>Mostafa Mahdieh

Re: [VOTE] Release Apache Jackrabbit Oak 1.2.27

[Davide Giannella]

+1
D.

Review current setup of CommitHooks

[Chetan Mehrotra]

Hi Team,

In a default Oak setup currently following CommitHooks are configured
to be run for each commit. Most of these hooks would perform separate
diff.

Would it make sense to review the current setup and see if some of
these hooks can be combined to avoid repetitive diff

 - CompositeHook
   - ResetCommitAttributeHook
   - CompositeHook
 - VersionHook
   - VersionEditorProvider
   - VersionableCollector
   - OrphanedVersionCleaner
 - ConflictHook
 - EditorHook
   - ItemSaveValidatorProvider
   - NameValidatorProvider
   - NamespaceEditorProvider
   - TypeEditorProvider
   - ConflictValidatorProvider
   - ChangeCollectorProvider
 - RepoStateCheckHook
 - EditorHook
   - IndexUpdateProvider
   - VersionablePathHook
   - EditorHook
 - PermissionStoreValidatorProvider
 - PermissionValidatorProvider
 - AccessControlValidatorProvider
 - PrivilegeValidatorProvider
 - UserValidatorProvider
 - CacheValidatorProvider
 - TokenValidatorProvider
   - PermissionHook
   - JcrAllCommitHook


Chetan Mehrotra

Re: [VOTE] Release Apache Jackrabbit Oak 1.2.27

[Julian Reschke]

On 2017-08-02 06:05, Amit Jain wrote:

...


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

Best regards, Julian

Re: frozen node modifications

[Chetan Mehrotra]

> it is preferable to not create custom node types, because typically the 
> business requirements are not understood enough

Nodetypes are helpful as "content annotation" and allow repository to
provide better performance by relying on them for indexing,
observation, bundling etc. So may be better to say avoid nodetypes
with restrictive definition. However do create new nodetype (or
mixins) to mark the domain objects in your application content.

Chetan Mehrotra

Re: frozen node modifications

[Marco Piovesana]

Hi Michael,
thanks for your comment. We started our project using node types but yes,
recently we also thought about moving to a "schemaless" structure because
of the struggling we had when trying to modify the data structure. However
I still don't quite understand how can this solve my problem with versioned
nodes. I mean: if a node is unstructured i can add or remove any property
from node without any problem, but i can't do that to its versions right?
If i need to apply a calculated value to each version, so that i don't have
to make that calculation any time i retrieve that version information, how
can i do that?

Marco.

On Tue, Aug 1, 2017 at 9:40 PM, Michael Marth 
wrote:

> Hi Marco,
>
> A better (or at least alternative) way to approach this, is to avoid the
> problem in the first place :) In my experience it is preferable to not
> create custom node types, because typically the business requirements are
> not understood enough - which means you later want to add things and then
> end up in the situation you just described. You could simply use
> unstructured nodes and have one String property describe the “type”.
> A good reason to have node types is if you require the repository to
> enforce integrity (as opposed to the application doing that).
>
> The unstructured approach is equivalent to the term “schemaless” as it
> became popular a couple of years ago. Obvs there are pros and cons, so pls
> take the above as a reflection of what has worked well for me (but your
> circimstances might be different)
>
> Cheers
> Michael
>
>
>
> 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, however, makes the system more complex because we have
> >weak-references between those nodes and recreating the history means new
> >ids for the versions.
> >There's really no way to modify the frozen node? There's a better way to
> >solve this problem?
> >
> >Marco.
>



-- 

marco piovesanA
Enterprise Application



*ESTECO* | EXPLORE DESIGN PERFECTION

AREA Science Park, Padriciano 99 - 34149 Trieste - ITALY
Phone: +39 040 3755548 - Fax: +39 040 3755549
[Website]  | [Twitter]
 | [Facebook]
 | [Linkedin]

Pursuant to Legislative Decree No. 196/2003, you are hereby informed that
this message contains confidential information intended only for the use of
the addressee. If you are not the addressee, and have received this message
by mistake, please delete it and immediately notify us. You may not copy or
disseminate this message to anyone. Thank you. Please consider the
environment before printing this email.