[JBoss JIRA] (ISPN-8448) Retried prepare times out while partition is in degraded mode
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-8448?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-8448:
--------------------------------
Fix Version/s: 9.2.0.Beta2
(was: 9.2.0.Beta1)
> Retried prepare times out while partition is in degraded mode
> -------------------------------------------------------------
>
> Key: ISPN-8448
> URL: https://issues.jboss.org/browse/ISPN-8448
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.1.9.Final, 9.0.3.Final, 8.2.8.Final, 9.1.2.Final, 9.2.0.Alpha2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 8.1.10.Final, 8.2.9.Final, 9.2.0.Beta2, 9.1.3.Final
>
>
> Since ISPN-5046, prepare commands are retried if one of the prepare targets has left the cluster. However, when the cache enters degraded mode, the prepare targets still include the owners in other partitions, and the prepare command is retried again.
> Each retry automatically waits for cache topology {{<command topology> + 1}}. But the second retry is not really triggered by a topology change, so the retry blocks for {{remoteTimeout}} milliseconds before failing with a {{TimeoutException}}.
> This situation actually happens in {{OptimisticTxPartitionAndMergeDuringPrepareTest}}, but the tests do not fail because it doesn't wait for an {{AvailabilityException}} specifically: they just take 15+ seconds each.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (ISPN-8517) Lazily ressurect ice fromMemory
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-8517?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-8517:
--------------------------------
Fix Version/s: 9.2.0.Beta2
(was: 9.2.0.Beta1)
> Lazily ressurect ice fromMemory
> -------------------------------
>
> Key: ISPN-8517
> URL: https://issues.jboss.org/browse/ISPN-8517
> Project: Infinispan
> Issue Type: Sub-task
> Components: Off Heap
> Affects Versions: 9.2.0.Alpha2
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 9.2.0.Beta2, 9.1.3.Final
>
>
> Currently many places do
> {code}
> ice = ice = offHeapEntryFactory.fromMemory(address)
> if (wrappedKey.equalsWrappedBytes(ice.getKey()))
> {code}
> In cases where this ends up being a miss, we read the entire value which is wasteful. And the CPU may not have the key in the cache size we read the object into memory. Where as if we do
> {code}
> if (offHeapEntryFactory.equalsKey(address, key))
> ice = ice = offHeapEntryFactory.fromMemory(address)
> {code}
> we know that CPU is reading from the address location twice in a row, which has a very high chance of still being in CPU caches which should hopefully provide better performance. We also then don't have to read the entire ice object in memory unless there was a hit.
> We also should change _performGet_ to return the address instead of the ice. This way callers can use this address for other optimizations such as when doing a _evict_ or _compute_ which have to read the entry first before a remove.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (ISPN-8516) OSGI integration tests random failure listening to RMI port
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-8516?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-8516:
--------------------------------
Fix Version/s: 9.2.0.Beta2
(was: 9.2.0.Beta1)
> OSGI integration tests random failure listening to RMI port
> -----------------------------------------------------------
>
> Key: ISPN-8516
> URL: https://issues.jboss.org/browse/ISPN-8516
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 9.1.2.Final, 9.2.0.Alpha2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 9.2.0.Beta2, 9.1.3.Final
>
>
> Because of [PAXEXAM-901|https://ops4j1.jira.com/browse/PAXEXAM-901], the [{{default-test}} Surefire execution|https://github.com/infinispan/infinispan/blob/master/integratio...] doesn't stop the {{@PerSuite}} Karaf container.
> That means the {{@PerClass}} Karaf container created for {{OSGiKarafFeaturesTest}} cannot listen to the RMI port:
> {noformat}
> 2017-11-06T19:51:01,920 | WARN | pool-15-thread-2 | Activator | 37 - org.apache.karaf.management.server - 4.1.2 | Error starting activator
> java.rmi.server.ExportException: Port already in use: 1099; nested exception is:
> java.net.BindException: Address already in use (Bind failed)
> at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:341) [?:?]
> at sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:249) [?:?]
> at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:411) [?:?]
> at sun.rmi.transport.LiveRef.exportObject(LiveRef.java:147) [?:?]
> at sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:236) [?:?]
> at sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:213) [?:?]
> at sun.rmi.registry.RegistryImpl.<init>(RegistryImpl.java:173) [?:?]
> at sun.rmi.registry.RegistryImpl.<init>(RegistryImpl.java:144) [?:?]
> at java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:239) [?:?]
> at org.apache.karaf.management.RmiRegistryFactory.init(RmiRegistryFactory.java:126) [37:org.apache.karaf.management.server:4.1.2]
> at org.apache.karaf.management.internal.Activator.doStart(Activator.java:104) [37:org.apache.karaf.management.server:4.1.2]
> at org.apache.karaf.util.tracker.BaseActivator.run(BaseActivator.java:242) [37:org.apache.karaf.management.server:4.1.2]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
> at java.lang.Thread.run(Thread.java:748) [?:?]
> Caused by: java.net.BindException: Address already in use (Bind failed)
> at java.net.PlainSocketImpl.socketBind(Native Method) ~[?:?]
> at java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387) ~[?:?]
> at java.net.ServerSocket.bind(ServerSocket.java:375) ~[?:?]
> at java.net.ServerSocket.<init>(ServerSocket.java:237) ~[?:?]
> at org.apache.karaf.management.RmiRegistryFactory$KarafServerSocketFactory.createServerSocket(RmiRegistryFactory.java:181) ~[?:?]
> at sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:666) ~[?:?]
> at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:330) ~[?:?]
> ... 16 more
> {noformat}
> Usually the tests still pass, but I believe this random failure is caused by {{OSGiKarafFeaturesTest}} connecting to the wrong Karaf instance:
> {noformat}
> 19:51:06,280 ERROR (main:[]) [TestSuiteProgress] Test failed: OSGiKarafFeaturesTest.testCleanInstall
> java.lang.ClassNotFoundException: org.objectweb.howl.log.LogConfigurationException (no security manager: RMI class loader disabled)
> at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:396) ~[?:1.8.0_151]
> at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:186) ~[?:1.8.0_151]
> at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:637) ~[?:1.8.0_151]
> at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:264) ~[?:1.8.0_151]
> at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:219) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1868) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1751) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2042) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1573) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2287) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:563) ~[?:1.8.0_151]
> at java.lang.Throwable.readObject(Throwable.java:914) ~[?:1.8.0_151]
> at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) ~[?:?]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_151]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_151]
> at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1158) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2178) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2069) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1573) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2287) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:563) ~[?:1.8.0_151]
> at java.lang.Throwable.readObject(Throwable.java:914) ~[?:1.8.0_151]
> at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) ~[?:?]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_151]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_151]
> at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1158) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2178) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2069) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1573) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:433) ~[?:1.8.0_151]
> at java.util.ArrayList.readObject(ArrayList.java:797) ~[?:1.8.0_151]
> at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) ~[?:?]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_151]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_151]
> at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1158) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2178) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2069) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1573) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2287) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:563) ~[?:1.8.0_151]
> at java.lang.Throwable.readObject(Throwable.java:914) ~[?:1.8.0_151]
> at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) ~[?:?]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_151]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_151]
> at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1158) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2178) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2069) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1573) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2287) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:563) ~[?:1.8.0_151]
> at java.lang.Throwable.readObject(Throwable.java:914) ~[?:1.8.0_151]
> at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) ~[?:?]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_151]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_151]
> at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1158) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2178) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2069) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1573) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2287) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2211) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2069) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1573) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:433) ~[?:1.8.0_151]
> at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:252) ~[?:1.8.0_151]
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161) ~[?:1.8.0_151]
> at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:227) ~[?:1.8.0_151]
> at java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:179) ~[?:1.8.0_151]
> at com.sun.proxy.$Proxy41.remoteCall(Unknown Source) ~[?:?]
> at org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl$1.invoke(RemoteBundleContextClientImpl.java:102) ~[pax-exam-container-rbc-client-4.11.0.jar:?]
> at com.sun.proxy.$Proxy42.call(Unknown Source) ~[?:?]
> at org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl.call(RemoteBundleContextClientImpl.java:290) ~[pax-exam-container-rbc-client-4.11.0.jar:?]
> at org.ops4j.pax.exam.container.remote.RBCRemoteTarget.call(RBCRemoteTarget.java:60) ~[pax-exam-container-remote-4.11.0.jar:?]
> at org.ops4j.pax.exam.karaf.container.internal.KarafTestContainer.call(KarafTestContainer.java:652) ~[pax-exam-container-karaf-4.11.0.jar:?]
> at org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.invoke(EagerSingleStagedReactor.java:109) ~[pax-exam-spi-4.11.0.jar:?]
> at org.ops4j.pax.exam.junit.impl.ProbeRunner$2.evaluate(ProbeRunner.java:267) ~[pax-exam-junit4-4.11.0.jar:?]
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) [junit-4.11.jar:?]
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) [junit-4.11.jar:?]
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) [junit-4.11.jar:?]
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) [junit-4.11.jar:?]
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) [junit-4.11.jar:?]
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) [junit-4.11.jar:?]
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) [junit-4.11.jar:?]
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) [junit-4.11.jar:?]
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309) [junit-4.11.jar:?]
> at org.ops4j.pax.exam.junit.impl.ProbeRunner.run(ProbeRunner.java:98) [pax-exam-junit4-4.11.0.jar:?]
> at org.ops4j.pax.exam.junit.PaxExam.run(PaxExam.java:93) [pax-exam-junit4-4.11.0.jar:?]
> at org.infinispan.it.osgi.util.CustomPaxExamRunner.run(CustomPaxExamRunner.java:73) [test-classes/:?]
> at org.junit.runners.Suite.runChild(Suite.java:127) [junit-4.11.jar:?]
> at org.junit.runners.Suite.runChild(Suite.java:26) [junit-4.11.jar:?]
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) [junit-4.11.jar:?]
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) [junit-4.11.jar:?]
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) [junit-4.11.jar:?]
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) [junit-4.11.jar:?]
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) [junit-4.11.jar:?]
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309) [junit-4.11.jar:?]
> at org.junit.runners.Suite.runChild(Suite.java:127) [junit-4.11.jar:?]
> at org.junit.runners.Suite.runChild(Suite.java:26) [junit-4.11.jar:?]
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) [junit-4.11.jar:?]
> at org.apache.maven.surefire.junitcore.pc.Scheduler$1.run(Scheduler.java:393) [surefire-junit47-2.20.jar:2.20]
> at org.apache.maven.surefire.junitcore.pc.InvokerStrategy.schedule(InvokerStrategy.java:54) [surefire-junit47-2.20.jar:2.20]
> at org.apache.maven.surefire.junitcore.pc.Scheduler.schedule(Scheduler.java:352) [surefire-junit47-2.20.jar:2.20]
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) [junit-4.11.jar:?]
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) [junit-4.11.jar:?]
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) [junit-4.11.jar:?]
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309) [junit-4.11.jar:?]
> at org.apache.maven.surefire.junitcore.pc.ParallelComputerBuilder$PC$1.run(ParallelComputerBuilder.java:595) [surefire-junit47-2.20.jar:2.20]
> at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55) [surefire-junit47-2.20.jar:2.20]
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137) [surefire-junit47-2.20.jar:2.20]
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107) [surefire-junit47-2.20.jar:2.20]
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83) [surefire-junit47-2.20.jar:2.20]
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75) [surefire-junit47-2.20.jar:2.20]
> at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:157) [surefire-junit47-2.20.jar:2.20]
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:386) [surefire-booter-2.20.jar:2.20]
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:323) [surefire-booter-2.20.jar:2.20]
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:143) [surefire-booter-2.20.jar:2.20]
> {noformat}
> The Windows/Solaris failures probably have the same cause, so we shouldn't need {{@SkipOnOS}} once we fix this.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (ISPN-8513) DistSyncOnePhaseTxStateTransferTest random failures
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-8513?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-8513:
--------------------------------
Fix Version/s: 9.2.0.Beta2
(was: 9.2.0.Beta1)
> DistSyncOnePhaseTxStateTransferTest random failures
> ---------------------------------------------------
>
> Key: ISPN-8513
> URL: https://issues.jboss.org/browse/ISPN-8513
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 9.2.0.Alpha2
> Reporter: Pedro Ruivo
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 9.2.0.Beta2
>
> Attachments: DistSyncOnePhaseTxStateTransferTest_pr_wburns_offheap_singlenode2_20171030.log.gz
>
>
> {{DistSyncOnePhaseTxStateTransferTest}} sometimes asserts that the x-site transfer has finished in the remote site too early:
> {noformat}
> 17:34:38,464 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.xsite.statetransfer.DistSyncOnePhaseTxStateTransferTest.testCancelStateTransfer[null, tx=false]
> java.lang.AssertionError:
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59) ~[testng-6.8.8.jar:?]
> at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:24) ~[testng-6.8.8.jar:?]
> at org.testng.AssertJUnit.assertFalse(AssertJUnit.java:41) ~[testng-6.8.8.jar:?]
> at org.testng.AssertJUnit.assertFalse(AssertJUnit.java:49) ~[testng-6.8.8.jar:?]
> at org.infinispan.xsite.statetransfer.BaseStateTransferTest$20.assertInCache(BaseStateTransferTest.java:601) ~[test-classes/:?]
> at org.infinispan.xsite.AbstractXSiteTest.assertInSite(AbstractXSiteTest.java:172) ~[test-classes/:?]
> at org.infinispan.xsite.statetransfer.BaseStateTransferTest.assertNoStateTransferInReceivingSite(BaseStateTransferTest.java:596) ~[test-classes/:?]
> at org.infinispan.xsite.statetransfer.BaseStateTransferTest.testCancelStateTransfer(BaseStateTransferTest.java:141) ~[test-classes/:?]
> {noformat}
> In fact, this part of the test seems to let the state transfer finish normally instead of cancelling it, so it could use some logs/comments to explain what's going on.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (ISPN-8522) PreferAvailabilityStrategy conflict resolution should occur if an expected member is not in max topology
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-8522?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-8522:
--------------------------------
Fix Version/s: 9.2.0.Beta2
(was: 9.2.0.Beta1)
> PreferAvailabilityStrategy conflict resolution should occur if an expected member is not in max topology
> --------------------------------------------------------------------------------------------------------
>
> Key: ISPN-8522
> URL: https://issues.jboss.org/browse/ISPN-8522
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.2.0.Alpha2
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Fix For: 9.2.0.Beta2
>
>
> The current method for determining whether a split brain heal is occurring during an on merge event is wrong. Instead we should assume healing whenever one or more of the expected members is not in the membership of the maxTopology received.
> Furthermore, we should also utilise the Union CH of all distinct CHs encountered for conflict resolution. This is necessary to ensure that we read the entries associated with all possible write owners before the rebalance occurs.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months