Intent to backport OAK-8071

Hi, I intent to backport the changes we did for OAK-8071: http://svn.apache.org/viewvc?rev=1854515=rev This adds some warning logging for specific cases where a commit is blocked for a long time (configurable via -Doak.segmentNodeStore.commitWaitWarnMillis) on a commit that is already in

Intent to backport OAK-8069

Hi, I would like to backport OAK-8069 to Oak 1.10 and 1.8. This introduced some logging to catch cases where many direct child nodes are added to a node transiently. Risk is relatively low as there are no functional changes, just logging. Michael

Re: Intent to backport OAK-8033 to Oak 1.10, 1.8 and 1.6

Merged into 1.6 at http://svn.apache.org/viewvc?rev=1853814=revMerged into 1.8 at http://svn.apache.org/viewvc?rev=1853813=revMerged into 1.10 at http://svn.apache.org/viewvc?rev=1853812=revMichael On Fri, 15 Feb 2019 at 09:58, Michael Dürig wrote: > > > Hi, > > In intend to backp

Intent to backport OAK-8033 to Oak 1.10, 1.8 and 1.6

Hi, In intend to backport OAK-8033 [1] to the branches mentioned in the subject. This fixes a regression introduced with OAK-7867 [2] that could cause data loss after running full compaction. The risk is relatively low as the fix is quite simple and has shown to resolve concessional test

Re: svn commit: r1851789 - in /jackrabbit/oak/trunk: oak-run/src/main/java/org/apache/jackrabbit/oak/run/ oak-segment-azure/src/main/java/org/apache/jackrabbit/oak/segment/azure/tool/ oak-segment-azur

Hi, I think the quoted implementation of migrateSegments is overly complex. Since we apparently need / want to keep the order of the segments in the archive across migration there is no way to parallelize writing the segments. However, this took me a while to figure out looking at the

Intent to backport OAK-7867 to Oak 1.8 and 1.6

Hi, I intend to backport OAK-7867 to Oak 1.8 and 1.6. This fixes an issue that can cause sever data loss with the segment node store. There is a medium to high risk with this backport as it touches some of the core parts of the segment node store. To mitigate the risk we ran a 14 days longevity

Intend to backport OAK-7838

Hi, I intend to backport https://issues.apache.org/jira/browse/OAK-7838. This fixes an unclosed executor (by removing it). The fix only affects monitoring code and is thus rather low risk. Michael

Intend to backport OAK-7837

Hi, I intend to backport https://issues.apache.org/jira/browse/OAK-7837. This is a simple fix in tooling (oak-run check) preventing it from crash under certain circumstances. The fix is simple and the risk is low. Michael

Intend to backport OAK-7853

Hi, I intend to backport https://issues.apache.org/jira/browse/OAK-7853. This fixes an issue that could cause data loss under rare circumstances. The fix touches a critical core code of the segment store. However, changes are confined to code paths that are rarely executed and very

Jira component for oak-segmemt-azure

Hi, With more work going into the Azure Segment Store, should we start tracking this via a dedicated Jira component? If there are no objections I suggest to add a segment-azure component. Michael

New Jackrabbit Committer: Woonsan Ko

Hi, Please welcome Woonsan Ko as a new committer and PMC member of the Apache Jackrabbit project. The Jackrabbit PMC recently decided to offer Woonsan committership based on his contributions. I'm happy to announce that he accepted the offer and that all the related administrative work has now

New Jackrabbit committer: Matt Ryan

Hi, Please welcome Matt Ryan as a new committer and PMC member of the Apache Jackrabbit project. The Jackrabbit PMC recently decided to offer Matt committership based on his contributions. I'm happy to announce that he accepted the offer and that all the related administrative work has now been

Re: Intent to backport OAK-6890

On 05.09.18 11:23, Francesco Mari wrote: I intend to backport OAK-6890 to the 1.6 branch. The keeps some background threads alive in the face of unexpected failures. All of these threads are critical for the correctness of the Segment Store. +1 Michael

Re: Intent to backport OAK-7721

On 04.09.18 11:14, Francesco Mari wrote: I intend to backport OAK-7721 to the 1.8 and 1.6 branches. The fix prevents the segment buffers from being corrupted when too big records are persisted. The corruption is only detected when the buffer is flushed to disk, when it's too late to detect

Intent to backport OAK-6648

Hi, I would like to backport OAK-6648 to Oak 1.6. This fixes an issue with offline revision cleanup causing tar files to not being removed under some circumstances. The risk is low as it only contains minor changes to code that is executed when the repository is shut down. Michael

Re: [DISCUSS] Enabling CI for Oak cloud-based features

I wonder how other communities address such issues. I.e. Apache jclouds would need to be tested against a rather broad variety of different cloud vendors. Maybe its worth to do some research on their approach. Michael On 31.07.18 10:01, Amit Jain wrote: There's one provided by Adobe as

Re: [VOTE] Release Apache Jackrabbit Oak 1.9.0

On 23.04.18 14:53, Davide Giannella wrote:     [X] +1 Release this package as Apache Jackrabbit Oak 1.9.0 Michael

Re: Azure Segment Store

> How does it perform compared to TarMK > a) when the entire repo doesn't fit into RAM allocated to the container ? > b) when the working set doesn't fit into RAM allocated to the container ? I think this is some of the things we need to find out along the way. Currently my thinking is to move

Re: [SegmentStore] Blobs under 16 KB always inlined in tar files?

On 15.02.18 22:06, Alexander Klimetschek wrote: I would agree on first sight. However, there might be good reasons for the current design and these concerns would not be true in practice. The same setting is essentially used for both STRING and BINARY properties - maybe it makes a lot of

Re: Intent to backport OAK-6373 to 1.8

+1. The fix only affects tooling code. With this change we increase coverage for detecting corruptions we previously missed. Michael On 31.01.18 12:23, Andrei Dulceanu wrote: Hi All, I intend to backport OAK-6373 to 1.8 branch. This issue enhances the behaviour of oak-run check command to

Re: Fwd: dump content of segment tar files

Hi, Unfortunately there is currently no OOTB tooling apart from oak-run check followed by a manual roll back to repair a repository. What where you doing with oak-run while the disk run full? Michael On 30.01.18 11:14, Torgeir Veimo wrote: Is there a tool to inspect the content of segment

Intend to backport OAK-7132 to 1.8

Hi, I intent to backport OAK-7132 to Oak 1.8. This is a fix to a critical error in the TarMK persistence layer that could lead to data loss. The fix was evaluated in trunk through an internal (to Adobe) longevity test for 5 day. Michael

Re: Oak 1.8.1 release plan

I'm still working on OAK-7132, which is a blocker for 1.8.1. A fix is currently in longevity testing. Looking good so far. If it survives the weekend I'll merge it into 1.8 first thing Mon. morning. Will keep you posted. Michael On 18.01.18 11:12, Davide Giannella wrote: Hello team, I'm

Re: Intent to backport OAK-7157 to 1.8

+1. This is also relevant for OAK-7132 in the broader scope. Michael On 16.01.18 16:45, Francesco Mari wrote: I intend to backport OAK-7157 to the 1.8 branch. The fix implements an optimisation for cold standby instances. With the fix in place, standby instances only retained the latest

Re: Intent to backport OAK-7158 to 1.8

+1. This is in the broader sense part of OAK-7132. Michael On 16.01.18 13:53, Francesco Mari wrote: I intend to backport OAK-7158 to the 1.8 branch. The fix is about disallowing users from changing the number of generations retained by the FileStore. Setting the number of retained generations

Re: [VOTE] Release Apache Jackrabbit Oak 1.8.0

On 09.01.18 12:53, Davide Giannella wrote: [X] +1 Release this package as Apache Jackrabbit Oak 1.8.0 Michael

Re: [VOTE] Release Apache Jackrabbit Oak 1.7.14

On 20.12.17 18:46, Davide Giannella wrote: [X] +1 Release this package as Apache Jackrabbit Oak 1.7.14 Michael

Re: Build failure due to out of heap in oak-solr

On 15.12.17 12:41, Robert Munteanu wrote: On Fri, 2017-12-15 at 15:18 +0530, Chetan Mehrotra wrote: Caused by: java.lang.OutOfMemoryError: Java heap space The build is failing due to OOM in oak-solr-core https://builds.apache.org/job/Jackrabbit%20Oak/1090/ FWIW, the windows build does not

Re: Experimental build for Oak on Windows

Thanks Robert for taking this up again. Almost exactly a year ago I spent some time in understanding Jenkins issues [1]. This showed that back then infrastructure problems prevailed by large. Only a few issues reported by Jenkins were actual regressions. I would be interested to see whether

Re: identify abandoned oak modules

Not exactly retiring but what about moving oak-pojosr under oak-examples? Michael On 21.11.17 16:53, Alex Deparvu wrote: I think we can also add 'oak-http' to the list. alex On Tue, Nov 21, 2017 at 4:04 PM, Francesco Mari wrote: I'm in favour of retiring

Re: Intent to backport OAK-6784

On 21.11.17 15:37, Francesco Mari wrote: I would like to backport OAK-6784 to 1.6. The Compact tool backend swallows the exception thrown during its execution. The issue is about propagating the exception forward, so that the tool frontend might handle them properly. +1 Michael

Intent to backport to 1.6 OAK-6931

https://issues.apache.org/jira/browse/OAK-6931 This fixes an issue in the offline compaction tool, which prevents the cache size to be set via the command line. Michael

Re: Oak 1.7.11 release plan

I made https://issues.apache.org/jira/browse/OAK-6894 a blocker. It has the potential to break the offline compaction tool causing data loss. We need to have a better understanding of the risks before we go forward. I'll keep you posted. Michael On 02.11.17 11:43, Davide Giannella wrote:

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

Hi, Recent failures seem to be caused by the JIRA plugin. See https://issues.apache.org/jira/browse/INFRA-15290# I disabled that plugin for now: https://builds.apache.org/job/Jackrabbit%20Oak/jobConfigHistory/showDiffFiles?timestamp1=2017-10-01_03-35-21=2017-10-16_11-54-27 Michael On

Re: Oak Session save behavior

Hi, As Chetan mentioned JCR sessions are synchronous. However IIUC, you are wrapping operations on sessions into futures in your code. So I would guess you would have to use the future API to determine the state of the wrapped operation (e.g. via a completion handler). Michael On 26.09.17

Re: Access to NodeStore instance within benchmark

I tend to agree with Davide. Especially since the use case is for benchmarking only. Isn't there an alternative way where the node store could be exposed via the the benchmark's fixture? Michael On 25.09.17 11:00, Davide Giannella wrote: On 25/09/2017 07:05, Chetan Mehrotra wrote: One way

Re: chroot-like content segregation?

Hi, I agree that on the NodeStore level this is probably easy enough. However mind you that the JCR semantics demand for *a lot* of shared global state, all of which is implement on top of the NodeStore. It is this global state that complicated the composite store implementation and in fact

Re: Segment Store GC failing on Windows

Hi, This is a know issue for some Windows environments. A workaround is to set tarmk.mode=32 in the configuration of the SegmentNodeStoreService. See also the "Tar storage" section at https://helpx.adobe.com/experience-manager/kb/performance-tuning-tips.html. Michael

Intended to backport OAK-6110 to 1.6

Hi, I intend to backport OAK-6110 to Oak 1.6. See OAK-6642 for a patch. The fix is very simple and showed big performance and scalability improvements compacting repositories with nodes having many siblings. Michael

Re: OAK-6575 - A word of caution

See https://github.com/mduerig/jackrabbit-oak/commit/2709c097b01 a006784b7011135efcbbe3ce1ba88 for a *really* quickly hacked together and entirely untested POC. But it should get the idea across though. Thank you. That makes sense. I think it only needs the java/org/apache/jackrabbit/

Re: OAK-6575 - A word of caution

On 06.09.17 23:08, Michael Dürig wrote: Hi, On 05.09.17 14:09, Ian Boston wrote: Repeating the comment to on OAK-6575 here for further discussion. 2 new Patches exploring both options. I would actually prefer the original patch (https://github.com/ieb/jackrabbit-oak/compare/trunk

Re: SegmentNodeStore documentation

On 06.09.17 22:27, Jörg Hoh wrote: Hi Oak-Devs I wonder about the documentation at http://jackrabbit.apache.org/oak/docs/nodestore/segmentmk.html In the section "Node records" it's stated: "A node that contains more than N properties or M child nodes (exact size TBD, M ~ 1k) is stored

Re: OAK-6575 - A word of caution

Hi, On 05.09.17 14:09, Ian Boston wrote: Repeating the comment to on OAK-6575 here for further discussion. 2 new Patches exploring both options. I would actually prefer the original patch (https://github.com/ieb/jackrabbit-oak/compare/trunk...ieb:OAK-6575?expand=1) in most parts. However I

Re: OAK-6575 - A word of caution

On 06.09.17 13:59, Ian Boston wrote: package for each new conversion Oak supported, greatly simplifying dependencies downstream, especially where the source and target classes already exist. If a concrete method is used, the package will need to be versioned everytime. I suspect OSGi rules

Re: OAK-6575 - A word of caution

On 04.09.17 16:57, Ian Boston wrote: Hi, IIUC There are 2 patterns: 1 Emitting a short lived signed URL as per the AWS CloudFront recommended method of serving private content. I think this is an area where your patch made a lot of progress. From your description my initial concerns in

Re: OAK-6575 - A word of caution

Hi, I think the discussion did move forward between the various issues but this might have been obfuscated because several topics where discussed at the same time. To me the two main topics touched exposure of an URI to binaries and an API to expose this from Oak. In the meanwhile I just

Re: OAK-6575 - A word of caution

On 04.09.17 16:18, Bertrand Delacretaz wrote: On Mon, Sep 4, 2017 at 3:44 PM, Ian Boston wrote: ...I feel that Oak is weaker without the ability to offload bulk data streaming to infrastructure designed for that purpose FWIW as an Oak user I share that feeling, IMO the

Re: reading the checkpoint metadata in the SegmentMK

. I'll follow up with an issue/discussion regarding the checkpoint properties. Michael Regards, Tomek -- Tomek Rękawek | Adobe Research | www.adobe.com reka...@adobe.com On 29 Aug 2017, at 08:56, Michael Dürig<mdue...@apache.org> wrote: Hi, L

Re: reading the checkpoint metadata in the SegmentMK

Hi, I would prefer to not make the org.apache.jackrabbit.oak.segment.SegmentNodeStore#getCheckpoints method public as this would bind us to a contract how to store the meta data. Maybe we could add some API that is agnostic to the storage format? Michael On 28.08.17 12:41, Tomek Rekawek

Fwd: reading the checkpoint metadata in the SegmentMK

Forwarding from jackrabbit-dev. As the Oak list is probably the right place to discuss this. Forwarded Message Subject: reading the checkpoint metadata in the SegmentMK Date: Mon, 28 Aug 2017 10:41:24 + From: Tomek Rekawek Reply-To:

Re: OAK-6575 - Provide a secure external URL to a DataStore binary.

On 24.08.17 15:33, Chetan Mehrotra wrote: Inside Oak it would have its own version of an AdapterManager, AdapterFactory. the DataStore would implement an AdapterFactory and register it with the AdapterManager. The OakConversionService implementation would then use the AdapterManager to perform

Re: OAK-6575 - Provide a secure external URL to a DataStore binary.

f being piggy backed on the secure URL discussion. Michael Chetan Mehrotra On Thu, Aug 24, 2017 at 5:41 AM, Michael Dürig <mdue...@apache.org> wrote: On 24.08.17 14:32, Chetan Mehrotra wrote: Why not just add a method Blob.getSignedURI()? This would be inline with getReferen

Re: OAK-6575 - Provide a secure external URL to a DataStore binary.

uture extensions." Michael Chetan Mehrotra [1] https://wiki.apache.org/jackrabbit/JCR%20Binary%20Usecase#UC4 On Thu, Aug 24, 2017 at 5:25 AM, Michael Dürig <mdue...@apache.org> wrote: On 24.08.17 13:38, Chetan Mehrotra wrote: various layers involved. The bit I don't understand is h

Re: OAK-6575 - Provide a secure external URL to a DataStore binary.

On 24.08.17 13:54, Ian Boston wrote: You could just jump to URI uri = adapterManager.getAdapter(binary, URI.class); No API changes to any existing Oak APIs, +1, I think this is what we should aim for. Michael

Re: OAK-6575 - Provide a secure external URL to a DataStore binary.

I understand the difficulties involved with implementing this due to the various layers involved. The bit I don't understand is how the adaptable pattern would make those go away. To me that pattern is just another way to implement this but it would also need to deal with all those layers.

Re: OAK-6575 - Provide a secure external URL to a DataStore binary.

On 24.08.17 09:27, Ian Boston wrote: On 24 August 2017 at 08:18, Michael Dürig <mdue...@apache.org> wrote: URI uri = ((OakValueFactory) valueFactory).getSignedURI(binProp); +1 One point Users in Sling dont know abou Oak, they know about JCR. URI uri = ((OakValueFactory) valueF

Re: OAK-6575 - Provide a secure external URL to a DataStore binary.

On 24.08.17 09:06, Chetan Mehrotra wrote: I think the discussion about the adapter pattern is orthogonal to the binary For me its tied to how you are going to implement this support. Adaptable patterns is one way based on my current understand of Oak design. At level of

Re: OAK-6575 - Provide a secure external URL to a DataStore binary.

Hi, I think the discussion about the adapter pattern is orthogonal to the binary issue. According to YAGNI we should stick with instance of checks unless we already have a somewhat clear picture of future extensions. Michael On 24.08.17 07:28, Chetan Mehrotra wrote: Based on the feedback

Re: Backporting cold standby chunking to 1.6.x?

Same here. Let's wait for a concrete case. Hopefully until then that feature already had a bit of "real world" coverage. Michael On 21.08.17 09:12, Francesco Mari wrote: I wouldn't backport unless strictly necessary. In my opinion, this is not a bug but an improvement. On Mon, Aug 21,

Re: Percentile implementation

On 04.07.17 11:15, Francesco Mari wrote: 2017-07-04 10:52 GMT+02:00 Andrei Dulceanu : Now my question is this: do we have a simple percentile implementation in Oak (I didn't find one)? I'm not aware of a percentile implementation in Oak. If not, would you

Re: [DiSCUSS] - highly vs rarely used data

Hi, I agree we should have a better look at access patterns, not only for indexing. I recently came across a repository with about 65% of its content in the version store. That content is pretty much archived and never accessed. Yet it fragments the index and thus impacts general access

Re: copy on write node store

On 30.05.17 09:34, Tomek Rekawek wrote: Hello Michael, thanks for the reply! On 30 May 2017, at 09:18, Michael Dürig <mdue...@apache.org> wrote: AFAIU from your mail and from looking at the patch this is about a node store implementation that can be rolled back to a previous

Re: copy on write node store

Hi Tomek, AFAIU from your mail and from looking at the patch this is about a node store implementation that can be rolled back to a previous state. If this is the case, a simpler way to achieve this might be to use the TarMK and and add functionality for rolling it back. The cleanest way

Re: svn commit: r1796624 - /jackrabbit/oak/trunk/oak-store-spi/src/main/java/org/apache/jackrabbit/oak/spi/state/AbstractNodeState.java

On 30.05.17 07:00, Chetan Mehrotra wrote: On Mon, May 29, 2017 at 6:50 PM, wrote: +private static final int CHILDREN_CAP = getInteger("children.cap", 100); Better to have system property prefix with 'oak' i.e. 'oak.children.cap' Agreed. Done at

Re: Oakathon: Oak Hackathon

The page is marked as ImmutablePage to me so I can't edit it. Username is RobertMunteanu. I added you contributor: https://wiki.apache.org/jackrabbit/ContributorsGroup. Should work now. Michael

Re: [VOTE] Release Apache Jackrabbit Oak 1.7.0

On 24.05.17 15:35, Davide Giannella wrote: [X] +1 Release this package as Apache Jackrabbit Oak 1.7.0 Michael

Oakathon: Oak Hackathon

Hi, We are going to hold an Oak Hackathon in Basel, Switzerland from August 21st to August 25th. This is a developers workshop with the goal to advance the overall state of Oak by fixing bugs, implementing new features or coming up with interesting POCs. Please indicate your attendance on

Re: Intent to backport to 1.6 and 1.4: OAK-5741

Back to the list, which I unintentionally dropped. On 22.05.17 10:19, Julian Reschke wrote: On 2017-05-22 10:16, Michael Dürig wrote: AFIK this is a new feature, why are we backporting this? Michael Because OAK-5704 relies on it. But why should we backport that on? It is a minor

Backport OAK-6208 to 1.6

Hi, I would like to back port OAK-6208 [1] to the 1.6 branch. Before 1.6 oak-run compact had a way to explicitly enable/disable memory mapping of the tar files. Somehow this got lost in oak-segment-tar and one has to resort to nasty workarounds like setting -Dsun.arch.data.model=32 on the

Re: Enforcing minimal test coverage

On 11.05.17 12:05, Angela Schreiber wrote: - oak-segment-tar: 0.65 I guess this only includes the coverage from running unit tests and does not include integration tests. For segment tar the figures are actually much better with the latter, which is (another) indicator that segment tar

Re: [ops] Unify NodeStore/DataStore configurations by using nstab

GMT+02:00 Michael Dürig <mdue...@apache.org>: Hi Arek, I agree that Oak would benefit from being simpler and more uniform to configure and run. The current approach with the Oak and Jcr builder classes has somehow outgrown its initial purpose. I am somewhat sceptic about (st

Re: Merge policy for the 1.6 branch

On 10.04.17 17:59, Michael Dürig wrote: Hi, I think we can get a consensus on the following statement: "Back ports bear a certain risk of introducing regressions to otherwise stable branches. Each back ported change should be carefully evaluated for its potential impact, risk and pos

Dangling Java 8 Maven profile!?

Hi, After OAK-5664 moved us to Java 8 I believe we can remove the java8 Maven profile as well [1]. Michael [1] https://github.com/apache/jackrabbit-oak/blob/trunk/oak-parent/pom.xml#L960

Re: [m12] Effort to Improve Modularisation of Oak

On 19.04.17 16:26, Angela Schreiber wrote: I'm actually reluctant about 1) and 2) as renaming established modules have quite a ripple effect. As with 3) we already have sub-modules in one place we should probably start a discussion of switching to a hierarchical module structure. makes sense

Re: svn commit: r1791885 - /jackrabbit/oak/trunk/oak-examples/webapp/pom.xml

On 19.04.17 12:32, Chetan Mehrotra wrote: On Wed, Apr 19, 2017 at 2:49 PM, wrote: -2.5 +3.0.0 May be we specify the version in parent pluginManagement and not have explicit version in any child pom +1 Michael Chetan Mehrotra

Re: [m12] Effort to Improve Modularisation of Oak

structure. To address 1) and 2) once the main modularisation effort stabilised. Michael Kind regards Angela On 18/04/17 08:57, "Michael Dürig" <mdue...@apache.org> wrote: On 13.04.17 15:52, Angela Schreiber wrote: {quote} I would suggest to go with a naming scheme t

Re: [m12n] A new home for ApproximateCounter, NodeUtil and TreeUtil?

AFAIK ApproximateCounter was intended to be general purpose. So moving it close to indexing would not be the right thing. We probably need to involve Thomas here to provide his perspective. But then, I think this (and as well as the considerations around NodeUtil and TreeUtil) should be

Re: [m12] Effort to Improve Modularisation of Oak

On 13.04.17 15:52, Angela Schreiber wrote: {quote} I would suggest to go with a naming scheme that reflects how modules would be grouped together in a hierarchical structure as much as possible for now. E.g. rename oak-commons-run to oak-run-commons. {quote} I would like to address this

Re: [m12] Effort to Improve Modularisation of Oak

I try to describe the changes proposed by the PoC in https://issues.apache.org/jira/browse/OAK-6073?focusedCommentId=15965623 ge=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment -15965623. Additionally added some step-by-step instruction on how we proceeded. Thanks,

Re: Module to host oak-run console scripts

Hi, On 13.04.17 11:33, Chetan Mehrotra wrote: Major benefit of scripts are they are faster to implement and can be used in older branches without impacting runtime. I agree on this part. But most of this benefit comes from not providing the same level of maintenance, testing, compatibility

Re: Backport of OAK-4933 to 1.6

On 12.04.17 09:17, Marcel Reutegger wrote: Hi, On 28/03/17 09:09, Michael Dürig wrote: As Marcel mentions on the issue a better approach would be to release this independently. If this is blocked by dependencies we should make an effort to sort this out, as now is the time in the release

Re: [m12] Effort to Improve Modularisation of Oak

Hi Angela, Thanks for driving this and coming up with a PoC. I like the direction this is taking. The module boundaries make sense to me and having certain dependencies de-tangled will certainly be helpful going forward. Could you share a bit of your experience doing this refactoring? What

Re: Merge policy for the 1.6 branch

ichael On 14.03.17 11:59, Michael Dürig wrote: Hi, Following up on Davide's release plan for Oak 1.6 [1] we should define a merge policy for the 1.6 branch. I would suggest to be a bit more conservative here than we have been in the past and ask for reviews of backports. That is, announce ca

Re: What's the contract of QueryBuilder.impersonates(String name)?

Confirmed, this is principle name. At least this is what it was built for in Jackrabbit 2. The string passed is escaped vis org.apache.jackrabbit.oak.commons.QueryUtils#escapeForQuery Michael On 03.04.17 16:36, Angela Schreiber wrote: Hi I don't know how Michael intended it to work

Re: Moving to Java 8

On 31.03.17 13:29, Julian Reschke wrote: On 2017-02-15 12:17, Julian Reschke wrote: Hi there, I understand that we might not be able to move to Java 8 just yet, but I felt it would be good to capture information related to this topic in Jira (so that we can link other related tickets). So

Re: New JIRA component for observation

On 31.03.17 07:06, Chetan Mehrotra wrote: On Thu, Mar 30, 2017 at 7:55 PM, Thomas Mueller wrote: Depending on that, we can use "Maven" module boundaries, or "Logical" module boundaries. My preference is for "Logical" module boundaries and not be bounded by the Maven

Re: Backport of OAK-4933 to 1.6

the tooling. Something we didn't have the resources for at that point in time. Michael Thanks, Raul On 28/03/2017, 11:54, "Angela Schreiber" <anch...@adobe.com> wrote: i was about to write pretty much the same thing :-) regards angela On 28/03/17 09:09, "

Re: Breakdown of Jira issues reported by Jenkins

/Jackrabbit%20Oak/ [2] https://builds.apache.org/view/J/job/Jackrabbit%20Oak/78/ On 21.03.17 09:06, Michael Dürig wrote: Hi, As a first reaction to this and to increase our benefit from Jenkins I disabled email notifications and Jira issue reporting for our Jenkins Matrix jobs [1, 2]. The jobs

Re: Backport of OAK-4933 to 1.6

As this is a new feature I would be interested in the motivation for having to backport this. Generally we should only backport fixes for defects. As Marcel mentions on the issue a better approach would be to release this independently. If this is blocked by dependencies we should make an

Re: New JIRA component for observation

On 27.03.17 09:26, Marcel Reutegger wrote: I'm wondering if this is the best approach. Initially we used the JIRA component 1:1 for modules we have in SVN. Now we also use them for sub-modules like 'documentmk', 'mongomk', 'property-index', ... +1 Michael

Re: Oak 1.0.29 vs 1.4.10 memory mapping.

Hi, I'm pretty sure that this method is the one introducing the extra full mapping of the repository: FileStoreHelper.checkFileStoreVersionOrFail We should probably run this check with memory mapping disabled anyway. Nothing to gain here but probably this would fix the double mapping and

Re: Metrics support in Oak

//github.com/ieb/slingmetrics/blob/master/src/main/java/org/apache/sling/metrics/impl/MetricsActivator.java#L79 On 21 March 2017 at 12:53, Michael Dürig <mdue...@apache.org> wrote: Hi, AFAICS Oak's Metrics support exposes all Stats in a flat namespace under "org.apache.jackrabbit.oak

Metrics support in Oak

Hi, AFAICS Oak's Metrics support exposes all Stats in a flat namespace under "org.apache.jackrabbit.oak". I don't think this is desirable. We should (a) either come up with a way to expose them by grouping related ones together or at least (b) arrive at a consensus on how we construct the

Re: Breakdown of Jira issues reported by Jenkins

://builds.apache.org/view/All/job/Apache%20Jackrabbit%20Oak%20matrix/ [2] https://builds.apache.org/view/All/job/Oak-Win/ [3] https://builds.apache.org/view/J/job/Jackrabbit%20Oak/ [4] https://issues.apache.org/jira/browse/INFRA-13599 On 28.02.17 12:31, Michael Dürig wrote: Hi, To get an overview on what

Re: Merge policy for the 1.6 branch

> wrote: On 14/03/2017 10:59, Michael Dürig wrote: In short, announce your backport on @oak-dev and ask for review. If confident enough that the review will pass anyway, go ahead but be prepared to revert. +1 if we time box it for each backport. For example 3 days or whatever. Something l

Re: Merge policy for the 1.6 branch

I don't think this works well: On 14.03.17 14:04, Julian Reschke wrote: Let me suggest something else: a) follow commit emails, As outlined in my previous mail this distributes the effort of figuring out the particulars of a backport to every committer where it would be less effort to

Re: Merge policy for the 1.6 branch

On 14.03.17 12:54, Julian Reschke wrote: On 2017-03-14 11:59, Michael Dürig wrote: Hi, Following up on Davide's release plan for Oak 1.6 [1] we should define a merge policy for the 1.6 branch. I would suggest to be a bit more conservative here than we have been in the past and ask

Re: Merge policy for the 1.6 branch

for backports afterwards. Regards, Tommaso Il giorno mar 14 mar 2017 alle ore 11:59 Michael Dürig <mdue...@apache.org> ha scritto: Hi, Following up on Davide's release plan for Oak 1.6 [1] we should define a merge policy for the 1.6 branch. I would suggest to be a bit more conservative her

Merge policy for the 1.6 branch

Hi, Following up on Davide's release plan for Oak 1.6 [1] we should define a merge policy for the 1.6 branch. I would suggest to be a bit more conservative here than we have been in the past and ask for reviews of backports. That is, announce candidates on @oak-dev mentioning the issue

Oak call topic: Jenkins issues and how to go forward

Hi, I posted a breakdown of the Jira issues reported by our Apache Jenkins instances on oak-dev [1]. Let's discuss whether the effort we are having there justifies the gain and how we could improve the situation. Michael [1] http://jackrabbit.markmail.org/thread/dnzis7d7bxv47cfe

  1   2   3   4   5   6   7   8   9   >