Re: [discuss] persisting cluster (view) id for discovery-lite-descriptor
Hi, Following up on the OAK-3672 discussion again, and taking a step back, I see three possible classes of solutions: a) the (cluster)id is always defined by discovery-lite, be it cluster or singlevm b) the (cluster)id is entirely removed and it is up to discovery.oak (in sling) to define it c) the (cluster)id is only set by discovery-lite when feasible, eg only for the cluster case I'm in favour of c) with the following arguments: * a) requires tarMk (!) to store this id somewhere. It can either store it in the filesystem (which makes failover support harder), store it as a hidden property in the node store (which is not manageable as it's hidden) or store it as a normal property in the repository (which sounds hacky, as discovery-lite is in the NodeStore layer while this would require it to simulate writing a JCR property) * removing the id altogether (b) would be going too far imv: the logical unit that defines the cluster view (its members) is the best place to also define an id for that unit. And that logical unit is discovery-lite in this case. * what speaks for returning null for the singleVm case (c) is the fact that it is a special case (it is not a cluster). So treating the special case separately doesn't break the separation of concern rule in my view. (c) would imply that the id is set when we're in a cluster case, and not otherwise (but that would not be a hard requirement, the specification would just be that the id *can* be null). So long story short: I suggest to change the definition of this id so that it *can* be null - in which case upper layers must define their own id. Which means Sling's discovery.oak would then store a clusterId under /var/discovery/oak. That would automatically support cold-standby/failover - fix the original bug - and simplify cleaning this property up for the clone case (as that would correspond to how this case was dealt with in discovery.impl times already). WDYT? Cheers, Stefan On 26/11/15 11:32, "Chetan Mehrotra" wrote: >On Thu, Nov 26, 2015 at 3:56 PM, Stefan Egli wrote: >> which would >> then be on the Sling level thus could more simply use the slingId. > >That also sounds good. While we are at it also have a look at OAK-3529 >where system needs to know a clusterId. Looks like some overlap so >keep that usecase also in mind > > >Chetan Mehrotra
Re: JUnit tests with FileDataStore
To make use of FileDataStore you would need to configure a SegmentNodeStore as MemoryNodeStore does not allow plugging in custom BlobStore Have a look at snippet [1] for a possible approach Chetan Mehrotra [1] https://gist.github.com/chetanmeh/6242d0a7fe421955d456 On Wed, Jan 27, 2016 at 6:42 AM, Tobias Bocanegra wrote: > Hi, > > I have some tests in filevault that I want to run with the > FileDataStore, but I couldn't figure out how to setup the repository > correctly here [0]. I also looked at the tests in oak, but I couldn't > find a valid reference. > > The reason for this is to test the binary references, which afaik only > work with the FileDataStore. > at least my test [1] works with jackrabbit, but not for oak. > > thanks. > regards, toby > > [0] > https://github.com/apache/jackrabbit-filevault/blob/trunk/vault-core/src/test/java/org/apache/jackrabbit/vault/packaging/integration/IntegrationTestBase.java#L118-L120 > [1] > https://github.com/apache/jackrabbit-filevault/blob/trunk/vault-core/src/test/java/org/apache/jackrabbit/vault/packaging/integration/TestBinarylessExport.java
Re: JUnit tests with FileDataStore
Thanks a bunch, Chetan! i'll give it a try. Regards, Toby On Wed, Jan 27, 2016 at 3:38 AM, Chetan Mehrotra wrote: > To make use of FileDataStore you would need to configure a > SegmentNodeStore as MemoryNodeStore does not allow plugging in custom > BlobStore > > Have a look at snippet [1] for a possible approach > > Chetan Mehrotra > [1] https://gist.github.com/chetanmeh/6242d0a7fe421955d456 > > > On Wed, Jan 27, 2016 at 6:42 AM, Tobias Bocanegra wrote: >> Hi, >> >> I have some tests in filevault that I want to run with the >> FileDataStore, but I couldn't figure out how to setup the repository >> correctly here [0]. I also looked at the tests in oak, but I couldn't >> find a valid reference. >> >> The reason for this is to test the binary references, which afaik only >> work with the FileDataStore. >> at least my test [1] works with jackrabbit, but not for oak. >> >> thanks. >> regards, toby >> >> [0] >> https://github.com/apache/jackrabbit-filevault/blob/trunk/vault-core/src/test/java/org/apache/jackrabbit/vault/packaging/integration/IntegrationTestBase.java#L118-L120 >> [1] >> https://github.com/apache/jackrabbit-filevault/blob/trunk/vault-core/src/test/java/org/apache/jackrabbit/vault/packaging/integration/TestBinarylessExport.java
[Oak origin/1.2] Apache Jackrabbit Oak matrix - Build # 712 - Failure
The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build #712) Status: Failure Check console output at https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/712/ to view the results. Changes: [amitj] OAK-3184: Consistency checker for data/blob store [amitj] OAK-3921: DataStoreBlobStore - Limit resolveChunks only to non inlined [amitj] OAK-3931: Identify own repository id in shared datastore gc stats [amitj] OAK-3184: Consistency checker for data/blob store [reschke] OAK-3932: DocumentStore.getIfCached() must not return NodeDocument.NULL Test results: 46 tests failed. FAILED: org.apache.jackrabbit.oak.jcr.ConcurrentAddIT.addNodes[RDBDocumentStore on jdbc:h2:file:./target/oaktest] Error Message: expected:<100> but was:<99> Stack Trace: java.lang.AssertionError: expected:<100> but was:<99> at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:834) at org.junit.Assert.assertEquals(Assert.java:645) at org.junit.Assert.assertEquals(Assert.java:631) at org.apache.jackrabbit.oak.jcr.ConcurrentAddIT.addNodes(ConcurrentAddIT.java:76) 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) FAILED: org.apache.jackrabbit.test.api.lock.LockTest.testCheckedInUnlock Error Message: OakConstraint0001: /[[rep:root, rep:AccessControllable]]: No matching definition found for child node jcr:system with effective type [rep:versionStorage, rep:AccessControllable] Stack Trace: javax.jcr.nodetype.ConstraintViolationException: OakConstraint0001: /[[rep:root, rep:AccessControllable]]: No matching definition found for child node jcr:system with effective type [rep:versionStorage, rep:AccessControllable] at org.apache.jackrabbit.oak.api.CommitFailedException.asRe
[Oak origin/1.0] Apache Jackrabbit Oak matrix - Build # 713 - Still Failing
The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build #713) Status: Still Failing Check console output at https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/713/ to view the results. Changes: [reschke] OAK-3932: DocumentStore.getIfCached() must not return NodeDocument.NULL [reschke] OAK-3932: DocumentStore.getIfCached() must not return NodeDocument.NULL Test results: 17 tests failed. FAILED: org.apache.jackrabbit.oak.security.authentication.ldap.GuestTokenDefaultLdapLoginModuleTest.org.apache.jackrabbit.oak.security.authentication.ldap.GuestTokenDefaultLdapLoginModuleTest Error Message: ERR_171 Failed to bind an LDAP service (1,024) to the service registry. Stack Trace: org.apache.directory.api.ldap.model.exception.LdapConfigurationException: ERR_171 Failed to bind an LDAP service (1,024) to the service registry. at org.apache.directory.server.ldap.LdapServer.startNetwork(LdapServer.java:695) at org.apache.directory.server.ldap.LdapServer.start(LdapServer.java:547) at org.apache.jackrabbit.oak.security.authentication.ldap.AbstractServer.setUp(AbstractServer.java:225) at org.apache.jackrabbit.oak.security.authentication.ldap.InternalLdapServer.setUp(InternalLdapServer.java:33) at org.apache.jackrabbit.oak.security.authentication.ldap.LdapLoginTestBase.beforeClass(LdapLoginTestBase.java:86) 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.RunBefores.evaluate(RunBefores.java:24) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) 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) Caused by: java.net.BindException: Address already in use at sun.nio.ch.Net.bind0(Native Method) at sun.nio.ch.Net.bind(Net.java:463) at sun.nio.ch.Net.bind(Net.java:455) at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) at org.apache.mina.transport.socket.nio.NioSocketAcceptor.open(NioSocketAcceptor.java:198) at org.apache.mina.transport.socket.nio.NioSocketAcceptor.open(NioSocketAcceptor.java:51) at org.apache.mina.core.polling.AbstractPollingIoAcceptor.registerHandles(AbstractPollingIoAcceptor.java:547) at org.apache.mina.core.polling.AbstractPollingIoAcceptor.access$400(AbstractPollingIoAcceptor.java:68) at org.apache.mina.core.polling.AbstractPollingIoAcceptor$Acceptor.run(AbstractPollingIoAcceptor.java:422) at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) FAILED: org.apache.jackrabbit.oak.security.authentication.ldap.LdapProviderTest.testGetUserByUserId Error Message: ERR_171 Failed to bind an LDAP service (1,024) to the service registry. Stack Trace: org.apache.directory.api.ldap.model.exception.LdapConfigurationException: ERR_171 Failed to bind an LDAP service (1,024) to the service registry. at org.apache.directory.server.ldap.Ld
[Oak origin/trunk] Apache Jackrabbit Oak matrix - Build # 714 - Still Failing
The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build #714) Status: Still Failing Check console output at https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/714/ to view the results. Changes: [amitj] OAK-3931: Identify own repository id in shared datastore gc stats [mreutegg] OAK-3932: DocumentStore.getIfCached() must not return NodeDocument.NULL [reschke] OAK-3932: DocumentStore.getIfCached() must not return NodeDocument.NULL [catholicon] OAK-3915: Include suggest directory size into lucene stats jmx [reschke] OAK-3871: ability to override [mduerig] OAK-3842: Adjust package export declarations Remove version declaration [mduerig] OAK-3934: Log ids of segments being released for gc because of their age [catholicon] OAK-3917: SuggestionHelper creating unnecessary temporary directories [chetanm] OAK-3907 - Sync the files to directory upon copy from remote Test results: All tests passed
