[Oak origin/trunk] Apache Jackrabbit Oak matrix - Build # 1501 - Still Failing
The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build #1501) Status: Still Failing Check console output at https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1501/ to view the results. Changes: [tomekr] OAK-5920 Checkpoint migration will fail if the MissingBlobStore is used [tomekr] OAK-5920 Checkpoint migration will fail if the MissingBlobStore is used [angela] OAK-5882 : Improve coverage for oak.security code in oak-core (wip) [angela] OAK-5926 : Readability of membership code [mduerig] trivial: added note re. this file being outdated [angela] OAK-5882 : Improve coverage for oak.security code in oak-core (wip) [angela] OAK-5929 : Redundant test for null with AuthorizableImpl.checkValidTree Test results: 1 tests failed. FAILED: org.apache.jackrabbit.oak.run.osgi.DocumentNodeStoreConfigTest.testRDBDocumentStore_CustomBlobStore Error Message: No service found for org.apache.jackrabbit.oak.spi.state.NodeStore. Expression: sr. Values: sr = null Stack Trace: java.lang.AssertionError: No service found for org.apache.jackrabbit.oak.spi.state.NodeStore. Expression: sr. Values: sr = null at org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:400) at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:646) at org.apache.jackrabbit.oak.run.osgi.AbstractRepositoryFactoryTest.getServiceWithWait(AbstractRepositoryFactoryTest.groovy:103) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90) at org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite$StaticMetaMethodSiteNoUnwrapNoCoerce.invoke(StaticMetaMethodSite.java:148) at org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite.callStatic(StaticMetaMethodSite.java:99) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:169) at org.apache.jackrabbit.oak.run.osgi.AbstractRepositoryFactoryTest.getServiceWithWait(AbstractRepositoryFactoryTest.groovy:96) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:207) at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:56) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:49) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:133) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:141) at org.apache.jackrabbit.oak.run.osgi.DocumentNodeStoreConfigTest.testRDBDocumentStore_CustomBlobStore(DocumentNodeStoreConfigTest.groovy:235) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48) at org.junit.rules.RunRules.evaluate(RunRules.java:20) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at org.junit.runners.ParentRunner.access$000(ParentRunn
[Oak origin/1.6] Apache Jackrabbit Oak matrix - Build # 1500 - Failure
The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build #1500) Status: Failure Check console output at https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1500/ to view the results. Changes: [tomekr] OAK-5920 Checkpoint migration will fail if the MissingBlobStore is used Test results: 1 tests failed. FAILED: org.apache.jackrabbit.oak.plugins.document.persistentCache.BroadcastTest.broadcastTCP Error Message: expected null, but was: Stack Trace: java.lang.AssertionError: expected null, but was: at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotNull(Assert.java:755) at org.junit.Assert.assertNull(Assert.java:737) at org.junit.Assert.assertNull(Assert.java:747) at org.apache.jackrabbit.oak.plugins.document.persistentCache.BroadcastTest.broadcastTry(BroadcastTest.java:220) at org.apache.jackrabbit.oak.plugins.document.persistentCache.BroadcastTest.broadcast(BroadcastTest.java:195) at org.apache.jackrabbit.oak.plugins.document.persistentCache.BroadcastTest.broadcastTCP(BroadcastTest.java:146) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at org.junit.runners.ParentRunner.run(ParentRunner.java:363) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
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 just write a single short message to @oak-dev. Also due to the large volume of traffic on @commits it is too easy to miss something. b) when we do a release from a stable branch, actually review what changed, instead of just ~3 people only running the release checker script. The release process is mostly about compliance with ASF licence requirements [1]. Apart from that when releasing it is not the appropriate time to discuss individual issues, their potential impact and risks. This is too late in the game. Such issues should be discussed close to the time when they are being worked on. Michael [1] http://www.apache.org/dev/release-publishing.html
Re: Merge policy for the 1.6 branch
Hi Julian Unfortunately we had issues more than once and they are not limited to indices. I distinctly remember troubles with semantic versioning, severe bugs that were back ported without anybody looking at the code, troublesome API... Therefore I don't agree that sending a mail to the list and inviting others to review changes is a waste of time or too much overhead. Kind regards Angela On 14/03/17 13:19, "Julian Reschke" wrote: >On 2017-03-14 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 for reviews of >>> backports. That is, announce candidates on @oak-dev mentioning the >>>issue >>> reference, potential risks, mitigations, etc. I don't think we need to >>> block the actual backport being performed on the outcome of the review >>> as in the worst case changes can always be reverted. The main aim of >>>the >>> announcement should be to increase visibility of the backports and >>> ensure they are eventually reviewed. >>> ... >> >> That sounds like a lot of overhead to me. >> >> What actual problem are we solving with this? >> >> Best regards, Julian > >I guess I need to expand on this. > >AFAICT, this has been triggered by one specific case where we backported >something without considering the impact on existing deployments (here: >creation of a new index that might cause the update to take a long time >on big repositories). > >(Or am I missing something here...?) > >Contrast with that with the tons of backports we've been doing, yes, >carefully, without such problems. > >Best regards, Julian >
Re: Merge policy for the 1.6 branch
On 2017-03-14 13:46, Michael Dürig wrote: ... The code review is something we should be doing anyway. The only added overhead here is the extra email asking for review. This is a bit of extra work for the person doing the backport but saves a couple of others time figuring out what a commit is about, its criticality, risk etc. Overall the effort would actually be less. And this doesn't even take into account all the extra effort a rogue backport would cause should we miss it by the standard CTR policy. ... Well, we have: 1) labels for backport candidates, 2) commit emails, 3) release notes and voting for releases. I'd argue that all these existing steps already provide opportunity for collecting review. Let me suggest something else: a) follow commit emails, b) when we do a release from a stable branch, actually review what changed, instead of just ~3 people only running the release checker script. I'd also propose that when we announce the release plan, we include the candidate release notes, so it's less work to see what changes would be included. Best regards, Julian
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 for reviews of backports. That is, announce candidates on @oak-dev mentioning the issue reference, potential risks, mitigations, etc. I don't think we need to block the actual backport being performed on the outcome of the review as in the worst case changes can always be reverted. The main aim of the announcement should be to increase visibility of the backports and ensure they are eventually reviewed. ... That sounds like a lot of overhead to me. What actual problem are we solving with this? The code review is something we should be doing anyway. The only added overhead here is the extra email asking for review. This is a bit of extra work for the person doing the backport but saves a couple of others time figuring out what a commit is about, its criticality, risk etc. Overall the effort would actually be less. And this doesn't even take into account all the extra effort a rogue backport would cause should we miss it by the standard CTR policy. Michael Best regards, Julian
Re: Merge policy for the 1.6 branch
On 2017-03-14 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 for reviews of backports. That is, announce candidates on @oak-dev mentioning the issue reference, potential risks, mitigations, etc. I don't think we need to block the actual backport being performed on the outcome of the review as in the worst case changes can always be reverted. The main aim of the announcement should be to increase visibility of the backports and ensure they are eventually reviewed. ... That sounds like a lot of overhead to me. What actual problem are we solving with this? Best regards, Julian I guess I need to expand on this. AFAICT, this has been triggered by one specific case where we backported something without considering the impact on existing deployments (here: creation of a new index that might cause the update to take a long time on big repositories). (Or am I missing something here...?) Contrast with that with the tons of backports we've been doing, yes, carefully, without such problems. Best regards, Julian
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 > backports. That is, announce candidates on @oak-dev mentioning the issue > reference, potential risks, mitigations, etc. I don't think we need to block > the actual backport being performed on the outcome of the review as in the > worst case changes can always be reverted. The main aim of the announcement > should be to increase visibility of the backports and ensure they are > eventually reviewed. > > 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. > > I think this is what we informally did so far already but wanted to state > this a bit more explicitly. > > WDYT? I'm in favour. I also like the idea of permanently applying this policy to every branch. > Michael > > > > [1] > https://lists.apache.org/thread.html/e5e71b61de9612d7cac195cbe948e8bdca58ee38ee16e7f124ea742c@%3Coak-dev.jackrabbit.apache.org%3E
Re: Merge policy for the 1.6 branch
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 for reviews of backports. That is, announce candidates on @oak-dev mentioning the issue reference, potential risks, mitigations, etc. I don't think we need to block the actual backport being performed on the outcome of the review as in the worst case changes can always be reverted. The main aim of the announcement should be to increase visibility of the backports and ensure they are eventually reviewed. ... That sounds like a lot of overhead to me. What actual problem are we solving with this? Best regards, Julian
Re: Merge policy for the 1.6 branch
ok, persistent and impacting all branches, sounds good to me. Regards, Tommaso Il giorno mar 14 mar 2017 alle ore 12:20 Michael Dürig ha scritto: > > I would be in favour to generally apply this policy for all branches as > with the number of branches we have now it is too easy to miss something > by just following @commits. > > Michael > > On 14.03.17 12:07, Tommaso Teofili wrote: > > I have one concern: is such a backport policy meant to be time boxed > (e.g. > > keep it for first N 1.6.x releases)? > > I am asking this because I'm wondering if we want to establish this > policy > > for all backports (1.4, 1.2, 1.0 branches too), or alternatively we aim > to > > be a bit conservative in the first months of a 1.x release and move back > to > > a less strict merge policy 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 here than we have been in the past and ask for reviews of > >> backports. That is, announce candidates on @oak-dev mentioning the issue > >> reference, potential risks, mitigations, etc. I don't think we need to > >> block the actual backport being performed on the outcome of the review > >> as in the worst case changes can always be reverted. The main aim of the > >> announcement should be to increase visibility of the backports and > >> ensure they are eventually reviewed. > >> > >> 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. > >> > >> I think this is what we informally did so far already but wanted to > >> state this a bit more explicitly. > >> > >> WDYT? > >> > >> Michael > >> > >> > >> > >> [1] > >> > >> > https://lists.apache.org/thread.html/e5e71b61de9612d7cac195cbe948e8bdca58ee38ee16e7f124ea742c@%3Coak-dev.jackrabbit.apache.org%3E > >> > > >
Re: Merge policy for the 1.6 branch
hi tommaso given some issues faced with backports in the past, i would wish this to be persistent and not just time boxed. kind regards angela On 14/03/17 12:07, "Tommaso Teofili" wrote: >I have one concern: is such a backport policy meant to be time boxed (e.g. >keep it for first N 1.6.x releases)? >I am asking this because I'm wondering if we want to establish this policy >for all backports (1.4, 1.2, 1.0 branches too), or alternatively we aim to >be a bit conservative in the first months of a 1.x release and move back >to >a less strict merge policy for backports afterwards. > >Regards, >Tommaso > >Il giorno mar 14 mar 2017 alle ore 11:59 Michael Dürig > >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 here than we have been in the past and ask for reviews of >> backports. That is, announce candidates on @oak-dev mentioning the issue >> reference, potential risks, mitigations, etc. I don't think we need to >> block the actual backport being performed on the outcome of the review >> as in the worst case changes can always be reverted. The main aim of the >> announcement should be to increase visibility of the backports and >> ensure they are eventually reviewed. >> >> 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. >> >> I think this is what we informally did so far already but wanted to >> state this a bit more explicitly. >> >> WDYT? >> >> Michael >> >> >> >> [1] >> >> >>https://lists.apache.org/thread.html/e5e71b61de9612d7cac195cbe948e8bdca58 >>ee38ee16e7f124ea742c@%3Coak-dev.jackrabbit.apache.org%3E >>
Re: Merge policy for the 1.6 branch
I would be in favour to generally apply this policy for all branches as with the number of branches we have now it is too easy to miss something by just following @commits. Michael On 14.03.17 12:07, Tommaso Teofili wrote: I have one concern: is such a backport policy meant to be time boxed (e.g. keep it for first N 1.6.x releases)? I am asking this because I'm wondering if we want to establish this policy for all backports (1.4, 1.2, 1.0 branches too), or alternatively we aim to be a bit conservative in the first months of a 1.x release and move back to a less strict merge policy for backports afterwards. Regards, Tommaso Il giorno mar 14 mar 2017 alle ore 11:59 Michael Dürig 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 here than we have been in the past and ask for reviews of backports. That is, announce candidates on @oak-dev mentioning the issue reference, potential risks, mitigations, etc. I don't think we need to block the actual backport being performed on the outcome of the review as in the worst case changes can always be reverted. The main aim of the announcement should be to increase visibility of the backports and ensure they are eventually reviewed. 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. I think this is what we informally did so far already but wanted to state this a bit more explicitly. WDYT? Michael [1] https://lists.apache.org/thread.html/e5e71b61de9612d7cac195cbe948e8bdca58ee38ee16e7f124ea742c@%3Coak-dev.jackrabbit.apache.org%3E
Re: Merge policy for the 1.6 branch
I have one concern: is such a backport policy meant to be time boxed (e.g. keep it for first N 1.6.x releases)? I am asking this because I'm wondering if we want to establish this policy for all backports (1.4, 1.2, 1.0 branches too), or alternatively we aim to be a bit conservative in the first months of a 1.x release and move back to a less strict merge policy for backports afterwards. Regards, Tommaso Il giorno mar 14 mar 2017 alle ore 11:59 Michael Dürig 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 here than we have been in the past and ask for reviews of > backports. That is, announce candidates on @oak-dev mentioning the issue > reference, potential risks, mitigations, etc. I don't think we need to > block the actual backport being performed on the outcome of the review > as in the worst case changes can always be reverted. The main aim of the > announcement should be to increase visibility of the backports and > ensure they are eventually reviewed. > > 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. > > I think this is what we informally did so far already but wanted to > state this a bit more explicitly. > > WDYT? > > Michael > > > > [1] > > https://lists.apache.org/thread.html/e5e71b61de9612d7cac195cbe948e8bdca58ee38ee16e7f124ea742c@%3Coak-dev.jackrabbit.apache.org%3E >
Re: Merge policy for the 1.6 branch
sounds like a plan angela 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 candidates on @oak-dev mentioning the issue >reference, potential risks, mitigations, etc. I don't think we need to >block the actual backport being performed on the outcome of the review >as in the worst case changes can always be reverted. The main aim of the >announcement should be to increase visibility of the backports and >ensure they are eventually reviewed. > >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. > >I think this is what we informally did so far already but wanted to >state this a bit more explicitly. > >WDYT? > >Michael > > > >[1] >https://lists.apache.org/thread.html/e5e71b61de9612d7cac195cbe948e8bdca58e >e38ee16e7f124ea742c@%3Coak-dev.jackrabbit.apache.org%3E
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 reference, potential risks, mitigations, etc. I don't think we need to block the actual backport being performed on the outcome of the review as in the worst case changes can always be reverted. The main aim of the announcement should be to increase visibility of the backports and ensure they are eventually reviewed. 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. I think this is what we informally did so far already but wanted to state this a bit more explicitly. WDYT? Michael [1] https://lists.apache.org/thread.html/e5e71b61de9612d7cac195cbe948e8bdca58ee38ee16e7f124ea742c@%3Coak-dev.jackrabbit.apache.org%3E
Re: Usage of lastModified from BlobStore record ?
Hi, Yes it is still used and it should be updated when writing a blob if it already exists. Thanks Amit On Tue, Mar 14, 2017 at 2:55 PM, Raul-Nicolae Hudea wrote: > Hi, > > In OAK 1.6, is lastModified of a DataRecord coming a BlobStore (S3, for > example) still used for timestamp comparison? (ex: to detect whether a > certain object needs to be GC-ed). Or updating it can be ignored in > backends (like S3Backend)? > > Looking through the code for usage of getLastModified seems to point in > that direction, but maybe someone has a more definitive answer. > > This is related to a question for the AzureDataStore PR ([1]) to which I > don’t have a definitive answer. > > Thanks, > Raul > > [1] https://github.com/apache/jackrabbit-oak/pull/58 > >
Usage of lastModified from BlobStore record ?
Hi, In OAK 1.6, is lastModified of a DataRecord coming a BlobStore (S3, for example) still used for timestamp comparison? (ex: to detect whether a certain object needs to be GC-ed). Or updating it can be ignored in backends (like S3Backend)? Looking through the code for usage of getLastModified seems to point in that direction, but maybe someone has a more definitive answer. This is related to a question for the AzureDataStore PR ([1]) to which I don’t have a definitive answer. Thanks, Raul [1] https://github.com/apache/jackrabbit-oak/pull/58
