Intent to backport OAK-8066 to 1.8 and 1.10

I intend to backport OAK-8066 to 1.8 and 1.10. The change prevents excessive memory consumption, which can lead to OOME, when rebasing a node with many children. The backport is tracked by OAK-8559. I couldn't reopen the original issue, so I created a new one to clearly signal that I want this

Re: Possible to open existing JCR repository using read-only FileStore?

The Jcr builder assumes write access to the repository. The read-only FileStore is used in CLI utilities and tests that deal directly with the NodeStore, completely bypassing the JCR API. As far as I know, we don't have a way to create a read-only JCR Repository. On Mon, 6 May 2019 at 10:49, Mark

Re: [SUMMARY] Branching and release

On Thu, 28 Mar 2019 at 14:13, Davide Giannella wrote: > I saw we still have versions like 1.10. Do we want to overall go through > a bit of sanitisation in Jira? > I think we should get rid of pseudo-versions like 1.10. I always found them confusing. Why not using only concrete versions we are

Re: Why don't we move to Git?

Hi, On Tue, 11 Dec 2018 at 10:56, Davide Giannella wrote: > Does git change always HEAD? Even if you merge something that fits > "behind" HEAD. > Git always changes the head when a merge commit is performed. See [1] for more details about how merging works in Git. I hope I understood your

Re: [Monitoring] - Provisioning StatisticsProvider in Oak

On Tue, 27 Nov 2018 at 11:45, Tommaso Teofili wrote: > After having dig into the code for a while I can see following options: > - have a dedicated OSGi service on the query side that can be then > polled in a static way from QueryEngineImpl in order to obtain such a > reference (see patch from

Re: Intent to backport OAK-7867 to Oak 1.8 and 1.6

+1 On Mon, 19 Nov 2018 at 17:50, Michael Dürig wrote: > 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

Re: Test failures in o.a.j.o.plugins.document

The problem seems to be caused by an incompatibility between the Docker client shipped with docker-junit-rule and the latest version of Docker. I created OAK-7874 to track this. On Thu, 1 Nov 2018 at 11:26, Francesco Mari wrote: > I experience multiple failures from te

Test failures in o.a.j.o.plugins.document

I experience multiple failures from tests in o.a.j.o.plugins.document. It looks like they have something to do with how the tests use Docker. I have Docker for Mac installed and working on my machine. Can somebody help with this? A sample of failures is the following: [INFO] Running

Re: Intend to backport OAK-7838

+1 On Tue, 30 Oct 2018 at 14:03, Michael Dürig wrote: > > > 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 >

Re: Intend to backport OAK-7837

+1 On Wed, 24 Oct 2018 at 11:42, Michael Dürig wrote: > > 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 >

Re: Intend to backport OAK-7854

+1 On Wed, 24 Oct 2018 at 11:46, Michael Dürig wrote: > > Hi, > > I intend to backport https://issues.apache.org/jira/browse/OAK-7854. > This issues adds and additional monitoring endpoint to detect the case > where the flush thread fails. Although the fix affects the file store, > the changes

Re: Jira component for oak-segmemt-azure

+1 On Thu, 4 Oct 2018 at 11:43, Michael Dürig wrote: > > 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 >

Intent to backport OAK-6890

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.

Intent to backport OAK-7721

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 the code path that led to the corruption. The

Intent to backport OAK-7720

I intend to backport OAK-7720 to the 1.8 and 1.6 branch. The fix makes the system log a dump of too big segments to ease debugging the corruption of the segment buffer.

Re: Intent to backport OAK-6648

+1 On Fri, 17 Aug 2018 at 09:09, Michael Dürig wrote: > > 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

Re: Release plan Oak 1.9.7

://techrevel.blog/2017/08/23/osgi-annotations-configuration-factory/ > > On 8/7/2018 8:02 PM, Francesco Mari wrote: > > Hi Manfred, > > Thanks for you suggestion. I'm currently experimenting with dropping the > `factory` attribute from `@Component` and setting the `factoryPi

Re: Release plan Oak 1.9.7

ht - ask a real OSGi > expert :)). Just try dropping the factory attribute from the Component > annotation and you should be fine. > > On 8/7/2018 6:32 PM, Francesco Mari wrote: > > The weird situation I'm looking into is that before my commit (e.g. at > >

Re: Release plan Oak 1.9.7

/osgi.org/specification/osgi.cmpn/7.0.0/service.component.html#service.component-factorycomponent On Tue, 7 Aug 2018 at 16:00, Francesco Mari wrote: > The issue is weird. The activate method of SegmentNodeStoreFactory is not > even called. As far as I know, all the other tests in oak

Re: Release plan Oak 1.9.7

The issue is weird. The activate method of SegmentNodeStoreFactory is not even called. As far as I know, all the other tests in oak-pojosr are working correctly. I will look into it. On Tue, 7 Aug 2018 at 15:19, Marcel Reutegger wrote: > Hi, > > On 07.08.18 14:57, Davide Giannella wrote: > >

Re: Intend to backport OAK-7132 to 1.8

+1 On Mon, Jan 22, 2018 at 12:24 PM, Michael Dürig wrote: > > 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)

Intent to backport OAK-{7168,7169,7171} to 1.8

I intend to backport OAK-{7168,7169,7171} to the 1.8 branch. The three issues fix the behaviour of the debug, datastorecheck, and history command when it comes to error handling. The fix make these commands return with a non-zero exit code in case of error and print error message to standard error

Intent to backport OAK-7157 to 1.8

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 generation, instead of the last two generations. This allows a cold standby instance to remove old segments more

Intent to backport OAK-7158 to 1.8

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 to a value different than its default might cause data loss due to the way cleanup works.

Re: [VOTE] Release Apache Jackrabbit Oak 1.6.7

+1 On Tue, Nov 28, 2017 at 10:46 AM, Alex Deparvu wrote: > [X] +1 Release this package as Apache Jackrabbit Oak 1.6.7 > > > alex > > On Tue, Nov 28, 2017 at 10:15 AM, Davide Giannella > wrote: > >> A candidate for the Jackrabbit Oak 1.6.7 release is

Re: identify abandoned oak modules

I'm in favour of retiring oak-remote. It is not currently used and it didn't receive much attention in the recent past. On Tue, Nov 21, 2017 at 3:56 PM, Angela Schreiber wrote: > hi oak devs > > looking at the list of modules we have in oak/trunk i get the impression >

Intent to backport OAK-6784

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.

Re: Intent to backport to 1.6 OAK-6931

+1 On Tue, Nov 14, 2017 at 12:19 PM, Michael Dürig wrote: > 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-6575 - A word of caution

On Thu, Sep 7, 2017 at 11:05 AM, Ian Boston wrote: > On 7 September 2017 at 07:22, Ian Boston wrote: > >> Hi, >> >> On 6 September 2017 at 22:43, Michael Dürig wrote: >> >>> >>> >>> On 06.09.17 23:08, Michael Dürig wrote: >>> Hi,

Re: OAK-6575 - A word of caution

On Wed, Sep 6, 2017 at 1:59 PM, Ian Boston <i...@tfd.co.uk> wrote: > Hi, > Thanks for looking at them. > > On 6 September 2017 at 12:32, Francesco Mari <mari.france...@gmail.com> > wrote: > >> I personally prefer the second approach. > > > Is that OAK

Re: OAK-6575 - A word of caution

nowledge will probably be able > to do better. > > > > On 5 September 2017 at 08:19, Ian Boston <i...@tfd.co.uk> wrote: > >> Hi, >> >> On 5 September 2017 at 07:55, Francesco Mari <mari.france...@gmail.com> >> wrote: >> >>> On Mon,

Re: OAK-6575 - A word of caution

On Mon, Sep 4, 2017 at 6:18 PM, Ian Boston wrote: > Do you mean: > keep the OakConversionService but put all the logic to convert from a > Value to a URI inside that implementation using new Oak SPI/APIs if > necessary and drop the AdapterManager completely ? Yes. I think there

Re: OAK-6575 - A word of caution

On Mon, Sep 4, 2017 at 4:41 PM, Ian Boston wrote: > If Oak committers feel that the contribution can't be included. Please feel > free to close OAK-6575 and I will delete the GitHub branch. Please don't! I'm not here to criticise your work, quite the contrary. The idea is good,

Re: OAK-6575 - A word of caution

s solution ad-hoc. > Would you be willing state your concerns for each one separately ? > > Best Regards > Ian > > On 4 September 2017 at 15:43, Francesco Mari <mari.france...@gmail.com> > wrote: > >> I'm in no position to veto the POC and I'm not willing to. I am

Re: OAK-6575 - A word of caution

I'm in no position to veto the POC and I'm not willing to. I am well aware of the importance of this feature. I expressed my concerns and so did others. As the subject of this thread clearly stated, I only wanted to point out that I had the feeling that we had a "reboot" of the conversation for no

OAK-6575 - A word of caution

The POC for OAK-6575 aims at introducing the AdapterManager and AdapterFactory API in Oak. This is just a step away from introducing a full-fledged implementation of Sling-like adapters in Oak. In fact, the OakConversionService is just an Adapter for a single, very specific conversion. We had a

Re: Backporting cold standby chunking to 1.6.x?

I wouldn't backport unless strictly necessary. In my opinion, this is not a bug but an improvement. On Mon, Aug 21, 2017 at 9:03 AM, Andrei Dulceanu wrote: > Hi all, > > With [0] and [1] blob chunking in cold standby was addressed in 1.8. I > think now we have a stable

Re: svn commit: r1805209 - in /jackrabbit/oak/trunk/oak-segment-tar: ./ src/main/java/org/apache/jackrabbit/oak/segment/file/ src/main/java/org/apache/jackrabbit/oak/segment/file/tar/ src/test/java/or

Instead of creating IOMonitor.NULL, you could instantiate a new IOMonitorAdapter when needed. This has already been done many times in TarFileTest and TarWriterTest. On Wed, Aug 16, 2017 at 5:26 PM, wrote: > Author: mduerig > Date: Wed Aug 16 15:26:29 2017 > New Revision:

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

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

Intent to backport OAK-4883 to 1.4

OAK-4883 fixes an issue introduced by a previous backport. The core of the issue is about publishing the JMX bean that allows to run the data store garbage collection on a standby instance.

Re: Percentile implementation

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 recommend writing my own or adapting/extracting

Re: Trunk doesn't compile

Thanks for taking care of this. 2017-07-04 10:17 GMT+02:00 Chetan Mehrotra <chetan.mehro...@gmail.com>: > My fault. Looks like code used API from Tika 1.15 which I am yet > testing. Would fix it now > Chetan Mehrotra > > > On Tue, Jul 4, 2017 at 1:34 PM, Francesco Mari &

Trunk doesn't compile

When compiling trunk (r1800739) I get the following error in the oak-lucene module. [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.5.1:compile (default-compile) on project oak-lucene: Compilation failure [ERROR]

Re: Dangling Java 8 Maven profile!?

+1 2017-04-25 9:08 GMT+02:00 Michael Dürig : > > 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-pare > nt/pom.xml#L960 >

Re: Oak 1.0.29 vs 1.4.10 memory mapping.

Hi, 2017-03-23 16:13 GMT+01:00 Alex Parvulescu : > Hi, > > To add what I have found so far. This seems related to OAK-4274, but I > think there might be a twist in there somewhere. > I'm pretty sure that this method is the one introducing the extra full > mapping of the

Re: Oak 1.0.29 vs 1.4.10 memory mapping.

You might be hitting OAK-4274, which I discovered quite some time ago. I'm not aware of a way to resolve this issue at the moment. 2017-03-22 16:47 GMT+01:00 Alex Parvulescu : > Hi, > > To give more background this came about during an investigation into a slow >

Re: Merge policy for the 1.6 branch

2017-03-14 11:59 GMT+01:00 Michael Dürig : > > 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 >

Re: svn commit: r1784874 - in /jackrabbit/oak/trunk/oak-core/src/test/java/org/apache/jackrabbit/oak/plugins/document: BlobReferenceIteratorTest.java OrphanedBranchTest.java RevisionGCTest.java

be that this problem is irrelevant to the document store! 2017-03-01 13:26 GMT+01:00 Marcel Reutegger <mreut...@adobe.com>: > On 01/03/17 09:55, Francesco Mari wrote: >> >> I don't know the implementation of store.dispose() but if that call >> throws an exception fixture.di

Re: svn commit: r1784874 - in /jackrabbit/oak/trunk/oak-core/src/test/java/org/apache/jackrabbit/oak/plugins/document: BlobReferenceIteratorTest.java OrphanedBranchTest.java RevisionGCTest.java

I don't know the implementation of store.dispose() but if that call throws an exception fixture.dispose() will not be invoked. If there is no ordering dependency between store.dispose(), fixture.dispose(), and Revision.resetClockToDefault(), it's more robust to put them in different @After

Re: JIRA commit plugin

2017-02-14 13:49 GMT+01:00 Alex Parvulescu : > Am I the only one relying on this feature to figure out backports? Of > course you have the comments on Jira, but almost always there's that > forgotten commit that fixes a tiny thing which isn't mentioned any more. A

[DISCUSS] Which I/O statistics should the FileStore expose?

Hi all, The recently introduced IOMonitor allows the FileStore to trigger I/O events. Callback methods from IOMonitor can be implemented to receive information about segment reads and writes. A trivial implementation of IOMonitor is able to track the following raw data. - The number of segments

Re: oak-run, diet and new module

As much as I like the proposal of slimming down oak-run, I think that dividing oak-run in oak-operations and oak-development is the wrong way to go. This kind of division is horizontal, since commands pertaining to different persistence backends are grouped together according to their roles. This

Re: svn commit: r1779324 - in /jackrabbit/oak/trunk/oak-segment-tar: ./ src/test/java/org/apache/jackrabbit/oak/segment/standby/ src/test/java/org/apache/jackrabbit/oak/segment/test/

Good suggestion. I opened OAK-5483 to track this. 2017-01-19 5:26 GMT+01:00 Chetan Mehrotra : > Hi Francesco, > > On Wed, Jan 18, 2017 at 7:01 PM, wrote: >> +package org.apache.jackrabbit.oak.segment.test; >> + >> +import java.net.ServerSocket; >> +

Re: Restrict matrix tasks to specific nodes

Thanks for your help. I will monitor the build during the following days and verify that everything is alright. 2016-12-08 20:01 GMT+01:00 Gavin McDonald <ga...@16degrees.com.au>: > >> On 8 Dec. 2016, at 9:34 pm, Francesco Mari <mari.france...@gmail.com> wrote: >&

Restrict matrix tasks to specific nodes

Hi, I recently discovered that some of the tests run by the Apache Jackrabbit Oak Matrix job [1] consistently fail when matrix tasks are scheduled on one of the nodes labelled "beam". I documented the failures in this issue [2]. I would like to schedule the matrix tasks to run on specific nodes

Re: Frequent failures in standby test

In the meantime, I configured those tests not to run when they are scheduled under a "beam" node. I will send a separate mail to builds@ and put oak-dev@ in CC. 2016-12-08 11:23 GMT+01:00 Robert Munteanu <romb...@apache.org>: > Hi, > > On Thu, 2016-12-08 at 10:01 +0100, F

Re: Frequent failures in standby test

e.org/jira/browse/OAK-5017?focusedCommentId=15731590=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15731590 2016-11-25 13:25 GMT+01:00 Francesco Mari <mari.france...@gmail.com>: > Every failure in build 1298 is due to "java.net.BindException: Address >

Re: svn commit: r1772167 - /jackrabbit/oak/trunk/oak-core/src/test/java/org/apache/jackrabbit/oak/query/QueryShapeTool.java

Would it make sense to make this part of oak-run instead? 2016-12-01 11:59 GMT+01:00 : > Author: thomasm > Date: Thu Dec 1 10:59:55 2016 > New Revision: 1772167 > > URL: http://svn.apache.org/viewvc?rev=1772167=rev > Log: > OAK-1884 Query: log file analyzer tool > > Added: >

Re: Remove oak-remote from reactor to get rid of JSON dependency

I will revisit RemoteServletIT to isolate and remove every usage of the JSON library. The test will have to be @Ignore'd, but oak-remote can be kept in the build without further modifications. I will rework the test in a second iteration to remove Unirest once and for all and restore

Re: Frequent failures in standby test

8 PM, Chetan Mehrotra > <chetan.mehro...@gmail.com> wrote: >> They are from oak-segment-tar. See >> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1295/#showFailuresLink >> Chetan Mehrotra >> >> >> On Tue, Nov 22, 2016 at 12:42 PM

Re: Build failing due to compilation errors in oak-segment-tar

Sorry, my bad. I messed up when I applied the patch. Thanks Chetan for fixing this. 2016-11-23 7:22 GMT+01:00 Andrei Dulceanu : > @Chetan Mehrotra, yes, this is the file. Thanks for adding it! > > On 23/11/2016, 07:18, "Chetan Mehrotra" wrote: > >

Re: Frequent failures in standby test

Are those from oak-tarmk-standby or oak-segment-tar? 2016-11-22 6:11 GMT+01:00 Chetan Mehrotra : > Hi Team, > > Since last 4-6 builds I am seeing a recurring failure of few test in > standby module > > * FailoverIPRangeIT > * ExternalPrivateStoreIT > * StandbyTestIT > >

Re: Deprecate oak-segment and oak-tarmk-standby

The other solution will be to keep oak-segment and oak-tarmk-standby as deprecated modules in 1.6.x and remove them in 1.8. 2016-11-01 14:00 GMT+01:00 Francesco Mari <mari.france...@gmail.com>: > 2016-11-01 12:56 GMT+01:00 Julian Reschke <julian.resc...@gmx.de>: >> On 2016-1

Re: Deprecate oak-segment and oak-tarmk-standby

2016-11-01 12:56 GMT+01:00 Julian Reschke <julian.resc...@gmx.de>: > On 2016-11-01 11:44, Francesco Mari wrote: >> >> Hi, >> >> 2016-11-01 11:38 GMT+01:00 Robert Munteanu <romb...@apache.org>: >>> >>> Hi Francesco, >>> >>

Re: Deprecate oak-segment and oak-tarmk-standby

Hi, 2016-11-01 11:38 GMT+01:00 Robert Munteanu <romb...@apache.org>: > Hi Francesco, > > On Tue, 2016-11-01 at 10:16 +0100, Francesco Mari wrote: >> Hi, >> >> This is a heads up for the deprecation oak-segment and >> oak-tarmk-standby. The new

Deprecate oak-segment and oak-tarmk-standby

Hi, This is a heads up for the deprecation oak-segment and oak-tarmk-standby. The new oak-segment-tar module is a replacement for both of the aforementioned modules. If somebody is concerned about the deprecation, please let me know.

Re: segment-tar depending on oak-core

is didn't happen because of lack of consensus. See my previous answer to Michael Marth. >See how that works out and if positive, continue with more. The reaction to the modularization effort was not positive, so oak-segment-tar backed up. > > Cheers, > Alex > > Am 27. Okt

Re: segment-tar depending on oak-core

might again find > consenus > > > > On 27/10/16 10:49, "Francesco Mari" <mari.france...@gmail.com> wrote: > >>We keep having this conversation regularly but nothing ever changes. >>As much as I would like to push the modularization effort forward, I >>re

Re: segment-tar depending on oak-core

We keep having this conversation regularly but nothing ever changes. As much as I would like to push the modularization effort forward, I recognize that the majority of the team is either not in favour or openly against it. I don't want to disrupt the way most of us are used to work. Michael Dürig

[RESULT][VOTE] Release Apache Jackrabbit Oak Segment Tar version 0.0.16

Hi, The vote passes as follows: +1 Michael Dürig +1 Francesco Mari +1 Davide Giannella +1 Alex Parvulescu Thanks for voting. I'll push the release out.

Re: segment-tar depending on oak-core

Luckily for us this is not a computer science problem but an easier software engineering concern. The release process in Oak is a joke. Releasing every two weeks by using version numbers as counters just for the sake of it is embarrassing. I don't even know how many releases of our parent POM we

Re: [VOTE] Release Apache Jackrabbit Oak Segment Tar version 0.0.16

+1 2016-10-20 14:17 GMT+02:00 Michael Dürig <mdue...@apache.org>: > > > On 20.10.16 2:08 , Francesco Mari wrote: >> >> [X] +1 Approve the release > > > Michael

[VOTE] Release Apache Jackrabbit Oak Segment Tar version 0.0.16

Hi, We solved 19 issues in this release: https://issues.apache.org/jira/browse/OAK/fixforversion/12338072 There are still some outstanding issues: https://issues.apache.org/jira/browse/OAK/component/12329487 Staging repository:

Oak Segment Tar 0.0.16 release plan

I'm planning to release oak-segment-tar tomorrow. There are currently some open issues, but none of them is critical. Currently open issues can be postponed to the next release. Let me know if I'm missing something.

Re: [VOTE] Release Apache Jackrabbit Oak Segment Tar version 0.0.14

+1

Re: another trunk build failure

I reverted that commit at r1763270. 2016-10-04 14:09 GMT+02:00 Francesco Mari <mari.france...@gmail.com>: > Yes, I guess I was too fast at enabling that fixture. The version of > Segment Tar implementing the Checkpoints interface hasn't been > released and referenced from the

Re: another trunk build failure

Yes, I guess I was too fast at enabling that fixture. The version of Segment Tar implementing the Checkpoints interface hasn't been released and referenced from the rest of Oak yet. 2016-10-04 14:03 GMT+02:00 Julian Reschke : > On 2016-10-04 12:08, Julian Reschke wrote: >>

Re: [VOTE] Release Apache Jackrabbit Oak Segment Tar version 0.0.12

+1 2016-09-15 18:29 GMT+02:00 Michael Dürig : > Hi, > > We solved 36 issues in this release: > https://issues.apache.org/jira/browse/OAK/fixforversion/12338153 > > There are still some outstanding issues: > https://issues.apache.org/jira/browse/OAK/component/12329487 > >

[RESULT][VOTE] Release Apache Jackrabbit Oak Segment Tar version 0.0.10

Hi, The vote passes as follows: +1 Francesco Mari +1 Alex Parvulescu +1 Michael Dürig Thanks for voting. I'll push the release out.

[VOTE] Release Apache Jackrabbit Oak Segment Tar version 0.0.10

Hi, We solved 18 issues in this release: https://issues.apache.org/jira/browse/OAK/fixforversion/12338041 There are still some outstanding issues: https://issues.apache.org/jira/browse/OAK/component/12329487 Staging repository:

Re: [VOTE] Release Apache Jackrabbit Oak Segment Tar version 0.0.10

+1 2016-08-23 18:07 GMT+02:00 Francesco Mari <mari.france...@gmail.com>: > Hi, > > We solved 18 issues in this release: > https://issues.apache.org/jira/browse/OAK/fixforversion/12338041 > > There are still some outstanding issues: > https://issues.apache.org/jira/br

Cold standby for oak-segment-tar

Hi all, The cold standby functionality originally implemented for oak-segment is currently unusable with oak-segment-tar. The cold standby requires access to the SegmentStore API and its lower level functionalities, but this API has been changed in oak-segment-tar in an incompatible way. I would

Re: Oak Segment Tar 0.0.8 release plan

the noise considerably. This approach also avoids the creation of Jira versions that have no meaning from a semantic versioning point of view. Looking forward to your opinions about this. 2016-07-29 15:21 GMT+02:00 Francesco Mari <mari.france...@gmail.com>: > The question to answer no

Re: Are dumb segments dumb?

The recent discovery in OAK-4604 shows that my POC suffers from the same problem. I fixed it in my latest commit. 2016-07-26 11:47 GMT+02:00 Francesco Mari <mari.france...@gmail.com>: > With my latest commits on this branch [1] I enabled every previously > ignored test, fixing them

Re: Are dumb segments dumb?

before. [1]: https://github.com/francescomari/jackrabbit-oak/tree/dumb 2016-07-25 17:48 GMT+02:00 Francesco Mari <mari.france...@gmail.com>: > It might be a variation in the process I tried. This shouldn't affect > much the statistics anyway, given that the population sample is big >

Re: Are dumb segments dumb?

a test artefact (i.e. test not > reproducible) or are we missing out on something. > > Michael > > > On 25.7.16 4:01 , Francesco Mari wrote: >> >> I put together some statistics [1] for the process I described above. >> The "dumb" variant requires more se

Re: Are dumb segments dumb?

I opened OAK-4596 to track the segment leak. 2016-07-25 16:01 GMT+02:00 Francesco Mari <mari.france...@gmail.com>: > I put together some statistics [1] for the process I described above. > The "dumb" variant requires more segments to store the same amount of > data, beca

Re: Are dumb segments dumb?

usually end up stored in the same segment. >> This >>makes tree traversals very fast and avoids most cache misses for >> typical >>clients that access more than one related node per session. >> >> Thus I would recommend keeping an eye also on benc

[RESULT][VOTE] Release Apache Jackrabbit Oak Segment Tar version 0.0.6

Hi, The vote passes as follows: +1 Francesco Mari +1 Michael Dürig +1 Alex Parvulescu Thanks for voting. I'll push the release out.

Re: Are dumb segments dumb?

the same time reducing > complexity a lot. > > OTOH we need to figure out how to regain the lost functionality (e.g. gc) > and asses its impact on repository size. > > Michael > > > > On 22.7.16 11:32 , Francesco Mari wrote: >> >> Hi, >> >> Yesterd

Are dumb segments dumb?

Hi, Yesterday I took some time for a little experiment: how many optimisations can be removed from the current segment format while maintaining the same functionality? I made some work in a branch on GitHub [1]. The code on that branch is similar to the current trunk except for the following

Re: [VOTE] Release Apache Jackrabbit Oak Segment Tar version 0.0.6

+1 2016-07-19 16:00 GMT+02:00 Francesco Mari <mari.france...@gmail.com>: > Hi, > > We solved 5 issues in this release: > https://issues.apache.org/jira/browse/OAK/fixforversion/12337966 > > There are still some outstanding issues: > https://issues.apache.org/jira/br

[VOTE] Release Apache Jackrabbit Oak Segment Tar version 0.0.6

Hi, We solved 5 issues in this release: https://issues.apache.org/jira/browse/OAK/fixforversion/12337966 There are still some outstanding issues: https://issues.apache.org/jira/browse/OAK/component/12329487 Staging repository:

[RESULT][VOTE] Release Apache Jackrabbit Oak Segment Tar version 0.0.4

Hi, The vote passes as follows: +1 Francesco Mari +1 Alex Parvulescu +1 Tommaso Teofili Thanks for voting. I'll push the release out.

Re: svn commit: r1752601 - in /jackrabbit/oak/trunk/oak-segment-tar: pom.xml src/main/java/org/apache/jackrabbit/oak/segment/SegmentWriter.java

I embedded Commons Math to make testing easier. I opened OAK-4561 to track the removal of the embedded dependency as soon as possible. 2016-07-14 11:57 GMT+02:00 Chetan Mehrotra : > On Thu, Jul 14, 2016 at 2:04 PM, wrote: > >

Re: [VOTE] Release Apache Jackrabbit Oak Segment Tar version 0.0.4

+1 2016-07-11 17:10 GMT+02:00 Francesco Mari <mari.france...@gmail.com>: > Hi, > > We solved 3 issues in this release: > https://issues.apache.org/jira/browse/OAK/fixforversion/12336855 > > There are still some outstanding issues: > https://issues.apache.org/jira/br

[VOTE] Release Apache Jackrabbit Oak Segment Tar version 0.0.4

Hi, We solved 3 issues in this release: https://issues.apache.org/jira/browse/OAK/fixforversion/12336855 There are still some outstanding issues: https://issues.apache.org/jira/browse/OAK/component/12329487 Staging repository:

Re: svn commit: r1750601 - in /jackrabbit/oak/trunk: oak-segment-tar/ oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/ oak-segment-tar/src/test/java/org/apache/jackrabbit/oak/segment/

Thanks a lot for your understanding! 2016-06-29 10:43 GMT+02:00 Chetan Mehrotra <chetan.mehro...@gmail.com>: > On Wed, Jun 29, 2016 at 1:25 PM, Francesco Mari > <mari.france...@gmail.com> wrote: > > oak-segment-tar should be releasable at any time. If I had to launch

Re: svn commit: r1750601 - in /jackrabbit/oak/trunk: oak-segment-tar/ oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/ oak-segment-tar/src/test/java/org/apache/jackrabbit/oak/segment/

your commit or postpone my release until Oak is released. Please don't let Oak impact the way we decided to manage oak-segment-tar. On Jun 29, 2016 9:25 AM, "Chetan Mehrotra" <chetan.mehro...@gmail.com> wrote: > Hi Francesco, > > On Wed, Jun 29, 2016 at 12:49 PM, Fran

Fwd: svn commit: r1750601 - in /jackrabbit/oak/trunk: oak-segment-tar/ oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/ oak-segment-tar/src/test/java/org/apache/jackrabbit/oak/segment/

Hi Chetan, Please do not change the "oak.version" property to a snapshot version. If your change relies on code that is only available in the latest snapshot of Oak, please revert this commit and hold it back until a proper release of Oak is performed. Thanks, Francesco -- Forwarded

  1   2   3   >