Re: [discuss][scalability] oak:asyncConflictResolution

2016-03-21 Thread Michael Dürig
Hi, There is org.apache.jackrabbit.oak.spi.commit.PartialConflictHandler and a couple of its implementations already. Maybe this could be leveraged here by somehow connecting it to the mix-ins you propose. Michael On 21.3.16 9:03 , Stefan Egli wrote: Hi oak-devs, tl.dr: suggestion is to

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

2016-03-21 Thread Apache Jenkins Server
The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build #803) Status: Still Failing Check console output at https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/803/ to view the results. Changes: [chetanm] OAK-4132 - JaasConfigSpiTest fails intermittently

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

2016-03-21 Thread Apache Jenkins Server
The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build #804) Status: Still Failing Check console output at https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/804/ to view the results. Changes: [chetanm] OAK-4132 - JaasConfigSpiTest fails intermittently

[discuss][scalability] oak:asyncConflictResolution

2016-03-21 Thread Stefan Egli
Hi oak-devs, tl.dr: suggestion is to introduce a new property (or mixin) that enables async merge for a subtree in a cluster case while at the same time pre-defines conflict resolution, since conflicts currently prevent trouble-free async merging. In case this has been discussed/suggested

Re: [discuss][scalability] oak:asyncConflictResolution

2016-03-21 Thread Stefan Egli
On 21/03/16 21:03, "Stefan Egli" wrote: >...a third one could again be 'strict' (which would correspond to JCR >semantics >as are the default today) .. actually that would not be possible asynchronously, scratch that.. Cheers, Stefan