[jira] [Updated] (OAK-4125) Test failure: testUpdateAndDelete [MyFixture: RDB-Derby(embedded)]

[Julian Reschke (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Reschke updated OAK-4125:

Fix Version/s: 1.0.35

> Test failure: testUpdateAndDelete [MyFixture: RDB-Derby(embedded)]
> --
>
> Key: OAK-4125
> URL: https://issues.apache.org/jira/browse/OAK-4125
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: rdbmk
>Affects Versions: 1.2.12, 1.0.28, 1.4.0
>Reporter: Davide Giannella
>Assignee: Julian Reschke
> Fix For: 1.6, 1.5.0, 1.0.35, 1.2.21, 1.4.10
>
>
> Test is randomly failing on jenkins. See epic for list of failed builds. Both 
> trunk and 1.4.
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/785/
> {noformat}
> Test results:
> 1 tests failed.
> FAILED:  
> org.apache.jackrabbit.oak.plugins.document.blob.RDBBlobStoreTest.testUpdateAndDelete[MyFixture:
>  RDB-Derby(embedded)]
> Error Message:
> null
> Stack Trace:
> java.lang.AssertionError
>   at org.junit.Assert.fail(Assert.java:86)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at org.junit.Assert.assertFalse(Assert.java:64)
>   at org.junit.Assert.assertFalse(Assert.java:74)
>   at 
> org.apache.jackrabbit.oak.plugins.document.blob.RDBBlobStoreTest.testUpdateAndDelete(RDBBlobStoreTest.java:187)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   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.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.junit.runners.Suite.runChild(Suite.java:128)
>   at org.junit.runners.Suite.runChild(Suite.java:27)
>   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:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   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)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (OAK-4125) Test failure: testUpdateAndDelete [MyFixture: RDB-Derby(embedded)]

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622926#comment-15622926
 ] 

Julian Reschke edited comment on OAK-4125 at 11/1/16 6:38 AM:
--

trunk: [r1735109|http://svn.apache.org/r1735109]
1.4: [r1767350|http://svn.apache.org/r1767350]
1.2: [r1767369|http://svn.apache.org/r1767369]
1.0: [r1767428|http://svn.apache.org/r1767428]



was (Author: reschke):
trunk: [r1735109|http://svn.apache.org/r1735109]
1.4: [r1767350|http://svn.apache.org/r1767350]
1.2: [r1767369|http://svn.apache.org/r1767369]


> Test failure: testUpdateAndDelete [MyFixture: RDB-Derby(embedded)]
> --
>
> Key: OAK-4125
> URL: https://issues.apache.org/jira/browse/OAK-4125
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: rdbmk
>Affects Versions: 1.2.12, 1.0.28, 1.4.0
>Reporter: Davide Giannella
>Assignee: Julian Reschke
> Fix For: 1.6, 1.5.0, 1.0.35, 1.2.21, 1.4.10
>
>
> Test is randomly failing on jenkins. See epic for list of failed builds. Both 
> trunk and 1.4.
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/785/
> {noformat}
> Test results:
> 1 tests failed.
> FAILED:  
> org.apache.jackrabbit.oak.plugins.document.blob.RDBBlobStoreTest.testUpdateAndDelete[MyFixture:
>  RDB-Derby(embedded)]
> Error Message:
> null
> Stack Trace:
> java.lang.AssertionError
>   at org.junit.Assert.fail(Assert.java:86)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at org.junit.Assert.assertFalse(Assert.java:64)
>   at org.junit.Assert.assertFalse(Assert.java:74)
>   at 
> org.apache.jackrabbit.oak.plugins.document.blob.RDBBlobStoreTest.testUpdateAndDelete(RDBBlobStoreTest.java:187)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   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.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.junit.runners.Suite.runChild(Suite.java:128)
>   at org.junit.runners.Suite.runChild(Suite.java:27)
>   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:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   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.ProviderFactor

[jira] [Comment Edited] (OAK-4125) Test failure: testUpdateAndDelete [MyFixture: RDB-Derby(embedded)]

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622926#comment-15622926
 ] 

Julian Reschke edited comment on OAK-4125 at 10/31/16 8:48 PM:
---

trunk: [r1735109|http://svn.apache.org/r1735109]
1.4: [r1767350|http://svn.apache.org/r1767350]
1.2: [r1767369|http://svn.apache.org/r1767369]



was (Author: reschke):
trunk: [r1735109|http://svn.apache.org/r1735109]
1.4: [r1767350|http://svn.apache.org/r1767350]


> Test failure: testUpdateAndDelete [MyFixture: RDB-Derby(embedded)]
> --
>
> Key: OAK-4125
> URL: https://issues.apache.org/jira/browse/OAK-4125
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: rdbmk
>Affects Versions: 1.2.12, 1.0.28, 1.4.0
>Reporter: Davide Giannella
>Assignee: Julian Reschke
> Fix For: 1.6, 1.5.0, 1.2.21, 1.4.10
>
>
> Test is randomly failing on jenkins. See epic for list of failed builds. Both 
> trunk and 1.4.
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/785/
> {noformat}
> Test results:
> 1 tests failed.
> FAILED:  
> org.apache.jackrabbit.oak.plugins.document.blob.RDBBlobStoreTest.testUpdateAndDelete[MyFixture:
>  RDB-Derby(embedded)]
> Error Message:
> null
> Stack Trace:
> java.lang.AssertionError
>   at org.junit.Assert.fail(Assert.java:86)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at org.junit.Assert.assertFalse(Assert.java:64)
>   at org.junit.Assert.assertFalse(Assert.java:74)
>   at 
> org.apache.jackrabbit.oak.plugins.document.blob.RDBBlobStoreTest.testUpdateAndDelete(RDBBlobStoreTest.java:187)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   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.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.junit.runners.Suite.runChild(Suite.java:128)
>   at org.junit.runners.Suite.runChild(Suite.java:27)
>   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:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   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.ForkedBoote

[jira] [Updated] (OAK-4125) Test failure: testUpdateAndDelete [MyFixture: RDB-Derby(embedded)]

[Julian Reschke (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Reschke updated OAK-4125:

Fix Version/s: 1.2.21

> Test failure: testUpdateAndDelete [MyFixture: RDB-Derby(embedded)]
> --
>
> Key: OAK-4125
> URL: https://issues.apache.org/jira/browse/OAK-4125
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: rdbmk
>Affects Versions: 1.2.12, 1.0.28, 1.4.0
>Reporter: Davide Giannella
>Assignee: Julian Reschke
> Fix For: 1.6, 1.5.0, 1.2.21, 1.4.10
>
>
> Test is randomly failing on jenkins. See epic for list of failed builds. Both 
> trunk and 1.4.
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/785/
> {noformat}
> Test results:
> 1 tests failed.
> FAILED:  
> org.apache.jackrabbit.oak.plugins.document.blob.RDBBlobStoreTest.testUpdateAndDelete[MyFixture:
>  RDB-Derby(embedded)]
> Error Message:
> null
> Stack Trace:
> java.lang.AssertionError
>   at org.junit.Assert.fail(Assert.java:86)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at org.junit.Assert.assertFalse(Assert.java:64)
>   at org.junit.Assert.assertFalse(Assert.java:74)
>   at 
> org.apache.jackrabbit.oak.plugins.document.blob.RDBBlobStoreTest.testUpdateAndDelete(RDBBlobStoreTest.java:187)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   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.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.junit.runners.Suite.runChild(Suite.java:128)
>   at org.junit.runners.Suite.runChild(Suite.java:27)
>   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:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   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)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-4125) Test failure: testUpdateAndDelete [MyFixture: RDB-Derby(embedded)]

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622926#comment-15622926
 ] 

Julian Reschke commented on OAK-4125:
-

trunk: [r1735109|http://svn.apache.org/r1735109]
1.4: [r1767350|http://svn.apache.org/r1767350]


> Test failure: testUpdateAndDelete [MyFixture: RDB-Derby(embedded)]
> --
>
> Key: OAK-4125
> URL: https://issues.apache.org/jira/browse/OAK-4125
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: rdbmk
>Affects Versions: 1.2.12, 1.0.28, 1.4.0
>Reporter: Davide Giannella
>Assignee: Julian Reschke
> Fix For: 1.6, 1.5.0, 1.4.10
>
>
> Test is randomly failing on jenkins. See epic for list of failed builds. Both 
> trunk and 1.4.
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/785/
> {noformat}
> Test results:
> 1 tests failed.
> FAILED:  
> org.apache.jackrabbit.oak.plugins.document.blob.RDBBlobStoreTest.testUpdateAndDelete[MyFixture:
>  RDB-Derby(embedded)]
> Error Message:
> null
> Stack Trace:
> java.lang.AssertionError
>   at org.junit.Assert.fail(Assert.java:86)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at org.junit.Assert.assertFalse(Assert.java:64)
>   at org.junit.Assert.assertFalse(Assert.java:74)
>   at 
> org.apache.jackrabbit.oak.plugins.document.blob.RDBBlobStoreTest.testUpdateAndDelete(RDBBlobStoreTest.java:187)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   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.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.junit.runners.Suite.runChild(Suite.java:128)
>   at org.junit.runners.Suite.runChild(Suite.java:27)
>   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:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   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)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OAK-4125) Test failure: testUpdateAndDelete [MyFixture: RDB-Derby(embedded)]

[Julian Reschke (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Reschke updated OAK-4125:

Fix Version/s: 1.4.10

> Test failure: testUpdateAndDelete [MyFixture: RDB-Derby(embedded)]
> --
>
> Key: OAK-4125
> URL: https://issues.apache.org/jira/browse/OAK-4125
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: rdbmk
>Affects Versions: 1.2.12, 1.0.28, 1.4.0
>Reporter: Davide Giannella
>Assignee: Julian Reschke
> Fix For: 1.6, 1.5.0, 1.4.10
>
>
> Test is randomly failing on jenkins. See epic for list of failed builds. Both 
> trunk and 1.4.
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/785/
> {noformat}
> Test results:
> 1 tests failed.
> FAILED:  
> org.apache.jackrabbit.oak.plugins.document.blob.RDBBlobStoreTest.testUpdateAndDelete[MyFixture:
>  RDB-Derby(embedded)]
> Error Message:
> null
> Stack Trace:
> java.lang.AssertionError
>   at org.junit.Assert.fail(Assert.java:86)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at org.junit.Assert.assertFalse(Assert.java:64)
>   at org.junit.Assert.assertFalse(Assert.java:74)
>   at 
> org.apache.jackrabbit.oak.plugins.document.blob.RDBBlobStoreTest.testUpdateAndDelete(RDBBlobStoreTest.java:187)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   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.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.junit.runners.Suite.runChild(Suite.java:128)
>   at org.junit.runners.Suite.runChild(Suite.java:27)
>   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:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   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)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-1558) Expose FileStoreBackupRestoreMBean for supported NodeStores

[Andrei Dulceanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622898#comment-15622898
 ] 

Andrei Dulceanu commented on OAK-1558:
--

[~mduerig], what is the difference between this issue and OAK-4866? To me, they 
seem to share the same goal.

> Expose FileStoreBackupRestoreMBean for supported NodeStores
> ---
>
> Key: OAK-1558
> URL: https://issues.apache.org/jira/browse/OAK-1558
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: mongomk, segment-tar
>Reporter: Michael Dürig
>  Labels: monitoring
> Fix For: 1.5.13
>
>
> {{NodeStore}} implementations should expose the 
> {{FileStoreBackupRestoreMBean}} in order to be interoperable with 
> {{RepositoryManagementMBean}}. See OAK-1160.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-5021) Improve observation of files

[Stefan Egli (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-5021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622800#comment-15622800
 ] 

Stefan Egli commented on OAK-5021:
--

Main implementation done 
[here|http://svn.apache.org/viewvc?rev=1767337&view=rev], which introduces:
{code}
public abstract OakEventFilter withNodeTypeAggregate(final String[] nodeTypes, 
final String[] relativeGlobPaths);
{code}
to the OakEventFilter. This allows to register a filter listening on changes 
below a node matching a set of node types. The change can happen in a number of 
subpaths and is subsequently 'aggregated', ie the event reporting the change 
has the location set to the node matching the set of node types (and the path 
still pointing to the actual change).

> Improve observation of files
> 
>
> Key: OAK-5021
> URL: https://issues.apache.org/jira/browse/OAK-5021
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: jcr
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>
> (Originally reported as JCR-4046, but moved to Oak as a result of introducing 
> the OakEventFilter in OAK-5013. From the original description: )
> A file in JCR is represented by at least two nodes, the nt:file node and a 
> child node named jcr:content holding the contents of the file (and metadata).
> This has the consequence that if the contents of a file changes, a change 
> event of the jcr:content node is reported - but not of the nt:file node.
> This makes creating listeners listening for changes in files complicated, as 
> you can't use the file name to filter  - especially with glob patterns (see 
> JCR-4044 - now OAK-5019) this becomes troublesome.
> In addition, whenever you get a change for a jcr:content node, you have to 
> check if the parent is a nt:file node and decide based on the result.
> It would be great to have a flag on the JackrabbitEventFilter to enable 
> smarter reporting just for nt:files: if a property on jcr:content is changed, 
> a change to the nt:file node is reported.
> See also SLING-6163 and OAK-4940
> /cc [~cziegeler]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (OAK-5019) Support glob patterns through OakEventFilter

[Stefan Egli (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-5019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622730#comment-15622730
 ] 

Stefan Egli edited comment on OAK-5019 at 10/31/16 5:12 PM:


Main implementation added 
[here|http://svn.apache.org/viewvc?rev=1767330&view=rev], (EDIT: and 
[here|http://svn.apache.org/viewvc?rev=1767333&view=rev]). This introduces:
{code}
public abstract OakEventFilter withIncludeGlobPaths(String... globPaths);
{code}
to the OakEventFilter and allows OAK-5039 style '*' wildcards in paths ('?' is 
not supported)


was (Author: egli):
Main implementation added 
[here|http://svn.apache.org/viewvc?rev=1767330&view=rev]. This introduces:
{code}
public abstract OakEventFilter withIncludeGlobPaths(String... globPaths);
{code}
to the OakEventFilter and allows OAK-5039 style '*' wildcards in paths ('?' is 
not supported)

> Support glob patterns through OakEventFilter
> 
>
> Key: OAK-5019
> URL: https://issues.apache.org/jira/browse/OAK-5019
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: jcr
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>
> (Originally reported as JCR-4044, but moved to Oak as a result of introducing 
> the OakEventFilter in OAK-5013. From the original description: )
> In the Sling project, we would like to register JCR listeners based on glob 
> patterns as defined in
> https://jackrabbit.apache.org/oak/docs/apidocs/org/apache/jackrabbit/oak/plugins/observation/filter/GlobbingPathFilter.html
> So basically instead (or in addition) to specifying an absolute path, 
> defining patterns.
> [Discussion 
> thread|https://lists.apache.org/thread.html/300f84574bbb039cebe35aab1afc21e043560a1c0471e456a2f5c0be@%3Cdev.jackrabbit.apache.org%3E]
> /cc [~cziegeler]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-5019) Support glob patterns through OakEventFilter

[Stefan Egli (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-5019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622730#comment-15622730
 ] 

Stefan Egli commented on OAK-5019:
--

Main implementation added 
[here|http://svn.apache.org/viewvc?rev=1767330&view=rev]. This introduces:
{code}
public abstract OakEventFilter withIncludeGlobPaths(String... globPaths);
{code}
to the OakEventFilter and allows OAK-5039 style '*' wildcards in paths ('?' is 
not supported)

> Support glob patterns through OakEventFilter
> 
>
> Key: OAK-5019
> URL: https://issues.apache.org/jira/browse/OAK-5019
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: jcr
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>
> (Originally reported as JCR-4044, but moved to Oak as a result of introducing 
> the OakEventFilter in OAK-5013. From the original description: )
> In the Sling project, we would like to register JCR listeners based on glob 
> patterns as defined in
> https://jackrabbit.apache.org/oak/docs/apidocs/org/apache/jackrabbit/oak/plugins/observation/filter/GlobbingPathFilter.html
> So basically instead (or in addition) to specifying an absolute path, 
> defining patterns.
> [Discussion 
> thread|https://lists.apache.org/thread.html/300f84574bbb039cebe35aab1afc21e043560a1c0471e456a2f5c0be@%3Cdev.jackrabbit.apache.org%3E]
> /cc [~cziegeler]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (OAK-4125) Test failure: testUpdateAndDelete [MyFixture: RDB-Derby(embedded)]

[Julian Reschke (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Reschke resolved OAK-4125.
-
Resolution: Fixed

marking as resolved (as it seems to reliably pass now); adding "1.5.0" as the 
version it was fixed in. Will backport to earlier branches.

> Test failure: testUpdateAndDelete [MyFixture: RDB-Derby(embedded)]
> --
>
> Key: OAK-4125
> URL: https://issues.apache.org/jira/browse/OAK-4125
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: rdbmk
>Affects Versions: 1.2.12, 1.0.28, 1.4.0
>Reporter: Davide Giannella
>Assignee: Julian Reschke
> Fix For: 1.6, 1.5.0
>
>
> Test is randomly failing on jenkins. See epic for list of failed builds. Both 
> trunk and 1.4.
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/785/
> {noformat}
> Test results:
> 1 tests failed.
> FAILED:  
> org.apache.jackrabbit.oak.plugins.document.blob.RDBBlobStoreTest.testUpdateAndDelete[MyFixture:
>  RDB-Derby(embedded)]
> Error Message:
> null
> Stack Trace:
> java.lang.AssertionError
>   at org.junit.Assert.fail(Assert.java:86)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at org.junit.Assert.assertFalse(Assert.java:64)
>   at org.junit.Assert.assertFalse(Assert.java:74)
>   at 
> org.apache.jackrabbit.oak.plugins.document.blob.RDBBlobStoreTest.testUpdateAndDelete(RDBBlobStoreTest.java:187)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   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.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.junit.runners.Suite.runChild(Suite.java:128)
>   at org.junit.runners.Suite.runChild(Suite.java:27)
>   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:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   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)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OAK-4125) Test failure: testUpdateAndDelete [MyFixture: RDB-Derby(embedded)]

[Julian Reschke (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Reschke updated OAK-4125:

Fix Version/s: 1.5.0

> Test failure: testUpdateAndDelete [MyFixture: RDB-Derby(embedded)]
> --
>
> Key: OAK-4125
> URL: https://issues.apache.org/jira/browse/OAK-4125
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: rdbmk
>Affects Versions: 1.2.12, 1.0.28, 1.4.0
>Reporter: Davide Giannella
>Assignee: Julian Reschke
> Fix For: 1.6, 1.5.0
>
>
> Test is randomly failing on jenkins. See epic for list of failed builds. Both 
> trunk and 1.4.
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/785/
> {noformat}
> Test results:
> 1 tests failed.
> FAILED:  
> org.apache.jackrabbit.oak.plugins.document.blob.RDBBlobStoreTest.testUpdateAndDelete[MyFixture:
>  RDB-Derby(embedded)]
> Error Message:
> null
> Stack Trace:
> java.lang.AssertionError
>   at org.junit.Assert.fail(Assert.java:86)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at org.junit.Assert.assertFalse(Assert.java:64)
>   at org.junit.Assert.assertFalse(Assert.java:74)
>   at 
> org.apache.jackrabbit.oak.plugins.document.blob.RDBBlobStoreTest.testUpdateAndDelete(RDBBlobStoreTest.java:187)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   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.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.junit.runners.Suite.runChild(Suite.java:128)
>   at org.junit.runners.Suite.runChild(Suite.java:27)
>   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:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   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)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-5040) Remove backup/restore methods in RepositoryManagementMBean

[JIRA]

[ 
https://issues.apache.org/jira/browse/OAK-5040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622605#comment-15622605
 ] 

Michael Dürig commented on OAK-5040:


This issue is inverse to OAK-1558. We need to decide which of the two we want 
to implement. I have a slight preference for OAK-1558 as all the functionality 
is actually there, only the wiring is missing. 

> Remove backup/restore methods in RepositoryManagementMBean
> --
>
> Key: OAK-5040
> URL: https://issues.apache.org/jira/browse/OAK-5040
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
> Fix For: 1.5.13
>
>
> The two operations: {{startBackup()}} and {{startRestore()}} exposed by 
> {{RepositoryManagementMBean}} throw an error when accessed:
> {{Cannot perform operation: no service of type FileStoreBackupRestoreMBean 
> found.}}
> Since this functionality is seldom used, these two methods should be removed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (OAK-5011) Add event aggregation support to observation filtering

[Stefan Egli (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-5011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Egli resolved OAK-5011.
--
   Resolution: Fixed
Fix Version/s: 1.5.13

Done in trunk in http://svn.apache.org/viewvc?rev=1767322&view=rev

> Add event aggregation support to observation filtering
> --
>
> Key: OAK-5011
> URL: https://issues.apache.org/jira/browse/OAK-5011
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, jcr
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: 1.5.13
>
> Attachments: OAK-5011.patch
>
>
> Currently the observation filtering 'subsystem' allows only the creation of 
> events with the path and identifier set to the parent of where the change 
> happened. To support features like JCR-4046 we need some sort of event 
> 'aggregation'. The idea is that while the change happened somewhere in a 
> subtree it would still be reported with the {{event.getIdentifier()}} set on 
> some parent/aggregator node (the {{event.getPath()}} would still be the 
> actual change).
> To support this, the suggestion is to add a {{EventAggregator}} to the 
> {{FilterBuilder}} which would be invoked right before the actual event is 
> being created, but after the filtering happened, so it would only affect how 
> the event looks like, not whether or not the event is generated.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (OAK-5039) Change globbing definition of GlobbingPathFilter

[Stefan Egli (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-5039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Egli resolved OAK-5039.
--
Resolution: Fixed

done in http://svn.apache.org/viewvc?rev=1767317&view=rev

> Change globbing definition of GlobbingPathFilter
> 
>
> Key: OAK-5039
> URL: https://issues.apache.org/jira/browse/OAK-5039
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: core
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: 1.5.13
>
>
> In order to satisfy OAK-5019 (and thus SLING-6174) the definition of 
> [GlobbingPathFilter|https://jackrabbit.apache.org/oak/docs/apidocs/org/apache/jackrabbit/oak/plugins/observation/filter/GlobbingPathFilter.html]
>  needs to be changed wrt the following:
> * old: {{* matches every path containing a single element}}
> * new: {{* matches character matches zero or more characters of a name 
> component without crossing directory boundaries}}
> (and derived definition is hence adjusted accordingly to match above change)
> This change will basically allow to match eg
> * {noformat}*.*{noformat}
> * {noformat}*.html{noformat}
> and not only arbitrarily named path elements.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OAK-5040) Remove backup/restore methods in RepositoryManagementMBean

[Andrei Dulceanu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-5040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-5040:
-
Issue Type: Task  (was: Bug)

> Remove backup/restore methods in RepositoryManagementMBean
> --
>
> Key: OAK-5040
> URL: https://issues.apache.org/jira/browse/OAK-5040
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
> Fix For: 1.5.13
>
>
> The two operations: {{startBackup()}} and {{startRestore()}} exposed by 
> {{RepositoryManagementMBean}} throw an error when accessed:
> {{Cannot perform operation: no service of type FileStoreBackupRestoreMBean 
> found.}}
> Since this functionality is seldom used, these two methods should be removed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OAK-5040) Remove backup/restore methods in RepositoryManagementMBean

[Andrei Dulceanu (JIRA)]

Andrei Dulceanu created OAK-5040:


 Summary: Remove backup/restore methods in RepositoryManagementMBean
 Key: OAK-5040
 URL: https://issues.apache.org/jira/browse/OAK-5040
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: segment-tar
Reporter: Andrei Dulceanu
Assignee: Andrei Dulceanu
Priority: Minor
 Fix For: 1.5.13


The two operations: {{startBackup()}} and {{startRestore()}} exposed by 
{{RepositoryManagementMBean}} throw an error when accessed:
{{Cannot perform operation: no service of type FileStoreBackupRestoreMBean 
found.}}
Since this functionality is seldom used, these two methods should be removed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (OAK-5035) Implement mini-benchmark for PersistentCache

[JIRA]

[ 
https://issues.apache.org/jira/browse/OAK-5035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15621791#comment-15621791
 ] 

Tomek Rękawek edited comment on OAK-5035 at 10/31/16 3:13 PM:
--

Fixed for trunk in [r1767237|https://svn.apache.org/r1767237], 
[r1767302|https://svn.apache.org/r1767302].


was (Author: tomek.rekawek):
Fixed for trunk in [r1767237|https://svn.apache.org/r1767237].

> Implement mini-benchmark for PersistentCache
> 
>
> Key: OAK-5035
> URL: https://issues.apache.org/jira/browse/OAK-5035
> Project: Jackrabbit Oak
>  Issue Type: Sub-task
>  Components: cache, documentmk
>Reporter: Tomek Rękawek
>Assignee: Tomek Rękawek
> Fix For: 1.6, 1.5.13
>
>
> In order to test OAK-4882 and OAK-2761 in a reliable way, we need to have a 
> tool that is able to reproduce the issue reported there.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OAK-5039) Change globbing definition of GlobbingPathFilter

[Stefan Egli (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-5039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Egli updated OAK-5039:
-
Description: 
In order to satisfy OAK-5019 (and thus SLING-6174) the definition of 
[GlobbingPathFilter|https://jackrabbit.apache.org/oak/docs/apidocs/org/apache/jackrabbit/oak/plugins/observation/filter/GlobbingPathFilter.html]
 needs to be changed wrt the following:
* old: {{* matches every path containing a single element}}
* new: {{* matches character matches zero or more characters of a name 
component without crossing directory boundaries}}

(and derived definition is hence adjusted accordingly to match above change)

This change will basically allow to match eg
* {noformat}*.*{noformat}
* {noformat}*.html{noformat}

and not only arbitrarily named path elements.

  was:
In order to satisfy OAK-5019 (and thus SLING-6174) the definition of 
[GlobbingPathFilter|https://jackrabbit.apache.org/oak/docs/apidocs/org/apache/jackrabbit/oak/plugins/observation/filter/GlobbingPathFilter.html]
 needs to be changed wrt the following:
* old: {{* matches every path containing a single element}}
* new: {{* matches character matches zero or more characters of a name 
component without crossing directory boundaries}}

(and derived definition is hence adjusted accordingly to match above change)

This change will basically allow to match eg {{*.*}} or {{*.html}} and not only 
arbitrarily named path elements.


> Change globbing definition of GlobbingPathFilter
> 
>
> Key: OAK-5039
> URL: https://issues.apache.org/jira/browse/OAK-5039
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: core
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: 1.5.13
>
>
> In order to satisfy OAK-5019 (and thus SLING-6174) the definition of 
> [GlobbingPathFilter|https://jackrabbit.apache.org/oak/docs/apidocs/org/apache/jackrabbit/oak/plugins/observation/filter/GlobbingPathFilter.html]
>  needs to be changed wrt the following:
> * old: {{* matches every path containing a single element}}
> * new: {{* matches character matches zero or more characters of a name 
> component without crossing directory boundaries}}
> (and derived definition is hence adjusted accordingly to match above change)
> This change will basically allow to match eg
> * {noformat}*.*{noformat}
> * {noformat}*.html{noformat}
> and not only arbitrarily named path elements.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-5021) Improve observation of files

[Stefan Egli (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-5021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622418#comment-15622418
 ] 

Stefan Egli commented on OAK-5021:
--

Ok, [informed the list|http://oak.markmail.org/thread/wevg2qhvbpp3xhyn] and 
created OAK-5039 to follow up

> Improve observation of files
> 
>
> Key: OAK-5021
> URL: https://issues.apache.org/jira/browse/OAK-5021
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: jcr
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>
> (Originally reported as JCR-4046, but moved to Oak as a result of introducing 
> the OakEventFilter in OAK-5013. From the original description: )
> A file in JCR is represented by at least two nodes, the nt:file node and a 
> child node named jcr:content holding the contents of the file (and metadata).
> This has the consequence that if the contents of a file changes, a change 
> event of the jcr:content node is reported - but not of the nt:file node.
> This makes creating listeners listening for changes in files complicated, as 
> you can't use the file name to filter  - especially with glob patterns (see 
> JCR-4044 - now OAK-5019) this becomes troublesome.
> In addition, whenever you get a change for a jcr:content node, you have to 
> check if the parent is a nt:file node and decide based on the result.
> It would be great to have a flag on the JackrabbitEventFilter to enable 
> smarter reporting just for nt:files: if a property on jcr:content is changed, 
> a change to the nt:file node is reported.
> See also SLING-6163 and OAK-4940
> /cc [~cziegeler]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OAK-5039) Change globbing definition of GlobbingPathFilter

[Stefan Egli (JIRA)]

Stefan Egli created OAK-5039:


 Summary: Change globbing definition of GlobbingPathFilter
 Key: OAK-5039
 URL: https://issues.apache.org/jira/browse/OAK-5039
 Project: Jackrabbit Oak
  Issue Type: Task
  Components: core
Affects Versions: 1.5.12
Reporter: Stefan Egli
Assignee: Stefan Egli
 Fix For: 1.5.13


In order to satisfy OAK-5019 (and thus SLING-6174) the definition of 
[GlobbingPathFilter|https://jackrabbit.apache.org/oak/docs/apidocs/org/apache/jackrabbit/oak/plugins/observation/filter/GlobbingPathFilter.html]
 needs to be changed wrt the following:
* old: {{* matches every path containing a single element}}
* new: {{* matches character matches zero or more characters of a name 
component without crossing directory boundaries}}

(and derived definition is hence adjusted accordingly to match above change)

This change will basically allow to match eg {{*.*}} or {{*.html}} and not only 
arbitrarily named path elements.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OAK-5038) Extend PersistentCacheStats with async queue-related stats

[JIRA]

 [ 
https://issues.apache.org/jira/browse/OAK-5038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tomek Rękawek updated OAK-5038:
---
Description: 
In order to measure how many put() operations are rejected after implementing 
OAK-4882 we need to gather three new stats:

* put entries rejected because they have been already read from the persistence 
cache,
* put entries rejected because they were not used,
* put entries rejected because the queue is full.

The new stats should be disabled by default and enabled by 
{{PersistentCacheStats.rejectedPut}}.

  was:
In order to measure how many put() operations are rejected after implementing 
OAK-4882 we need to gather two new stats:

* put entries rejected by the heuristics,
* put entries rejected because the queue is full.

The new stats should be disabled by default and enabled by 
{{PersistentCacheStats.rejectedPut}}.


> Extend PersistentCacheStats with async queue-related stats
> --
>
> Key: OAK-5038
> URL: https://issues.apache.org/jira/browse/OAK-5038
> Project: Jackrabbit Oak
>  Issue Type: Sub-task
>  Components: cache, documentmk
>Reporter: Tomek Rękawek
> Fix For: 1.6, 1.5.13
>
>
> In order to measure how many put() operations are rejected after implementing 
> OAK-4882 we need to gather three new stats:
> * put entries rejected because they have been already read from the 
> persistence cache,
> * put entries rejected because they were not used,
> * put entries rejected because the queue is full.
> The new stats should be disabled by default and enabled by 
> {{PersistentCacheStats.rejectedPut}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OAK-4861) AsyncIndexUpdate consuming constantly 1 CPU core

[angela (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela updated OAK-4861:

Component/s: query

> AsyncIndexUpdate consuming constantly 1 CPU core
> 
>
> Key: OAK-4861
> URL: https://issues.apache.org/jira/browse/OAK-4861
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: query
>Affects Versions: 1.0.31
>Reporter: Jörg Hoh
>
> The AsyncIndexUpdate thread takes a long time on some of our environments to 
> update the index for a few nodes:
> {noformat}
> 28.09.2016 18:23:49.405 *DEBUG* [pool-11-thread-1] 
> org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate AsyncIndex (async) 
> update run completed in 3,369 min. Indexed 14 nodes
> {noformat}
> I set the log to DEBUG for investigation and during the time I saw constantly 
> such times; this instance is a test instance and there was no activity from 
> the outside during this time. I also can confirm such times from other 
> environments.
> The immediately visible problem is that this instance (and others as well) 
> constantly consume at least 1 CPU core, no matter what activity happens on 
> the system. This only happens on the master node of our DocumentNodeStore 
> clusters. 
> I did a number of threaddumps during investigation and a common stacktrace 
> for the AsyncIndexUpdate was like this:
> {noformat}
> 3XMTHREADINFO "pool-11-thread-1" J9VMThread:0x01E69C00, 
> j9thread_t:0x7FFFBE101CB0, java/lang/Thread:0x0001077FE938, state:R, 
> prio=5
> 3XMJAVALTHREAD (java/lang/Thread getId:0x10A, isDaemon:false)
> 3XMTHREADINFO1 (native thread ID:0x3C781, native priority:0x5, native 
> policy:UNKNOWN, vmstate:CW, vm thread flags:0x0001)
> 3XMTHREADINFO2 (native stack address range from:0x7FFFC696A000, 
> to:0x7FFFC69AB000, size:0x41000)
> 3XMCPUTIME CPU usage total: 992425.397213554 secs, current 
> category="Application"
> 3XMHEAPALLOC Heap bytes allocated since last GC cycle=735893672 (0x2BDCD8A8)
> 3XMTHREADINFO3 Java callstack:
> 4XESTACKTRACE at 
> com/google/common/collect/Lists.newArrayList(Lists.java:128(Compiled Code))
> 4XESTACKTRACE at 
> org/apache/jackrabbit/oak/plugins/index/lucene/OakDirectory$OakIndexFile.(OakDirectory.java:255(Compiled
>  Code))
> 4XESTACKTRACE at 
> org/apache/jackrabbit/oak/plugins/index/lucene/OakDirectory$OakIndexFile.(OakDirectory.java:201(Compiled
>  Code))
> 4XESTACKTRACE at 
> org/apache/jackrabbit/oak/plugins/index/lucene/OakDirectory$OakIndexInput.(OakDirectory.java:400(Compiled
>  Code))
> 4XESTACKTRACE at 
> org/apache/jackrabbit/oak/plugins/index/lucene/OakDirectory$OakIndexInput.clone(OakDirectory.java:408(Compiled
>  Code))
> 4XESTACKTRACE at 
> org/apache/jackrabbit/oak/plugins/index/lucene/OakDirectory$OakIndexInput.clone(OakDirectory.java:384(Compiled
>  Code))
> 4XESTACKTRACE at 
> org/apache/lucene/store/Directory$SlicedIndexInput.clone(Directory.java:288(Compiled
>  Code))
> 4XESTACKTRACE at 
> org/apache/lucene/store/Directory$SlicedIndexInput.clone(Directory.java:269(Compiled
>  Code))
> 4XESTACKTRACE at 
> org/apache/lucene/codecs/BlockTreeTermsReader$FieldReader.(BlockTreeTermsReader.java:481(Compiled
>  Code))
> 4XESTACKTRACE at 
> org/apache/lucene/codecs/BlockTreeTermsReader.(BlockTreeTermsReader.java:176(Compiled
>  Code))
> 4XESTACKTRACE at 
> org/apache/lucene/codecs/lucene41/Lucene41PostingsFormat.fieldsProducer(Lucene41PostingsFormat.java:437(Compiled
>  Code))
> 4XESTACKTRACE at 
> org/apache/lucene/index/SegmentCoreReaders.(SegmentCoreReaders.java:116(Compiled
>  Code))
> 4XESTACKTRACE at 
> org/apache/lucene/index/SegmentReader.(SegmentReader.java:96(Compiled 
> Code))
> 4XESTACKTRACE at 
> org/apache/lucene/index/ReadersAndUpdates.getReader(ReadersAndUpdates.java:141(Compiled
>  Code))
> 4XESTACKTRACE at 
> org/apache/lucene/index/BufferedUpdatesStream.applyDeletesAndUpdates(BufferedUpdatesStream.java:279(Compiled
>  Code))
> 5XESTACKTRACE (entered lock: 
> org/apache/lucene/index/BufferedUpdatesStream@0x0002245B4100, entry 
> count: 1)
> 4XESTACKTRACE at 
> org/apache/lucene/index/IndexWriter.applyAllDeletesAndUpdates(IndexWriter.java:3191(Compiled
>  Code))
> 5XESTACKTRACE (entered lock: 
> org/apache/lucene/index/IndexWriter@0x0002245B4050, entry count: 3)
> 4XESTACKTRACE at 
> org/apache/lucene/index/IndexWriter.maybeApplyDeletes(IndexWriter.java:3182(Compiled
>  Code))
> 5XESTACKTRACE (entered lock: 
> org/apache/lucene/index/IndexWriter@0x0002245B4050, entry count: 2)
> 4XESTACKTRACE at 
> org/apache/lucene/index/IndexWriter.doFlush(IndexWriter.java:3155(Compiled 
> Code))
> 5XESTACKTRACE (entered lock: 
> org/apache/lucene/index/IndexWriter@0x0002245B4050, entry count: 1)
> 4XESTACKTRACE at 
> org/apache/lucene/index/IndexWriter.flush(IndexWriter.java:3123(Compiled 
> Code))
> 4XESTACKTRACE at 

[jira] [Commented] (OAK-4688) OSGi Bundle unable to start after 1.2.16 upgrade

[angela (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-4688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622374#comment-15622374
 ] 

angela commented on OAK-4688:
-

[~ronnyfm], I am sorry but this is the wrong place to report issues with AEM. 
May I kindly ask you provide a description on how to reproduce the issue with 
only Apache Jackrabbit Oak. If that's not possible you should reach out to the 
AEM support... in this case I would resolve this issue as incomplete.

> OSGi Bundle unable to start after 1.2.16 upgrade
> 
>
> Key: OAK-4688
> URL: https://issues.apache.org/jira/browse/OAK-4688
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: auth-external
>Affects Versions: 1.2.16
> Environment: AEM 6.1 with hotfix cq-6.1.0-hotfix-10832-1.0.zip
>Reporter: Ronny Fallas
>
> I was running AEM 6.1 with oak-auth-external 1.2.14, but after a hotfix was 
> installed with version 1.2.16 my bundle is unable to start.
> This dependency appears as unsolved:
> {code}org.apache.jackrabbit.oak.spi.security.authentication.external,version=[1.0,2)
>  -- Cannot be resolved{code}
> In fact, the version is now 2.0, as it appears in the exported packages in 
> the console:
> {code}org.apache.jackrabbit.oak.spi.security.authentication.external,version=2.0.0{code}
> I updated the *pom.xml* as follows, it doesn't work.
> {code:xml}
>   
> org.apache.jackrabbit
> oak-auth-external
> 1.2.16
> provided
> {code}
> Any ideas?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OAK-4688) OSGi Bundle unable to start after 1.2.16 upgrade

[angela (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela updated OAK-4688:

Component/s: auth-external

> OSGi Bundle unable to start after 1.2.16 upgrade
> 
>
> Key: OAK-4688
> URL: https://issues.apache.org/jira/browse/OAK-4688
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: auth-external
>Affects Versions: 1.2.16
> Environment: AEM 6.1 with hotfix cq-6.1.0-hotfix-10832-1.0.zip
>Reporter: Ronny Fallas
>
> I was running AEM 6.1 with oak-auth-external 1.2.14, but after a hotfix was 
> installed with version 1.2.16 my bundle is unable to start.
> This dependency appears as unsolved:
> {code}org.apache.jackrabbit.oak.spi.security.authentication.external,version=[1.0,2)
>  -- Cannot be resolved{code}
> In fact, the version is now 2.0, as it appears in the exported packages in 
> the console:
> {code}org.apache.jackrabbit.oak.spi.security.authentication.external,version=2.0.0{code}
> I updated the *pom.xml* as follows, it doesn't work.
> {code:xml}
>   
> org.apache.jackrabbit
> oak-auth-external
> 1.2.16
> provided
> {code}
> Any ideas?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OAK-4597) Improve test coverage of blob GC

[angela (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela updated OAK-4597:

Component/s: segment-tar
 documentmk

> Improve test coverage of blob GC
> 
>
> Key: OAK-4597
> URL: https://issues.apache.org/jira/browse/OAK-4597
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: documentmk, segment-tar
>Reporter: Amit Jain
>Assignee: Amit Jain
>
> More tests to improve test coverage of various aspects related to blob GC



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OAK-4911) Can not read node Property when move code into a Thread (Java)

[angela (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela updated OAK-4911:

Component/s: jcr

> Can not read node Property when move code into a Thread (Java)
> --
>
> Key: OAK-4911
> URL: https://issues.apache.org/jira/browse/OAK-4911
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Affects Versions: 1.3.10
> Environment: MAC OS X
>Reporter: amin zamani
> Attachments: JCROakTest.java, java-code.txt, mixin-definitions.cnd
>
>
> Hallo,
> we develop an application and everything is working as it should. We upload 
> documents and for each document a new preview file (node) should be 
> generated. It works well when we execute the code synchron. But because of 
> the fact that the generation of a preview file (like PDF format) can take 
> very long time we decided to move the preview generation code into a usual 
> java thread so that after the user is upload a document the website is 
> responding very quick and does not wait till the preview file is generated 
> but the preview file is generated parallel. 
> No the problem: As soon as I move the same code regarding to the preview file 
> generation into a usual thread (no modifications to the logic, only a thread 
> is bordered to it) suddenly the node path does not exist, this is the error:
> -
> Caused by: javax.jcr.PathNotFoundException: jcr:lastModifiedBy not found on 
> /jcr:system/jcr:versionStorage/7e/f8/5b/7ef85b25-4598-4476-82df-446eb3a08a90/1.0/jcr:frozenNode/jcr:content
>   at 
> org.apache.jackrabbit.oak.jcr.session.NodeImpl$11.perform(NodeImpl.java:631)
>   at 
> org.apache.jackrabbit.oak.jcr.session.NodeImpl$11.perform(NodeImpl.java:625)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:207)
>   at 
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.perform(ItemImpl.java:112)
>   at 
> org.apache.jackrabbit.oak.jcr.session.NodeImpl.getProperty(NodeImpl.java:625)
>   at 
> com.westernacher.noah.util.content_repository.JcrUtil.getStringProperty(JcrUtil.java:35)
> ---
> In my point of view this is a bug. This is the code that works:
> Example:
> /// 1) User Upload document through browser in our web app..
> // 2) ... document uploaded and saved in OAK CR
> // 3) Now generate the preview:
> updateDocumentPreview(documentId);
> 
> Now the same in a thread that does not work:
> => I have only moved the method "updateDocumentPreview(documentId);" in a 
> Thread (Java 8):
> //Same code as before except the last line replaced by following lines:
> Runnable run = ()-> {updateDocumentPreview(documentId);}
> new Thread(run).start(); //Start the thread to generate a document preview
> --



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OAK-5006) Persistent cache: improve concurrency

[angela (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-5006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela updated OAK-5006:

Component/s: documentmk

> Persistent cache: improve concurrency
> -
>
> Key: OAK-5006
> URL: https://issues.apache.org/jira/browse/OAK-5006
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: documentmk
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
> Fix For: 1.6
>
>
> In some highly concurrent benchmarks (100 threads or so), the persistent 
> cache is sometimes blocked, mainly in the (in-memory) cache. This should be 
> resolved. One problem seems to be fixed in a newer version of the MVStore 
> (the "file system cache"), and the other cache bottleneck should be solved 
> using a config option for the segmentCount.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OAK-4508) LoggingDocumentStore: better support for multple instances

[angela (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela updated OAK-4508:

Component/s: documentmk

> LoggingDocumentStore: better support for multple instances
> --
>
> Key: OAK-4508
> URL: https://issues.apache.org/jira/browse/OAK-4508
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: documentmk
>Reporter: Julian Reschke
>Priority: Minor
>
> It would be cool if the logging could be configured to use a specific prefix 
> instead of "ds." - this would make it more useful when debugging code that 
> involves two different ds instances in the same VM.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OAK-4912) MongoDB: ReadPreferenceIT.testMongoReadPreferencesForLocalChanges() ocasionally fails

[angela (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela updated OAK-4912:

Component/s: documentmk

> MongoDB: ReadPreferenceIT.testMongoReadPreferencesForLocalChanges() 
> ocasionally fails
> -
>
> Key: OAK-4912
> URL: https://issues.apache.org/jira/browse/OAK-4912
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: documentmk
>Reporter: Julian Reschke
>Priority: Minor
>
> {noformat}
> testMongoReadPreferencesForLocalChanges(org.apache.jackrabbit.oak.plugins.document.mongo.ReadPreferenceIT)
>   Time elapsed: 0.024 sec  <<< FAILURE!
> java.lang.AssertionError: expected: but was:
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at 
> org.apache.jackrabbit.oak.plugins.document.mongo.ReadPreferenceIT.testMongoReadPreferencesForLocalChanges(ReadPreferenceIT.java:195)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-5022) add includeSubtreeOnDelete flag to OakEventFilter

[Stefan Egli (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-5022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622353#comment-15622353
 ] 

Stefan Egli commented on OAK-5022:
--

Added main implementation 
[here|http://svn.apache.org/viewvc?rev=1767295&view=rev], this introduces:
{code}
public abstract OakEventFilter withIncludeSubtreeOnRemove();
{code}
to the OakEventFilter and does not do a {{deleteSubtree()}} as is otherwise the 
default (ie includes the deleted node of a subtree-removal)

> add includeSubtreeOnDelete flag to OakEventFilter
> -
>
> Key: OAK-5022
> URL: https://issues.apache.org/jira/browse/OAK-5022
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: jcr
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>
> (Originally reported as JCR-4037, but moved to Oak as a result of introducing 
> the OakEventFilter in OAK-5013. From the original description: )
> In some cases of observation it would be useful to receive events of child 
> node or properties of a parent/grandparent that was deleted. Currently (in 
> Oak at least) one only receives a deleted event for the node that was deleted 
> and none of the children.
> Suggesting to (re)introduce a flag, eg as follows to the 
> JackrabbitEventFilter:
> {code}
> boolean includeSubtreeOnRemove;
> {code}
> (Open for any better name of course)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OAK-5037) Update Oak 1.2 and Oak 1.4 to Jackrabbit 2.12.5

[angela (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-5037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela updated OAK-5037:

Component/s: parent

> Update Oak 1.2 and Oak 1.4 to Jackrabbit 2.12.5
> ---
>
> Key: OAK-5037
> URL: https://issues.apache.org/jira/browse/OAK-5037
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: parent
>Affects Versions: 1.2.20, 1.4.9
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OAK-4773) OakAsync0001: Concurrent update detected

[angela (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela updated OAK-4773:

Component/s: query
 core

> OakAsync0001: Concurrent update detected
> 
>
> Key: OAK-4773
> URL: https://issues.apache.org/jira/browse/OAK-4773
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: core, query
>Reporter: jhonny Villarroel
>
> Getting following  log in version oak 1.3.16 :
> WARN  [2016-09-07 23:09:05,573] 
> org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate: [async] The index 
> update failed
> ! org.apache.jackrabbit.oak.api.CommitFailedException: OakAsync0001: 
> Concurrent update detected
> ! at 
> org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate.(AsyncIndexUpdate.java:93)
> ! at org.apache.jackrabbit.oak.Oak.createNewContentRepository(Oak.java:649)
> ! at org.apache.jackrabbit.oak.Oak.createContentRepository(Oak.java:623)
> ! at org.apache.jackrabbit.oak.jcr.Jcr.createContentRepository(Jcr.java:372)
> ! at org.apache.jackrabbit.oak.jcr.Jcr.createRepository(Jcr.java:380)
> ! at 
> com.dharbor.dms.repository.impl.RepositoryManagerImpl.createRepository(RepositoryManagerImpl.java:100)
> ! at 
> com.dharbor.dms.repository.impl.RepositoryManagerImpl.start(RepositoryManagerImpl.java:76)
> ! at 
> com.dharbor.dms.repository.impl.RepositoryManagerImpl.(RepositoryManagerImpl.java:423)
> ! at 
> com.dharbor.dms.repository.impl.DMSRAOFactory.getRepositoryManager(DMSRAOFactory.java:36)
> ! at 
> com.dharbor.dms.repository.impl.MetaDataRAOImpl.(MetaDataRAOImpl.java:63)
> ! at 
> com.dharbor.dms.repository.impl.MetaDataRAOImpl.(MetaDataRAOImpl.java:65)
> ! at 
> com.dharbor.dms.repository.impl.DMSRAOFactory.getMetaDataRaoInstance(DMSRAOFactory.java:30)
> ! at 
> com.dharbor.dms.content.impl.MetaDataServiceImpl.createMetadata(MetaDataServiceImpl.java:54)
> ! at 
> com.dharbor.dms.content.impl.ContentManagerImpl.createMetadata(ContentManagerImpl.java:52)
> ! at 
> com.dharbor.rest.handler.impl.UploadActionHandler.handle(UploadActionHandler.java:60)
> ! at 
> com.dharbor.rest.facade.DmsServiceFacade.executeAction(DmsServiceFacade.java:165)
> ! at 
> com.dharbor.dms.services.impl.JackrabbitCoreAdapter.save(JackrabbitCoreAdapter.java:54)
> ! at 
> com.dharbor.dms.restws.impl.FileResourceImpl.uploadFile(FileResourceImpl.java:72)
> ! 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.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
> ! at 
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144)
> ! at 
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161)
> ! at 
> org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:160)
> ! at 
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99)
> ! at 
> org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:389)
> ! at 
> org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:347)
> ! at 
> org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)
> ! at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:326)
> ! at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
> ! at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
> ! at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
> ! at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
> ! at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
> ! at 
> org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
> ! at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:305)
> ! at 
> org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1154)
> ! at 
> org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:473)
> ! at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:427)
> ! at 
> org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:388)
> ! at 
> org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:341)
> ! at 
> org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:228)
> !

[jira] [Updated] (OAK-4125) Test failure: testUpdateAndDelete [MyFixture: RDB-Derby(embedded)]

[angela (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela updated OAK-4125:

Component/s: rdbmk

> Test failure: testUpdateAndDelete [MyFixture: RDB-Derby(embedded)]
> --
>
> Key: OAK-4125
> URL: https://issues.apache.org/jira/browse/OAK-4125
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: rdbmk
>Affects Versions: 1.2.12, 1.0.28, 1.4.0
>Reporter: Davide Giannella
>Assignee: Julian Reschke
> Fix For: 1.6
>
>
> Test is randomly failing on jenkins. See epic for list of failed builds. Both 
> trunk and 1.4.
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/785/
> {noformat}
> Test results:
> 1 tests failed.
> FAILED:  
> org.apache.jackrabbit.oak.plugins.document.blob.RDBBlobStoreTest.testUpdateAndDelete[MyFixture:
>  RDB-Derby(embedded)]
> Error Message:
> null
> Stack Trace:
> java.lang.AssertionError
>   at org.junit.Assert.fail(Assert.java:86)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at org.junit.Assert.assertFalse(Assert.java:64)
>   at org.junit.Assert.assertFalse(Assert.java:74)
>   at 
> org.apache.jackrabbit.oak.plugins.document.blob.RDBBlobStoreTest.testUpdateAndDelete(RDBBlobStoreTest.java:187)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   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.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.junit.runners.Suite.runChild(Suite.java:128)
>   at org.junit.runners.Suite.runChild(Suite.java:27)
>   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:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   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)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OAK-4778) OakServlet does not handle properly JCR_PRIMARYTYPE

[angela (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela updated OAK-4778:

Component/s: webapp

> OakServlet does not handle properly JCR_PRIMARYTYPE
> ---
>
> Key: OAK-4778
> URL: https://issues.apache.org/jira/browse/OAK-4778
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: webapp
>Reporter: Andrei Dulceanu
>
> The example at [1] contains the following snippet which currently does not 
> work as expected:
> {code}
> $ http -j -b localhost:8080/test \
>   jcr\\:primaryType=oak:Unstructured foo=abc bar:=123
> {
> "bar": "123",
> "foo": "abc",
> "jcr:primaryType": "oak:Unstructured"
> }
> {code}
> [~alexparvulescu] already provided a fix for this special case at [2].
> [1] https://github.com/apache/jackrabbit-oak/tree/trunk/oak-http
> [2] 
> https://github.com/stillalex/jackrabbit-oak/commit/70c9f71f180c3f5c6f0c436ef943f006a297



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (OAK-4965) Cold standby logs SNFE ERROR

[Andrei Dulceanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-4965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622320#comment-15622320
 ] 

Andrei Dulceanu edited comment on OAK-4965 at 10/31/16 2:34 PM:


Following [~mduerig]'s latest suggestion, I created a 
{{SegmentNotFoundExceptionHandler}} which has two different implementations, 
based on the type of {{FileStore}}: {{primary}} or {{standby}}. The first logs 
each {{SegmentNotFoundException}}, while the latter does nothing, since these 
exceptions are something expected for the {{standby}} instance, while loading 
the segment hierarchy from {{primary}}.

[~mduerig], [~frm], could one of you take a look at the patch?


was (Author: dulceanu):
Following [~mduerig]'s latest suggestion, I created a 
{{SegmentNotFoundExceptionHandler}} which has two different implementations, 
based on the type of {{FileStore}}: {{primary}} or {{standby}}. The first logs 
each {{SegmentNotFoundException}}, while the latter does nothing, since 
{{SegmentNotFoundException}}s are something expected for the {{standby}} 
instance, while loading the segment hierarchy from {{primary}}.

[~mduerig], [~frm], could one of you take a look at the patch?

> Cold standby logs SNFE ERROR
> 
>
> Key: OAK-4965
> URL: https://issues.apache.org/jira/browse/OAK-4965
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: segment-tar
>Affects Versions: Segment Tar 0.0.14
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
> Fix For: 1.6, 1.5.13
>
> Attachments: OAK-4965-01.patch
>
>
> On coldstandby, there are a lot of occurences of SNFE:
> {code}
> 200766 04.10.2016 14:29:52.657 *ERROR* [sling-default-16-Registered 
> Service.577] org.apache.jackrabbit.oak.segment.SegmentId Segment not found: 
> 19d493e3-8bad-4124-a962-5388d91f560e. SegmentId age=0ms
> 200767 org.apache.jackrabbit.oak.segment.SegmentNotFoundException: Segment 
> 19d493e3-8bad-4124-a962-5388d91f560e not found
> 200768 at 
> org.apache.jackrabbit.oak.segment.file.FileStore$14.call(FileStore.java:1345)
> 200769 at 
> org.apache.jackrabbit.oak.segment.file.FileStore$14.call(FileStore.java:1285)
> 200770 at 
> org.apache.jackrabbit.oak.cache.CacheLIRS$Segment.load(CacheLIRS.java:1013)
> 200771 at 
> org.apache.jackrabbit.oak.cache.CacheLIRS$Segment.get(CacheLIRS.java:974)
> 200772 at 
> org.apache.jackrabbit.oak.cache.CacheLIRS.get(CacheLIRS.java:285)
> 200773 at 
> org.apache.jackrabbit.oak.segment.SegmentCache.getSegment(SegmentCache.java:92)
> 200774 at 
> org.apache.jackrabbit.oak.segment.file.FileStore.readSegment(FileStore.java:1285)
> 200775 at 
> org.apache.jackrabbit.oak.segment.SegmentId.getSegment(SegmentId.java:123)
> 200776 at 
> org.apache.jackrabbit.oak.segment.Record.getSegment(Record.java:70)
> 200777 at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.getStableIdBytes(SegmentNodeState.java:139)
> 200778 at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.getStableId(SegmentNodeState.java:122)
> 200779 at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.fastEquals(SegmentNodeState.java:633)
> 200780 at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:459)
> 200781 at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.compareAgainstBaseState(StandbyClientSyncExecution.java:100)
> 200782 at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.execute(StandbyClientSyncExecution.java:80)
> 200783 at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync.run(StandbyClientSync.java:143)
> 200784 at 
> org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:118)
> 200785 at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
> 200786 at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> 200787 at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> 200788 at java.lang.Thread.run(Thread.java:745)
> 200789 04.10.2016 14:29:52.657 *INFO* [sling-default-16-Registered 
> Service.577] 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution 
> Found missing segment 19d493e3-8bad-4124-a962-5388d91f560e
> 200790 04.10.2016 14:29:52.657 *INFO* [sling-default-16-Registered 
> Service.577] 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution 
> Loading segment 19d493e3-8bad-4124-a962-5388d91f560e
> 200791 04.10.2016 14:29:52.657 *DEBUG* [nioEventLoopGroup-208-1] 
> org.apache.jackrabbit.oak.segment.standby.codec.GetSegmentRequestEncoder 
> Sending reque

[jira] [Updated] (OAK-4965) Cold standby logs SNFE ERROR

[Andrei Dulceanu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-4965:
-
Attachment: OAK-4965-01.patch

Following [~mduerig]'s latest suggestion, I created a 
{{SegmentNotFoundExceptionHandler}} which has two different implementations, 
based on the type of {{FileStore}}: {{primary}} or {{standby}}. The first logs 
each {{SegmentNotFoundException}}, while the latter does nothing, since 
{{SegmentNotFoundException}}s are something expected for the {{standby}} 
instance, while loading the segment hierarchy from {{primary}}.

[~mduerig], [~frm], could one of you take a look at the patch?

> Cold standby logs SNFE ERROR
> 
>
> Key: OAK-4965
> URL: https://issues.apache.org/jira/browse/OAK-4965
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: segment-tar
>Affects Versions: Segment Tar 0.0.14
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
> Fix For: 1.6, 1.5.13
>
> Attachments: OAK-4965-01.patch
>
>
> On coldstandby, there are a lot of occurences of SNFE:
> {code}
> 200766 04.10.2016 14:29:52.657 *ERROR* [sling-default-16-Registered 
> Service.577] org.apache.jackrabbit.oak.segment.SegmentId Segment not found: 
> 19d493e3-8bad-4124-a962-5388d91f560e. SegmentId age=0ms
> 200767 org.apache.jackrabbit.oak.segment.SegmentNotFoundException: Segment 
> 19d493e3-8bad-4124-a962-5388d91f560e not found
> 200768 at 
> org.apache.jackrabbit.oak.segment.file.FileStore$14.call(FileStore.java:1345)
> 200769 at 
> org.apache.jackrabbit.oak.segment.file.FileStore$14.call(FileStore.java:1285)
> 200770 at 
> org.apache.jackrabbit.oak.cache.CacheLIRS$Segment.load(CacheLIRS.java:1013)
> 200771 at 
> org.apache.jackrabbit.oak.cache.CacheLIRS$Segment.get(CacheLIRS.java:974)
> 200772 at 
> org.apache.jackrabbit.oak.cache.CacheLIRS.get(CacheLIRS.java:285)
> 200773 at 
> org.apache.jackrabbit.oak.segment.SegmentCache.getSegment(SegmentCache.java:92)
> 200774 at 
> org.apache.jackrabbit.oak.segment.file.FileStore.readSegment(FileStore.java:1285)
> 200775 at 
> org.apache.jackrabbit.oak.segment.SegmentId.getSegment(SegmentId.java:123)
> 200776 at 
> org.apache.jackrabbit.oak.segment.Record.getSegment(Record.java:70)
> 200777 at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.getStableIdBytes(SegmentNodeState.java:139)
> 200778 at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.getStableId(SegmentNodeState.java:122)
> 200779 at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.fastEquals(SegmentNodeState.java:633)
> 200780 at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:459)
> 200781 at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.compareAgainstBaseState(StandbyClientSyncExecution.java:100)
> 200782 at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.execute(StandbyClientSyncExecution.java:80)
> 200783 at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync.run(StandbyClientSync.java:143)
> 200784 at 
> org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:118)
> 200785 at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
> 200786 at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> 200787 at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> 200788 at java.lang.Thread.run(Thread.java:745)
> 200789 04.10.2016 14:29:52.657 *INFO* [sling-default-16-Registered 
> Service.577] 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution 
> Found missing segment 19d493e3-8bad-4124-a962-5388d91f560e
> 200790 04.10.2016 14:29:52.657 *INFO* [sling-default-16-Registered 
> Service.577] 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution 
> Loading segment 19d493e3-8bad-4124-a962-5388d91f560e
> 200791 04.10.2016 14:29:52.657 *DEBUG* [nioEventLoopGroup-208-1] 
> org.apache.jackrabbit.oak.segment.standby.codec.GetSegmentRequestEncoder 
> Sending request from client qastandby1 for segment 
> 19d493e3-8bad-4124-a962-5388d91f560e
> {code}
> While these are false positives (the segment is found later), we need to find 
> a way to avoid logging the errors. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-5020) Improved support for node removals

[Stefan Egli (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-5020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622305#comment-15622305
 ] 

Stefan Egli commented on OAK-5020:
--

Main implementation added 
[here|http://svn.apache.org/viewvc?rev=1767287&view=rev], this introduces:
{code}
public abstract OakEventFilter withIncludeAncestorsRemove();
{code}
to the OakEventFilter.
More work will be necessary with addition of OAK-5019 etc so leaving ticket 
open.

> Improved support for node removals
> --
>
> Key: OAK-5020
> URL: https://issues.apache.org/jira/browse/OAK-5020
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: jcr
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>
> (Originally reported as JCR-4045, but moved to Oak as a result of introducing 
> the OakEventFilter in OAK-5013. From the original description: )
> If a listener is subscribed for removal events of a subtree, e.g. /a/b/c/d it 
> gets removal events for everything in that three.
> However, if /a/b is removed, the listener is not informed at all, which makes 
> the listener state inconsistent/invalid
> I suggest to add a new flag to the JackrabbitEventFilter and if that is 
> enabled the listener will get remove events of all the parent nodes - if the 
> listener is interested in remove events of any kind.
> /cc [~cziegeler]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OAK-5038) Extend PersistentCacheStats with async queue-related stats

[JIRA]

Tomek Rękawek created OAK-5038:
--

 Summary: Extend PersistentCacheStats with async queue-related stats
 Key: OAK-5038
 URL: https://issues.apache.org/jira/browse/OAK-5038
 Project: Jackrabbit Oak
  Issue Type: Sub-task
  Components: cache, documentmk
Reporter: Tomek Rękawek


In order to measure how many put() operations are rejected after implementing 
OAK-4882 we need to gather two new stats:

* put entries rejected by the heuristics,
* put entries rejected because the queue is full.

The new stats should be disabled by default and enabled by 
{{PersistentCacheStats.rejectedPut}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (OAK-4969) ColdStandby does not fetch missing blobs

[Francesco Mari (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francesco Mari resolved OAK-4969.
-
Resolution: Fixed

> ColdStandby does not fetch missing blobs
> 
>
> Key: OAK-4969
> URL: https://issues.apache.org/jira/browse/OAK-4969
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: segment-tar, segmentmk
>Affects Versions: Segment Tar 0.0.10
>Reporter: Timothee Maret
>Assignee: Francesco Mari
> Fix For: 1.6, 1.2.21, 1.5.13, 1.4.10, 1.4, 1.2
>
> Attachments: OAK-4969-oak-tarmk-standby.patch, OAK-4969.patch
>
>
> 1. In a setup composed of two instances (primary, standby) configured with a 
> custom blob store (File blob store).
> 2. On the primary instance, set/update a BINARY property of an existing 
> resource with > 2MB binary.
> 3. Observe that the standby instance does not fetch the binary and instead, 
> enters a loop detecting the missing binary upon comparing node states.
> For example, the following stack trace would be printed every 5 seconds on 
> the standby (the polling time is 5sec). 
> {code}
> 19.10.2016 16:22:38.035 *DEBUG* [nioEventLoopGroup-1005-1] 
> org.apache.jackrabbit.oak.segment.standby.codec.ResponseDecoder Decoding 'get 
> head' response
> 19.10.2016 16:22:38.038 *DEBUG* [sling-default-81-Registered Service.607] 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Channel closed
> 19.10.2016 16:22:40.241 *DEBUG* [sling-default-81-Registered Service.607] 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Group shut down
> 19.10.2016 16:22:40.242 *ERROR* [sling-default-81-Registered Service.607] 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync Failed 
> synchronizing state.
> java.lang.RuntimeException: Error occurred while obtaining InputStream for 
> blobId [4dfc748c91d518c9221031ec6115fd7ac04fe27b#10]
>   at 
> org.apache.jackrabbit.oak.plugins.blob.BlobStoreBlob.getNewStream(BlobStoreBlob.java:49)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:252)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:87)
>   at 
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:45)
>   at 
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:42)
>   at com.google.common.io.ByteStreams$3.openStream(ByteStreams.java:907)
>   at com.google.common.io.ByteSource.contentEquals(ByteSource.java:301)
>   at com.google.common.io.ByteStreams.equal(ByteStreams.java:661)
>   at 
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob.equal(AbstractBlob.java:68)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentBlob.equals(SegmentBlob.java:193)
>   at com.google.common.base.Objects.equal(Objects.java:55)
>   at 
> org.apache.jackrabbit.oak.plugins.memory.AbstractPropertyState.equal(AbstractPropertyState.java:53)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentPropertyState.equals(SegmentPropertyState.java:249)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:622)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:516)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:415)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:457)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord$2.childNodeChanged(MapRecord.java:401)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord$3.childNodeChanged(MapRecord.java:442)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:485)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:433)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:3

[jira] [Updated] (OAK-4969) ColdStandby does not fetch missing blobs

[Francesco Mari (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francesco Mari updated OAK-4969:

Fix Version/s: 1.4.10
   1.2.21

> ColdStandby does not fetch missing blobs
> 
>
> Key: OAK-4969
> URL: https://issues.apache.org/jira/browse/OAK-4969
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: segment-tar, segmentmk
>Affects Versions: Segment Tar 0.0.10
>Reporter: Timothee Maret
>Assignee: Francesco Mari
> Fix For: 1.2, 1.4, 1.6, 1.2.21, 1.5.13, 1.4.10
>
> Attachments: OAK-4969-oak-tarmk-standby.patch, OAK-4969.patch
>
>
> 1. In a setup composed of two instances (primary, standby) configured with a 
> custom blob store (File blob store).
> 2. On the primary instance, set/update a BINARY property of an existing 
> resource with > 2MB binary.
> 3. Observe that the standby instance does not fetch the binary and instead, 
> enters a loop detecting the missing binary upon comparing node states.
> For example, the following stack trace would be printed every 5 seconds on 
> the standby (the polling time is 5sec). 
> {code}
> 19.10.2016 16:22:38.035 *DEBUG* [nioEventLoopGroup-1005-1] 
> org.apache.jackrabbit.oak.segment.standby.codec.ResponseDecoder Decoding 'get 
> head' response
> 19.10.2016 16:22:38.038 *DEBUG* [sling-default-81-Registered Service.607] 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Channel closed
> 19.10.2016 16:22:40.241 *DEBUG* [sling-default-81-Registered Service.607] 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Group shut down
> 19.10.2016 16:22:40.242 *ERROR* [sling-default-81-Registered Service.607] 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync Failed 
> synchronizing state.
> java.lang.RuntimeException: Error occurred while obtaining InputStream for 
> blobId [4dfc748c91d518c9221031ec6115fd7ac04fe27b#10]
>   at 
> org.apache.jackrabbit.oak.plugins.blob.BlobStoreBlob.getNewStream(BlobStoreBlob.java:49)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:252)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:87)
>   at 
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:45)
>   at 
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:42)
>   at com.google.common.io.ByteStreams$3.openStream(ByteStreams.java:907)
>   at com.google.common.io.ByteSource.contentEquals(ByteSource.java:301)
>   at com.google.common.io.ByteStreams.equal(ByteStreams.java:661)
>   at 
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob.equal(AbstractBlob.java:68)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentBlob.equals(SegmentBlob.java:193)
>   at com.google.common.base.Objects.equal(Objects.java:55)
>   at 
> org.apache.jackrabbit.oak.plugins.memory.AbstractPropertyState.equal(AbstractPropertyState.java:53)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentPropertyState.equals(SegmentPropertyState.java:249)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:622)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:516)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:415)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:457)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord$2.childNodeChanged(MapRecord.java:401)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord$3.childNodeChanged(MapRecord.java:442)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:485)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:433)
>   at 
> org.apache.jackrabbit.oak.segment.MapRec

[jira] [Commented] (OAK-4969) ColdStandby does not fetch missing blobs

[Francesco Mari (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622120#comment-15622120
 ] 

Francesco Mari commented on OAK-4969:
-

Fix for oak-tarmk-standby backported on 1.2 at r1767277.

> ColdStandby does not fetch missing blobs
> 
>
> Key: OAK-4969
> URL: https://issues.apache.org/jira/browse/OAK-4969
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: segment-tar, segmentmk
>Affects Versions: Segment Tar 0.0.10
>Reporter: Timothee Maret
>Assignee: Francesco Mari
> Fix For: 1.2, 1.4, 1.6, 1.5.13
>
> Attachments: OAK-4969-oak-tarmk-standby.patch, OAK-4969.patch
>
>
> 1. In a setup composed of two instances (primary, standby) configured with a 
> custom blob store (File blob store).
> 2. On the primary instance, set/update a BINARY property of an existing 
> resource with > 2MB binary.
> 3. Observe that the standby instance does not fetch the binary and instead, 
> enters a loop detecting the missing binary upon comparing node states.
> For example, the following stack trace would be printed every 5 seconds on 
> the standby (the polling time is 5sec). 
> {code}
> 19.10.2016 16:22:38.035 *DEBUG* [nioEventLoopGroup-1005-1] 
> org.apache.jackrabbit.oak.segment.standby.codec.ResponseDecoder Decoding 'get 
> head' response
> 19.10.2016 16:22:38.038 *DEBUG* [sling-default-81-Registered Service.607] 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Channel closed
> 19.10.2016 16:22:40.241 *DEBUG* [sling-default-81-Registered Service.607] 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Group shut down
> 19.10.2016 16:22:40.242 *ERROR* [sling-default-81-Registered Service.607] 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync Failed 
> synchronizing state.
> java.lang.RuntimeException: Error occurred while obtaining InputStream for 
> blobId [4dfc748c91d518c9221031ec6115fd7ac04fe27b#10]
>   at 
> org.apache.jackrabbit.oak.plugins.blob.BlobStoreBlob.getNewStream(BlobStoreBlob.java:49)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:252)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:87)
>   at 
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:45)
>   at 
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:42)
>   at com.google.common.io.ByteStreams$3.openStream(ByteStreams.java:907)
>   at com.google.common.io.ByteSource.contentEquals(ByteSource.java:301)
>   at com.google.common.io.ByteStreams.equal(ByteStreams.java:661)
>   at 
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob.equal(AbstractBlob.java:68)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentBlob.equals(SegmentBlob.java:193)
>   at com.google.common.base.Objects.equal(Objects.java:55)
>   at 
> org.apache.jackrabbit.oak.plugins.memory.AbstractPropertyState.equal(AbstractPropertyState.java:53)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentPropertyState.equals(SegmentPropertyState.java:249)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:622)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:516)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:415)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:457)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord$2.childNodeChanged(MapRecord.java:401)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord$3.childNodeChanged(MapRecord.java:442)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:485)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:433)
>  

[jira] [Commented] (OAK-4969) ColdStandby does not fetch missing blobs

[Francesco Mari (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622098#comment-15622098
 ] 

Francesco Mari commented on OAK-4969:
-

Fix for oak-tarmk-standby backported on 1.4 at r1767270.

> ColdStandby does not fetch missing blobs
> 
>
> Key: OAK-4969
> URL: https://issues.apache.org/jira/browse/OAK-4969
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: segment-tar, segmentmk
>Affects Versions: Segment Tar 0.0.10
>Reporter: Timothee Maret
>Assignee: Francesco Mari
> Fix For: 1.2, 1.4, 1.6, 1.5.13
>
> Attachments: OAK-4969-oak-tarmk-standby.patch, OAK-4969.patch
>
>
> 1. In a setup composed of two instances (primary, standby) configured with a 
> custom blob store (File blob store).
> 2. On the primary instance, set/update a BINARY property of an existing 
> resource with > 2MB binary.
> 3. Observe that the standby instance does not fetch the binary and instead, 
> enters a loop detecting the missing binary upon comparing node states.
> For example, the following stack trace would be printed every 5 seconds on 
> the standby (the polling time is 5sec). 
> {code}
> 19.10.2016 16:22:38.035 *DEBUG* [nioEventLoopGroup-1005-1] 
> org.apache.jackrabbit.oak.segment.standby.codec.ResponseDecoder Decoding 'get 
> head' response
> 19.10.2016 16:22:38.038 *DEBUG* [sling-default-81-Registered Service.607] 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Channel closed
> 19.10.2016 16:22:40.241 *DEBUG* [sling-default-81-Registered Service.607] 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Group shut down
> 19.10.2016 16:22:40.242 *ERROR* [sling-default-81-Registered Service.607] 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync Failed 
> synchronizing state.
> java.lang.RuntimeException: Error occurred while obtaining InputStream for 
> blobId [4dfc748c91d518c9221031ec6115fd7ac04fe27b#10]
>   at 
> org.apache.jackrabbit.oak.plugins.blob.BlobStoreBlob.getNewStream(BlobStoreBlob.java:49)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:252)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:87)
>   at 
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:45)
>   at 
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:42)
>   at com.google.common.io.ByteStreams$3.openStream(ByteStreams.java:907)
>   at com.google.common.io.ByteSource.contentEquals(ByteSource.java:301)
>   at com.google.common.io.ByteStreams.equal(ByteStreams.java:661)
>   at 
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob.equal(AbstractBlob.java:68)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentBlob.equals(SegmentBlob.java:193)
>   at com.google.common.base.Objects.equal(Objects.java:55)
>   at 
> org.apache.jackrabbit.oak.plugins.memory.AbstractPropertyState.equal(AbstractPropertyState.java:53)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentPropertyState.equals(SegmentPropertyState.java:249)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:622)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:516)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:415)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:457)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord$2.childNodeChanged(MapRecord.java:401)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord$3.childNodeChanged(MapRecord.java:442)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:485)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:433)
>  

[jira] [Updated] (OAK-5023) add applyNoteTypeOnSelf property to OakEventFilter

[Stefan Egli (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-5023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Egli updated OAK-5023:
-
Fix Version/s: 1.5.13

> add applyNoteTypeOnSelf property to OakEventFilter
> --
>
> Key: OAK-5023
> URL: https://issues.apache.org/jira/browse/OAK-5023
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: jcr
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: 1.5.13
>
>
> (Originally reported as JCR-4048, but moved to Oak as a result of introducing 
> the OakEventFilter in OAK-5013. From the original description: )
> There seems to be a rather frequent use case of observation around which 
> would like to create a filter on a _child_ rather than on a _parent_: 
> consider the case when you'd like to filter for the removal of a node that 
> has a particular nodeType. This can't be achieved atm as the nodeType is 
> applicable to the parent of the node that changes, not the node itself (ie 
> child).
> Therefore suggesting the introduction of a flag similar to the following:
> {code}
> boolean applyOnOwnNode;
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (OAK-5023) add applyNoteTypeOnSelf property to OakEventFilter

[Stefan Egli (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-5023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Egli resolved OAK-5023.
--
Resolution: Fixed

Introduced new switch on OakEventFilter 
[here|http://svn.apache.org/viewvc?rev=1767266&view=rev]:
{code}
public abstract OakEventFilter withApplyNodeTypeOnSelf();
{code}

> add applyNoteTypeOnSelf property to OakEventFilter
> --
>
> Key: OAK-5023
> URL: https://issues.apache.org/jira/browse/OAK-5023
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: jcr
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>
> (Originally reported as JCR-4048, but moved to Oak as a result of introducing 
> the OakEventFilter in OAK-5013. From the original description: )
> There seems to be a rather frequent use case of observation around which 
> would like to create a filter on a _child_ rather than on a _parent_: 
> consider the case when you'd like to filter for the removal of a node that 
> has a particular nodeType. This can't be achieved atm as the nodeType is 
> applicable to the parent of the node that changes, not the node itself (ie 
> child).
> Therefore suggesting the introduction of a flag similar to the following:
> {code}
> boolean applyOnOwnNode;
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OAK-5023) add applyNoteTypeOnSelf property to OakEventFilter

[Stefan Egli (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-5023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Egli updated OAK-5023:
-
Summary: add applyNoteTypeOnSelf property to OakEventFilter  (was: add 
applyOnOwnNode property to OakEventFilter)

> add applyNoteTypeOnSelf property to OakEventFilter
> --
>
> Key: OAK-5023
> URL: https://issues.apache.org/jira/browse/OAK-5023
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: jcr
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>
> (Originally reported as JCR-4048, but moved to Oak as a result of introducing 
> the OakEventFilter in OAK-5013. From the original description: )
> There seems to be a rather frequent use case of observation around which 
> would like to create a filter on a _child_ rather than on a _parent_: 
> consider the case when you'd like to filter for the removal of a node that 
> has a particular nodeType. This can't be achieved atm as the nodeType is 
> applicable to the parent of the node that changes, not the node itself (ie 
> child).
> Therefore suggesting the introduction of a flag similar to the following:
> {code}
> boolean applyOnOwnNode;
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-4969) ColdStandby does not fetch missing blobs

[Francesco Mari (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622068#comment-15622068
 ] 

Francesco Mari commented on OAK-4969:
-

Fixed for oak-tarmk-standby at r1767265.

> ColdStandby does not fetch missing blobs
> 
>
> Key: OAK-4969
> URL: https://issues.apache.org/jira/browse/OAK-4969
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: segment-tar, segmentmk
>Affects Versions: Segment Tar 0.0.10
>Reporter: Timothee Maret
>Assignee: Francesco Mari
> Fix For: 1.2, 1.4, 1.6, 1.5.13
>
> Attachments: OAK-4969-oak-tarmk-standby.patch, OAK-4969.patch
>
>
> 1. In a setup composed of two instances (primary, standby) configured with a 
> custom blob store (File blob store).
> 2. On the primary instance, set/update a BINARY property of an existing 
> resource with > 2MB binary.
> 3. Observe that the standby instance does not fetch the binary and instead, 
> enters a loop detecting the missing binary upon comparing node states.
> For example, the following stack trace would be printed every 5 seconds on 
> the standby (the polling time is 5sec). 
> {code}
> 19.10.2016 16:22:38.035 *DEBUG* [nioEventLoopGroup-1005-1] 
> org.apache.jackrabbit.oak.segment.standby.codec.ResponseDecoder Decoding 'get 
> head' response
> 19.10.2016 16:22:38.038 *DEBUG* [sling-default-81-Registered Service.607] 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Channel closed
> 19.10.2016 16:22:40.241 *DEBUG* [sling-default-81-Registered Service.607] 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Group shut down
> 19.10.2016 16:22:40.242 *ERROR* [sling-default-81-Registered Service.607] 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync Failed 
> synchronizing state.
> java.lang.RuntimeException: Error occurred while obtaining InputStream for 
> blobId [4dfc748c91d518c9221031ec6115fd7ac04fe27b#10]
>   at 
> org.apache.jackrabbit.oak.plugins.blob.BlobStoreBlob.getNewStream(BlobStoreBlob.java:49)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:252)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:87)
>   at 
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:45)
>   at 
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:42)
>   at com.google.common.io.ByteStreams$3.openStream(ByteStreams.java:907)
>   at com.google.common.io.ByteSource.contentEquals(ByteSource.java:301)
>   at com.google.common.io.ByteStreams.equal(ByteStreams.java:661)
>   at 
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob.equal(AbstractBlob.java:68)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentBlob.equals(SegmentBlob.java:193)
>   at com.google.common.base.Objects.equal(Objects.java:55)
>   at 
> org.apache.jackrabbit.oak.plugins.memory.AbstractPropertyState.equal(AbstractPropertyState.java:53)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentPropertyState.equals(SegmentPropertyState.java:249)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:622)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:516)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:415)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:457)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord$2.childNodeChanged(MapRecord.java:401)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord$3.childNodeChanged(MapRecord.java:442)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:485)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:433)
>   at 
> org.apach

[jira] [Commented] (OAK-4969) ColdStandby does not fetch missing blobs

[Francesco Mari (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622055#comment-15622055
 ] 

Francesco Mari commented on OAK-4969:
-

Fixed for oak-segment-tar at r1767263.

> ColdStandby does not fetch missing blobs
> 
>
> Key: OAK-4969
> URL: https://issues.apache.org/jira/browse/OAK-4969
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: segment-tar, segmentmk
>Affects Versions: Segment Tar 0.0.10
>Reporter: Timothee Maret
>Assignee: Francesco Mari
> Fix For: 1.2, 1.4, 1.6, 1.5.13
>
> Attachments: OAK-4969-oak-tarmk-standby.patch, OAK-4969.patch
>
>
> 1. In a setup composed of two instances (primary, standby) configured with a 
> custom blob store (File blob store).
> 2. On the primary instance, set/update a BINARY property of an existing 
> resource with > 2MB binary.
> 3. Observe that the standby instance does not fetch the binary and instead, 
> enters a loop detecting the missing binary upon comparing node states.
> For example, the following stack trace would be printed every 5 seconds on 
> the standby (the polling time is 5sec). 
> {code}
> 19.10.2016 16:22:38.035 *DEBUG* [nioEventLoopGroup-1005-1] 
> org.apache.jackrabbit.oak.segment.standby.codec.ResponseDecoder Decoding 'get 
> head' response
> 19.10.2016 16:22:38.038 *DEBUG* [sling-default-81-Registered Service.607] 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Channel closed
> 19.10.2016 16:22:40.241 *DEBUG* [sling-default-81-Registered Service.607] 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Group shut down
> 19.10.2016 16:22:40.242 *ERROR* [sling-default-81-Registered Service.607] 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync Failed 
> synchronizing state.
> java.lang.RuntimeException: Error occurred while obtaining InputStream for 
> blobId [4dfc748c91d518c9221031ec6115fd7ac04fe27b#10]
>   at 
> org.apache.jackrabbit.oak.plugins.blob.BlobStoreBlob.getNewStream(BlobStoreBlob.java:49)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:252)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:87)
>   at 
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:45)
>   at 
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:42)
>   at com.google.common.io.ByteStreams$3.openStream(ByteStreams.java:907)
>   at com.google.common.io.ByteSource.contentEquals(ByteSource.java:301)
>   at com.google.common.io.ByteStreams.equal(ByteStreams.java:661)
>   at 
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob.equal(AbstractBlob.java:68)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentBlob.equals(SegmentBlob.java:193)
>   at com.google.common.base.Objects.equal(Objects.java:55)
>   at 
> org.apache.jackrabbit.oak.plugins.memory.AbstractPropertyState.equal(AbstractPropertyState.java:53)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentPropertyState.equals(SegmentPropertyState.java:249)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:622)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:516)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:415)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:457)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord$2.childNodeChanged(MapRecord.java:401)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord$3.childNodeChanged(MapRecord.java:442)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:485)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:433)
>   at 
> org.apache.

[jira] [Assigned] (OAK-4969) ColdStandby does not fetch missing blobs

[Francesco Mari (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francesco Mari reassigned OAK-4969:
---

Assignee: Francesco Mari  (was: Timothee Maret)

> ColdStandby does not fetch missing blobs
> 
>
> Key: OAK-4969
> URL: https://issues.apache.org/jira/browse/OAK-4969
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: segment-tar, segmentmk
>Affects Versions: Segment Tar 0.0.10
>Reporter: Timothee Maret
>Assignee: Francesco Mari
> Fix For: 1.2, 1.4, 1.6, 1.5.13
>
> Attachments: OAK-4969-oak-tarmk-standby.patch, OAK-4969.patch
>
>
> 1. In a setup composed of two instances (primary, standby) configured with a 
> custom blob store (File blob store).
> 2. On the primary instance, set/update a BINARY property of an existing 
> resource with > 2MB binary.
> 3. Observe that the standby instance does not fetch the binary and instead, 
> enters a loop detecting the missing binary upon comparing node states.
> For example, the following stack trace would be printed every 5 seconds on 
> the standby (the polling time is 5sec). 
> {code}
> 19.10.2016 16:22:38.035 *DEBUG* [nioEventLoopGroup-1005-1] 
> org.apache.jackrabbit.oak.segment.standby.codec.ResponseDecoder Decoding 'get 
> head' response
> 19.10.2016 16:22:38.038 *DEBUG* [sling-default-81-Registered Service.607] 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Channel closed
> 19.10.2016 16:22:40.241 *DEBUG* [sling-default-81-Registered Service.607] 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Group shut down
> 19.10.2016 16:22:40.242 *ERROR* [sling-default-81-Registered Service.607] 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync Failed 
> synchronizing state.
> java.lang.RuntimeException: Error occurred while obtaining InputStream for 
> blobId [4dfc748c91d518c9221031ec6115fd7ac04fe27b#10]
>   at 
> org.apache.jackrabbit.oak.plugins.blob.BlobStoreBlob.getNewStream(BlobStoreBlob.java:49)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:252)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:87)
>   at 
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:45)
>   at 
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:42)
>   at com.google.common.io.ByteStreams$3.openStream(ByteStreams.java:907)
>   at com.google.common.io.ByteSource.contentEquals(ByteSource.java:301)
>   at com.google.common.io.ByteStreams.equal(ByteStreams.java:661)
>   at 
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob.equal(AbstractBlob.java:68)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentBlob.equals(SegmentBlob.java:193)
>   at com.google.common.base.Objects.equal(Objects.java:55)
>   at 
> org.apache.jackrabbit.oak.plugins.memory.AbstractPropertyState.equal(AbstractPropertyState.java:53)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentPropertyState.equals(SegmentPropertyState.java:249)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:622)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:516)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:415)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:457)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord$2.childNodeChanged(MapRecord.java:401)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord$3.childNodeChanged(MapRecord.java:442)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:485)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:433)
>   at 
> org.apache.jackrabbit.oak.segment.MapRecord.compa

[jira] [Comment Edited] (OAK-5021) Improve observation of files

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-5021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622005#comment-15622005
 ] 

Carsten Ziegeler edited comment on OAK-5021 at 10/31/16 12:23 PM:
--

[~egli] Could point, so far I overlooked this. Now I would at least except that 
{noformat}
/**/*.html 
{noformat}

works, which doesn't seem to be the case looking at that javadoc.

In Sling we have this simple definition (which is the usual pattern matching 
available nearly everywhere else, e.g. Ant, Maven etc.):
The * character matches zero or more characters of a name component without 
crossing directory boundaries.
The ** characters match zero or more characters crossing directory boundaries.


was (Author: cziegeler):
[~egli] Could point, so far I overlooked this. Now I would at least except that 
{noformat}
/**/*.html 
{noformat}

works, which doesn't seem to be the case looking at that javadoc

> Improve observation of files
> 
>
> Key: OAK-5021
> URL: https://issues.apache.org/jira/browse/OAK-5021
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: jcr
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>
> (Originally reported as JCR-4046, but moved to Oak as a result of introducing 
> the OakEventFilter in OAK-5013. From the original description: )
> A file in JCR is represented by at least two nodes, the nt:file node and a 
> child node named jcr:content holding the contents of the file (and metadata).
> This has the consequence that if the contents of a file changes, a change 
> event of the jcr:content node is reported - but not of the nt:file node.
> This makes creating listeners listening for changes in files complicated, as 
> you can't use the file name to filter  - especially with glob patterns (see 
> JCR-4044 - now OAK-5019) this becomes troublesome.
> In addition, whenever you get a change for a jcr:content node, you have to 
> check if the parent is a nt:file node and decide based on the result.
> It would be great to have a flag on the JackrabbitEventFilter to enable 
> smarter reporting just for nt:files: if a property on jcr:content is changed, 
> a change to the nt:file node is reported.
> See also SLING-6163 and OAK-4940
> /cc [~cziegeler]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-5021) Improve observation of files

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-5021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622005#comment-15622005
 ] 

Carsten Ziegeler commented on OAK-5021:
---

[~egli] Could point, so far I overlooked this. Now I would at least except that 
{noformat}
/**/*.html 
{noformat}

works, which doesn't seem to be the case looking at that javadoc

> Improve observation of files
> 
>
> Key: OAK-5021
> URL: https://issues.apache.org/jira/browse/OAK-5021
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: jcr
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>
> (Originally reported as JCR-4046, but moved to Oak as a result of introducing 
> the OakEventFilter in OAK-5013. From the original description: )
> A file in JCR is represented by at least two nodes, the nt:file node and a 
> child node named jcr:content holding the contents of the file (and metadata).
> This has the consequence that if the contents of a file changes, a change 
> event of the jcr:content node is reported - but not of the nt:file node.
> This makes creating listeners listening for changes in files complicated, as 
> you can't use the file name to filter  - especially with glob patterns (see 
> JCR-4044 - now OAK-5019) this becomes troublesome.
> In addition, whenever you get a change for a jcr:content node, you have to 
> check if the parent is a nt:file node and decide based on the result.
> It would be great to have a flag on the JackrabbitEventFilter to enable 
> smarter reporting just for nt:files: if a property on jcr:content is changed, 
> a change to the nt:file node is reported.
> See also SLING-6163 and OAK-4940
> /cc [~cziegeler]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-5021) Improve observation of files

[Stefan Egli (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-5021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15621929#comment-15621929
 ] 

Stefan Egli commented on OAK-5021:
--

[~cziegeler], re your comment on JCR-4046 (which moved to OAK-5021 meanwhile):
{quote}First of all, you don't know if a pattern is targetting a file, assume
{noformat}/**/*.*{noformat}
{quote}
Are you expecting such a glob format to be supported via OAK-5019 ? The 
[GlobbingPathFilter|https://jackrabbit.apache.org/oak/docs/apidocs/org/apache/jackrabbit/oak/plugins/observation/filter/GlobbingPathFilter.html]
 defines globbing differently (more restricted).

> Improve observation of files
> 
>
> Key: OAK-5021
> URL: https://issues.apache.org/jira/browse/OAK-5021
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: jcr
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>
> (Originally reported as JCR-4046, but moved to Oak as a result of introducing 
> the OakEventFilter in OAK-5013. From the original description: )
> A file in JCR is represented by at least two nodes, the nt:file node and a 
> child node named jcr:content holding the contents of the file (and metadata).
> This has the consequence that if the contents of a file changes, a change 
> event of the jcr:content node is reported - but not of the nt:file node.
> This makes creating listeners listening for changes in files complicated, as 
> you can't use the file name to filter  - especially with glob patterns (see 
> JCR-4044 - now OAK-5019) this becomes troublesome.
> In addition, whenever you get a change for a jcr:content node, you have to 
> check if the parent is a nt:file node and decide based on the result.
> It would be great to have a flag on the JackrabbitEventFilter to enable 
> smarter reporting just for nt:files: if a property on jcr:content is changed, 
> a change to the nt:file node is reported.
> See also SLING-6163 and OAK-4940
> /cc [~cziegeler]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (OAK-4969) ColdStandby does not fetch missing blobs

[Timothee Maret (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15616810#comment-15616810
 ] 

Timothee Maret edited comment on OAK-4969 at 10/31/16 11:24 AM:


[~frm] thanks for your insight. I found a clean way to fix this. Actually the 
{{StandbyDiff}} allows to intercept the exception at the required node level 
and attempt loading its binary properties.

This issue affects the previous standby implementation ({{oak-tarmk-standby}}).
I have attached two patches, one for each standby implementation, which contain

1. a test that reproduce the issue
2. the fix for the trunk

[~frm], [~alexparvulescu] Could you have a look at the patches
1. {{OAK-4969.patch}} (fix for {{oak-segment-tar}}
2. {{OAK-4969-oak-tarmk-standby.patch}} (fix for {{oak-tarmk-standby}}) 
?


was (Author: marett):
[~frm] thanks for your insight. I found a clean way to fix this. Actually the 
{{StandbyDiff}} allows to intercept the exception at the required node level 
and attempt loading its binary properties.

This issue affects the previous standby implementation ({{oak-tarmk-standby}}).
I have attached two patches, one for each standby implementation, which contain

1. a test that reproduce the issue
2. the fix for the trunk

[~frm] Could you have a look at the patch {{OAK-4969.patch}} (fix for 
{{oak-segment-tar}} ?
[~alexparvulescu] Could you have a look at the patch 
{{OAK-4969-oak-tarmk-standby.patch}} (fix for {{oak-tarmk-standby}}) ?

> ColdStandby does not fetch missing blobs
> 
>
> Key: OAK-4969
> URL: https://issues.apache.org/jira/browse/OAK-4969
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: segment-tar, segmentmk
>Affects Versions: Segment Tar 0.0.10
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: 1.2, 1.4, 1.6, 1.5.13
>
> Attachments: OAK-4969-oak-tarmk-standby.patch, OAK-4969.patch
>
>
> 1. In a setup composed of two instances (primary, standby) configured with a 
> custom blob store (File blob store).
> 2. On the primary instance, set/update a BINARY property of an existing 
> resource with > 2MB binary.
> 3. Observe that the standby instance does not fetch the binary and instead, 
> enters a loop detecting the missing binary upon comparing node states.
> For example, the following stack trace would be printed every 5 seconds on 
> the standby (the polling time is 5sec). 
> {code}
> 19.10.2016 16:22:38.035 *DEBUG* [nioEventLoopGroup-1005-1] 
> org.apache.jackrabbit.oak.segment.standby.codec.ResponseDecoder Decoding 'get 
> head' response
> 19.10.2016 16:22:38.038 *DEBUG* [sling-default-81-Registered Service.607] 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Channel closed
> 19.10.2016 16:22:40.241 *DEBUG* [sling-default-81-Registered Service.607] 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Group shut down
> 19.10.2016 16:22:40.242 *ERROR* [sling-default-81-Registered Service.607] 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync Failed 
> synchronizing state.
> java.lang.RuntimeException: Error occurred while obtaining InputStream for 
> blobId [4dfc748c91d518c9221031ec6115fd7ac04fe27b#10]
>   at 
> org.apache.jackrabbit.oak.plugins.blob.BlobStoreBlob.getNewStream(BlobStoreBlob.java:49)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:252)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:87)
>   at 
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:45)
>   at 
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:42)
>   at com.google.common.io.ByteStreams$3.openStream(ByteStreams.java:907)
>   at com.google.common.io.ByteSource.contentEquals(ByteSource.java:301)
>   at com.google.common.io.ByteStreams.equal(ByteStreams.java:661)
>   at 
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob.equal(AbstractBlob.java:68)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentBlob.equals(SegmentBlob.java:193)
>   at com.google.common.base.Objects.equal(Objects.java:55)
>   at 
> org.apache.jackrabbit.oak.plugins.memory.AbstractPropertyState.equal(AbstractPropertyState.java:53)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentPropertyState.equals(SegmentPropertyState.java:249)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:622)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:516)
>   at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
>   at 
> org.apache.jackrabbit.oak.segment.standby.

[jira] [Resolved] (OAK-5017) Standby test failures

[JIRA]

 [ 
https://issues.apache.org/jira/browse/OAK-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Dürig resolved OAK-5017.

Resolution: Fixed

Fixed as suggested by [~marett]

> Standby test failures
> -
>
> Key: OAK-5017
> URL: https://issues.apache.org/jira/browse/OAK-5017
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Timothee Maret
>  Labels: test-failure
> Fix For: 1.5.13
>
>
> I've recently seen a couple of the standby tests fail. E.g. on Jenkins: 
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1245/
> {noformat}
> java.lang.AssertionError: expected: 
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... }, 
> root = { ... } }> but was: 
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... }, 
> root = { ... } }>
>   at 
> org.apache.jackrabbit.oak.segment.standby.StandbyTestIT.testSyncLoop(StandbyTestIT.java:122)
> {noformat}
> {noformat}
> java.lang.AssertionError: expected: 
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... }, 
> root = { ... } }> but was: 
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... }, 
> root = { ... } }>
>   at 
> org.apache.jackrabbit.oak.segment.standby.StandbyTestIT.testSyncLoop(StandbyTestIT.java:122)
> {noformat}
> {{org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT.testProxySkippedBytes}}:
> {noformat}
> java.lang.AssertionError: expected:<{ root = { ... } }> but was:<{ root : { } 
> }>
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-5017) Standby test failures

[Timothee Maret (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15621896#comment-15621896
 ] 

Timothee Maret commented on OAK-5017:
-

[~mduerig] OAK-5034 has been fixed. Could you close this issue (I don't have 
this ability) ?.

> Standby test failures
> -
>
> Key: OAK-5017
> URL: https://issues.apache.org/jira/browse/OAK-5017
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Timothee Maret
>  Labels: test-failure
> Fix For: 1.5.13
>
>
> I've recently seen a couple of the standby tests fail. E.g. on Jenkins: 
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1245/
> {noformat}
> java.lang.AssertionError: expected: 
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... }, 
> root = { ... } }> but was: 
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... }, 
> root = { ... } }>
>   at 
> org.apache.jackrabbit.oak.segment.standby.StandbyTestIT.testSyncLoop(StandbyTestIT.java:122)
> {noformat}
> {noformat}
> java.lang.AssertionError: expected: 
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... }, 
> root = { ... } }> but was: 
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... }, 
> root = { ... } }>
>   at 
> org.apache.jackrabbit.oak.segment.standby.StandbyTestIT.testSyncLoop(StandbyTestIT.java:122)
> {noformat}
> {{org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT.testProxySkippedBytes}}:
> {noformat}
> java.lang.AssertionError: expected:<{ root = { ... } }> but was:<{ root : { } 
> }>
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (OAK-5034) FileStoreUtil#readSegmentWithRetry max retry delay is too short to be functional

[Francesco Mari (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-5034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francesco Mari resolved OAK-5034.
-
   Resolution: Fixed
Fix Version/s: 1.5.13
   1.6

Fixed at r1767246.

> FileStoreUtil#readSegmentWithRetry max retry delay is too short to be 
> functional
> 
>
> Key: OAK-5034
> URL: https://issues.apache.org/jira/browse/OAK-5034
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: segment-tar
>Affects Versions: Segment Tar 0.0.16
>Reporter: Timothee Maret
>Assignee: Francesco Mari
> Fix For: 1.6, 1.5.13
>
> Attachments: OAK-5034.patch
>
>
> The commit {{1765838}} introduced the {{FileStoreUtil#readSegmentWithRetry}} 
> util and reduced the period between two tries (from 2sec to 0.125s) while the 
> total number of tries did not change.
> This does not give enough time for the server to find references and 
> segments, thus causing exceptions such as
> {code}
> 29.10.2016 05:07:37.242 *ERROR* [sling-default-2-Registered Service.605] 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync Failed 
> synchronizing state.
> java.lang.IllegalStateException: Unable to read references of segment 
> 5168c878-3a3f-49d0-aea9-b8b57d5d867f from primary
> at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.readReferences(StandbyClientSyncExecution.java:196)
> at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.copySegmentHierarchyFromPrimary(StandbyClientSyncExecution.java:130)
> at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.compareAgainstBaseState(StandbyClientSyncExecution.java:94)
> at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.execute(StandbyClientSyncExecution.java:74)
> at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync.run(StandbyClientSync.java:143)
> at 
> org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:118)
> at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> and causing the client to throw exceptions, ultimately causing IT tests to 
> fail.
> IIUC, the minimum period to retry should be bigger than a TarMK flush cycle 
> (5 sec).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (OAK-5034) FileStoreUtil#readSegmentWithRetry max retry delay is too short to be functional

[Francesco Mari (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-5034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francesco Mari reassigned OAK-5034:
---

Assignee: Francesco Mari  (was: Timothee Maret)

> FileStoreUtil#readSegmentWithRetry max retry delay is too short to be 
> functional
> 
>
> Key: OAK-5034
> URL: https://issues.apache.org/jira/browse/OAK-5034
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: segment-tar
>Affects Versions: Segment Tar 0.0.16
>Reporter: Timothee Maret
>Assignee: Francesco Mari
> Attachments: OAK-5034.patch
>
>
> The commit {{1765838}} introduced the {{FileStoreUtil#readSegmentWithRetry}} 
> util and reduced the period between two tries (from 2sec to 0.125s) while the 
> total number of tries did not change.
> This does not give enough time for the server to find references and 
> segments, thus causing exceptions such as
> {code}
> 29.10.2016 05:07:37.242 *ERROR* [sling-default-2-Registered Service.605] 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync Failed 
> synchronizing state.
> java.lang.IllegalStateException: Unable to read references of segment 
> 5168c878-3a3f-49d0-aea9-b8b57d5d867f from primary
> at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.readReferences(StandbyClientSyncExecution.java:196)
> at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.copySegmentHierarchyFromPrimary(StandbyClientSyncExecution.java:130)
> at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.compareAgainstBaseState(StandbyClientSyncExecution.java:94)
> at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.execute(StandbyClientSyncExecution.java:74)
> at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync.run(StandbyClientSync.java:143)
> at 
> org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:118)
> at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> and causing the client to throw exceptions, ultimately causing IT tests to 
> fail.
> IIUC, the minimum period to retry should be bigger than a TarMK flush cycle 
> (5 sec).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-5022) add includeSubtreeOnDelete flag to OakEventFilter

[Stefan Egli (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-5022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15621846#comment-15621846
 ] 

Stefan Egli commented on OAK-5022:
--

I think where this has an impact is if we include subtree-removal in 
prefiltering, as that's synchronous.

> add includeSubtreeOnDelete flag to OakEventFilter
> -
>
> Key: OAK-5022
> URL: https://issues.apache.org/jira/browse/OAK-5022
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: jcr
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>
> (Originally reported as JCR-4037, but moved to Oak as a result of introducing 
> the OakEventFilter in OAK-5013. From the original description: )
> In some cases of observation it would be useful to receive events of child 
> node or properties of a parent/grandparent that was deleted. Currently (in 
> Oak at least) one only receives a deleted event for the node that was deleted 
> and none of the children.
> Suggesting to (re)introduce a flag, eg as follows to the 
> JackrabbitEventFilter:
> {code}
> boolean includeSubtreeOnRemove;
> {code}
> (Open for any better name of course)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OAK-5037) Update Oak 1.2 and Oak 1.4 to Jackrabbit 2.12.5

[Julian Reschke (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-5037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Reschke updated OAK-5037:

Priority: Minor  (was: Major)

> Update Oak 1.2 and Oak 1.4 to Jackrabbit 2.12.5
> ---
>
> Key: OAK-5037
> URL: https://issues.apache.org/jira/browse/OAK-5037
> Project: Jackrabbit Oak
>  Issue Type: Task
>Affects Versions: 1.2.20, 1.4.9
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (OAK-5013) Introduce observation filter extension mechanism to Oak

[Stefan Egli (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-5013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15621818#comment-15621818
 ] 

Stefan Egli edited comment on OAK-5013 at 10/31/16 10:39 AM:
-

Done in trunk in http://svn.apache.org/viewvc?rev=1767238&view=rev (and 
[this|http://svn.apache.org/viewvc?rev=1767243&view=rev] and 
[this|http://svn.apache.org/viewvc?rev=1767244&view=rev] and 
[this|http://svn.apache.org/viewvc?rev=1767245&view=rev] ..)
Note that the version is currently left at 0.0.0 to avoid version increases 
during 1.5 unstable development. Opened blocker OAK-5036 to change that to 
1.0.0 before oak 1.6 release.


was (Author: egli):
Done in trunk in http://svn.apache.org/viewvc?rev=1767238&view=rev
Note that the version is currently left at 0.0.0 to avoid version increases 
during 1.5 unstable development. Opened blocker OAK-5036 to change that to 
1.0.0 before oak 1.6 release.

> Introduce observation filter extension mechanism to Oak
> ---
>
> Key: OAK-5013
> URL: https://issues.apache.org/jira/browse/OAK-5013
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: jcr
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: 1.5.13
>
> Attachments: OAK-5013.patch
>
>
> During [discussions|http://markmail.org/thread/fyngo4dwb7fvlqdj] regarding 
> extending JackrabbitEventFilter an interesting suggestion by [~mduerig] came 
> up that we could extend the JackrabbitEventFilter in oak explicitly, rather 
> than modifying it in Jackrabbit each time we add something oak-specific.
> We should introduce a builder/interface pair in oak to reflect that. 
> Users that would like to use such oak-specific extensions would wrap a 
> JackrabbitEventFilter and get an OakEventFilter that contains enabling these 
> extensions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OAK-5037) Update Oak 1.2 and Oak 1.4 to Jackrabbit 2.12.5

[Julian Reschke (JIRA)]

Julian Reschke created OAK-5037:
---

 Summary: Update Oak 1.2 and Oak 1.4 to Jackrabbit 2.12.5
 Key: OAK-5037
 URL: https://issues.apache.org/jira/browse/OAK-5037
 Project: Jackrabbit Oak
  Issue Type: Task
Affects Versions: 1.4.9, 1.2.20
Reporter: Julian Reschke
Assignee: Julian Reschke






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-4882) Bottleneck in the asynchronous persistent cache

[JIRA]

[ 
https://issues.apache.org/jira/browse/OAK-4882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15621825#comment-15621825
 ] 

Tomek Rękawek commented on OAK-4882:


Implemented a simple benchmark in OAK-5035. The way to reproduce [original 
issue|OAK-2761]:

{noformat}
$ java -DcacheOptions="size=100,+compact,-async" -jar 
target/oak-run-1.6-SNAPSHOT.jar benchmark --concurrency=8 PersistentCacheTest 
Oak-Mongo
Apache Jackrabbit Oak 1.6-SNAPSHOT
# PersistentCacheTest  C min 10% 50% 90% max
   N
Oak-Mongo  8 122 215 278 3533403
1520
{noformat}

The max = 3403 indicates that at some point during the test the threads are 
locked on the compaction process during generation switch (it can be confirmed 
with a debugger). On the other hand, after enabling +async mode the results are 
as follows:

{noformat}
java -DcacheOptions="size=100,+compact,+async" -jar 
target/oak-run-1.6-SNAPSHOT.jar benchmark --concurrency=8 PersistentCacheTest 
Oak-Mongo
Apache Jackrabbit Oak 1.6-SNAPSHOT
# PersistentCacheTest  C min 10% 50% 90% max
   N
Oak-Mongo  8  55  73  91 124 356
4998
{noformat}

So, it seems that there's no more hangup there.

I'll also try to measure how many put() entries are discarded (by the 
heuristics and the full queue).

> Bottleneck in the asynchronous persistent cache
> ---
>
> Key: OAK-4882
> URL: https://issues.apache.org/jira/browse/OAK-4882
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: cache, documentmk
>Affects Versions: 1.5.10, 1.4.8
>Reporter: Tomek Rękawek
>Assignee: Tomek Rękawek
> Fix For: 1.6, 1.5.13
>
> Attachments: OAK-4882.patch
>
>
> The class responsible for accepting new cache operations which will be 
> handled asynchronously is 
> [CacheActionDispatcher|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/persistentCache/async/CacheActionDispatcher.java].
>  In case of a high load, when the queue is full (=1024 entries), the 
> [add()|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/persistentCache/async/CacheActionDispatcher.java#L86]
>  method removes the oldest 256 entries. However, we can't afford losing the 
> updates (as it may result in having stale entries in the cache), so all the 
> removed entries are compacted into one big invalidate action.
> The compaction action 
> ([CacheActionDispatcher#cleanTheQueue|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/persistentCache/async/CacheActionDispatcher.java#L97])
>  still holds the lock taken in add() method, so threads which tries to add 
> something to the queue have to wait until cleanTheQueue() ends.
> Maybe we can optimise the CacheActionDispatcher#add->cleanTheQueue part, so 
> it won't hold the lock for the whole time.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (OAK-5013) Introduce observation filter extension mechanism to Oak

[Stefan Egli (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-5013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Egli resolved OAK-5013.
--
Resolution: Fixed

Done in trunk in http://svn.apache.org/viewvc?rev=1767238&view=rev
Note that the version is currently left at 0.0.0 to avoid version increases 
during 1.5 unstable development. Opened blocker OAK-5036 to change that to 
1.0.0 before oak 1.6 release.

> Introduce observation filter extension mechanism to Oak
> ---
>
> Key: OAK-5013
> URL: https://issues.apache.org/jira/browse/OAK-5013
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: jcr
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: 1.5.13
>
> Attachments: OAK-5013.patch
>
>
> During [discussions|http://markmail.org/thread/fyngo4dwb7fvlqdj] regarding 
> extending JackrabbitEventFilter an interesting suggestion by [~mduerig] came 
> up that we could extend the JackrabbitEventFilter in oak explicitly, rather 
> than modifying it in Jackrabbit each time we add something oak-specific.
> We should introduce a builder/interface pair in oak to reflect that. 
> Users that would like to use such oak-specific extensions would wrap a 
> JackrabbitEventFilter and get an OakEventFilter that contains enabling these 
> extensions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OAK-5036) switch o.a.j.oak.jcr.observation.filter version to 1.0.0 before oak 1.6 release

[Stefan Egli (JIRA)]

Stefan Egli created OAK-5036:


 Summary: switch o.a.j.oak.jcr.observation.filter version to 1.0.0 
before oak 1.6 release
 Key: OAK-5036
 URL: https://issues.apache.org/jira/browse/OAK-5036
 Project: Jackrabbit Oak
  Issue Type: Task
  Components: jcr
Reporter: Stefan Egli
Assignee: Stefan Egli
Priority: Blocker
 Fix For: 1.6


OAK-5013 introduces an extension mechanism to expose Oak specific observation 
filtering features. 

Currently the corresponding package is set to version 0.0.0 with the idea to 
not dirty the version range unnecessarily before oak 1.6. But before releasing 
oak 1.6 this should be set to 1.0.0



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-5022) add includeSubtreeOnDelete flag to OakEventFilter

[JIRA]

[ 
https://issues.apache.org/jira/browse/OAK-5022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15621798#comment-15621798
 ] 

Michael Dürig commented on OAK-5022:


bq. Could this be handled lazily

In the current implementation this would be lazy by default. That is, the diff 
would only be calculated as much as is required and as long as you keep calling 
{{EventIterator.next()}}. 

> add includeSubtreeOnDelete flag to OakEventFilter
> -
>
> Key: OAK-5022
> URL: https://issues.apache.org/jira/browse/OAK-5022
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: jcr
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>
> (Originally reported as JCR-4037, but moved to Oak as a result of introducing 
> the OakEventFilter in OAK-5013. From the original description: )
> In some cases of observation it would be useful to receive events of child 
> node or properties of a parent/grandparent that was deleted. Currently (in 
> Oak at least) one only receives a deleted event for the node that was deleted 
> and none of the children.
> Suggesting to (re)introduce a flag, eg as follows to the 
> JackrabbitEventFilter:
> {code}
> boolean includeSubtreeOnRemove;
> {code}
> (Open for any better name of course)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (OAK-5035) Implement mini-benchmark for PersistentCache

[JIRA]

 [ 
https://issues.apache.org/jira/browse/OAK-5035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tomek Rękawek resolved OAK-5035.

   Resolution: Fixed
Fix Version/s: 1.5.13

> Implement mini-benchmark for PersistentCache
> 
>
> Key: OAK-5035
> URL: https://issues.apache.org/jira/browse/OAK-5035
> Project: Jackrabbit Oak
>  Issue Type: Sub-task
>  Components: cache, documentmk
>Reporter: Tomek Rękawek
>Assignee: Tomek Rękawek
> Fix For: 1.6, 1.5.13
>
>
> In order to test OAK-4882 and OAK-2761 in a reliable way, we need to have a 
> tool that is able to reproduce the issue reported there.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-5035) Implement mini-benchmark for PersistentCache

[JIRA]

[ 
https://issues.apache.org/jira/browse/OAK-5035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15621791#comment-15621791
 ] 

Tomek Rękawek commented on OAK-5035:


Fixed for trunk in [r1767237|https://svn.apache.org/r1767237].

> Implement mini-benchmark for PersistentCache
> 
>
> Key: OAK-5035
> URL: https://issues.apache.org/jira/browse/OAK-5035
> Project: Jackrabbit Oak
>  Issue Type: Sub-task
>  Components: cache, documentmk
>Reporter: Tomek Rękawek
>Assignee: Tomek Rękawek
> Fix For: 1.6
>
>
> In order to test OAK-4882 and OAK-2761 in a reliable way, we need to have a 
> tool that is able to reproduce the issue reported there.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OAK-5035) Implement mini-benchmark for PersistentCache

[JIRA]

Tomek Rękawek created OAK-5035:
--

 Summary: Implement mini-benchmark for PersistentCache
 Key: OAK-5035
 URL: https://issues.apache.org/jira/browse/OAK-5035
 Project: Jackrabbit Oak
  Issue Type: Sub-task
  Components: cache, documentmk
Reporter: Tomek Rękawek
 Fix For: 1.6


In order to test OAK-4882 and OAK-2761 in a reliable way, we need to have a 
tool that is able to reproduce the issue reported there.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (OAK-5035) Implement mini-benchmark for PersistentCache

[JIRA]

 [ 
https://issues.apache.org/jira/browse/OAK-5035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tomek Rękawek reassigned OAK-5035:
--

Assignee: Tomek Rękawek

> Implement mini-benchmark for PersistentCache
> 
>
> Key: OAK-5035
> URL: https://issues.apache.org/jira/browse/OAK-5035
> Project: Jackrabbit Oak
>  Issue Type: Sub-task
>  Components: cache, documentmk
>Reporter: Tomek Rękawek
>Assignee: Tomek Rękawek
> Fix For: 1.6
>
>
> In order to test OAK-4882 and OAK-2761 in a reliable way, we need to have a 
> tool that is able to reproduce the issue reported there.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (OAK-5022) add includeSubtreeOnDelete flag to OakEventFilter

[Stefan Egli (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-5022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15621644#comment-15621644
 ] 

Stefan Egli edited comment on OAK-5022 at 10/31/16 8:55 AM:


[~mmarth], re
bq. Re "includeSubtreeOnRemove": need to careful to not make this a very 
expensive operation for large subtrees. 
Agreed. Removal of a large subtree will probably be at the same cost as 
-removing- adding a large subtree. As either way the subtree needs to be 
traversed (either in prefiltering or if prefiltering doesn't result in an 
exclude with the actual finer-grade filter).
bq. Could this be handled lazily?
Not sure what exactly you're referring to, not handling this in prefiltering 
but only in the affected filter (which is by definition async)?


was (Author: egli):
[~mmarth], re
bq. Re "includeSubtreeOnRemove": need to careful to not make this a very 
expensive operation for large subtrees. 
Agreed. Removal of a large subtree will probably be at the same cost as 
removing a large subtree. As either way the subtree needs to be traversed 
(either in prefiltering or if prefiltering doesn't result in an exclude with 
the actual finer-grade filter).
bq. Could this be handled lazily?
Not sure what exactly you're referring to, not handling this in prefiltering 
but only in the affected filter (which is by definition async)?

> add includeSubtreeOnDelete flag to OakEventFilter
> -
>
> Key: OAK-5022
> URL: https://issues.apache.org/jira/browse/OAK-5022
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: jcr
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>
> (Originally reported as JCR-4037, but moved to Oak as a result of introducing 
> the OakEventFilter in OAK-5013. From the original description: )
> In some cases of observation it would be useful to receive events of child 
> node or properties of a parent/grandparent that was deleted. Currently (in 
> Oak at least) one only receives a deleted event for the node that was deleted 
> and none of the children.
> Suggesting to (re)introduce a flag, eg as follows to the 
> JackrabbitEventFilter:
> {code}
> boolean includeSubtreeOnRemove;
> {code}
> (Open for any better name of course)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-5022) add includeSubtreeOnDelete flag to OakEventFilter

[Stefan Egli (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-5022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15621644#comment-15621644
 ] 

Stefan Egli commented on OAK-5022:
--

[~mmarth], re
bq. Re "includeSubtreeOnRemove": need to careful to not make this a very 
expensive operation for large subtrees. 
Agreed. Removal of a large subtree will probably be at the same cost as 
removing a large subtree. As either way the subtree needs to be traversed 
(either in prefiltering or if prefiltering doesn't result in an exclude with 
the actual finer-grade filter).
bq. Could this be handled lazily?
Not sure what exactly you're referring to, not handling this in prefiltering 
but only in the affected filter (which is by definition async)?

> add includeSubtreeOnDelete flag to OakEventFilter
> -
>
> Key: OAK-5022
> URL: https://issues.apache.org/jira/browse/OAK-5022
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: jcr
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>
> (Originally reported as JCR-4037, but moved to Oak as a result of introducing 
> the OakEventFilter in OAK-5013. From the original description: )
> In some cases of observation it would be useful to receive events of child 
> node or properties of a parent/grandparent that was deleted. Currently (in 
> Oak at least) one only receives a deleted event for the node that was deleted 
> and none of the children.
> Suggesting to (re)introduce a flag, eg as follows to the 
> JackrabbitEventFilter:
> {code}
> boolean includeSubtreeOnRemove;
> {code}
> (Open for any better name of course)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-4987) Segment objects under-report their size for the cache

[JIRA]

[ 
https://issues.apache.org/jira/browse/OAK-4987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15621596#comment-15621596
 ] 

Michael Dürig commented on OAK-4987:


Before we introduced the LIRS cache the {{Segment.getCacheSize()}} [method | 
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-segment/src/main/java/org/apache/jackrabbit/oak/plugins/segment/Segment.java#L389]
 was used to estimate the memory footprint of a cached segment. That method 
takes the impact of direct vs. non direct buffers on memory consumption into 
account. We should probably use a similar logic in the weigher for the LIRS 
cache. 

> Segment objects under-report their size for the cache
> -
>
> Key: OAK-4987
> URL: https://issues.apache.org/jira/browse/OAK-4987
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: segment-tar
>Reporter: Alex Parvulescu
> Fix For: 1.5.14
>
>
> The {{SegmentCache}} expects each {{Segment}} object to report its own size, 
> which will then be used to properly keep the cache within the configured 
> bounds [0]. If a {{Segment}} object is unable to accurately account for its 
> own size the global cache will have a size that is a lot bigger than the 
> expected value:
> {noformat}
> Class Name   
> | Shallow Heap | Retained Heap | Percentage
> -
> org.apache.jackrabbit.oak.segment.Segment @ 0x6cd906df0  
> |   48 | 1 439 728 |  0,09%
> |- org.apache.jackrabbit.oak.segment.ImmutableRecordNumbers @ 0x6cd906e50
> |   16 | 1 177 432 |  0,07%
> |- java.nio.HeapByteBuffer @ 0x6cd906e20 
> |   48 |   262 208 |  0,02%
> |- org.apache.jackrabbit.oak.segment.ImmutableSegmentReferences @ 
> 0x6ce0a0880|   16 |40 |  0,00%
> -
> {noformat}
> This is pre OAK-4872, so the objects won't match anymore, but the core issue 
> is still there (segment size needs to account for {{segmentReferences}} and 
> {{recordNumbers}}).
> [0] 
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/SegmentCache.java#L53



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)