[JBoss JIRA] (ISPN-11706) Use XidImpl internally
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-11706?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-11706:
-----------------------------------
Sprint: DataGrid Sprint #43, DataGrid Sprint #44 (was: DataGrid Sprint #43)
> Use XidImpl internally
> ----------------------
>
> Key: ISPN-11706
> URL: https://issues.redhat.com/browse/ISPN-11706
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core, Transactions
> Affects Versions: 11.0.0.Dev04
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Priority: Major
>
> We can use {{XidImpl}} to store external {{Xid}} in our internals. This way, we only need to handle one implementation internally that makes life easier with protostream.
> Action plan:
> * Remove {{EmbeddedXid}} and move generator code to {{EmbbededTransaction}}
> * Remove {{RemoteXid}} and move generator code to {{RemoteTransaction}}
> * Update {{XidImpl.copy()}}
> * Create protostream marshaller
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 7 months
[JBoss JIRA] (ISPN-11634) Merge TopologyUpdateStableCommand and TopologyUpdateCommand
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-11634?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-11634:
-----------------------------------
Sprint: DataGrid Sprint #43, DataGrid Sprint #44 (was: DataGrid Sprint #43)
> Merge TopologyUpdateStableCommand and TopologyUpdateCommand
> -----------------------------------------------------------
>
> Key: ISPN-11634
> URL: https://issues.redhat.com/browse/ISPN-11634
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 11.0.0.Dev04
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 11.0.0.CR1
>
>
> {code:java}
> 19:48:14,672 TRACE (testng-Test:[]) [TopologyManagementHelper] Attempting to execute command on self: StableTopologyUpdateCommand{cacheName='testCache', origin=Test-NodeD, currentCH=DefaultConsistentHash
> {ns=256, owners = (1)[Test-NodeE: 256+0]}
> , pendingCH=null, actualMembers=[Test-NodeE], persistentUUIDs=[72b17309-62d1-4928-abf6-88a8606ef342], rebalanceId=5, topologyId=27, viewId=7}
> 19:48:14,686 INFO (jgroups-5,Test-NodeE:[]) [CLUSTER] ISPN000094: Received new cluster view for channel org.infinispan.statetransfer.Test: [Test-NodeE|8] (1) [Test-NodeE]
> 19:48:14,690 TRACE (non-blocking-thread-Test-NodeE-p9541-t5:[Merge-8]) [PreferConsistencyStrategy] Max stable partition topology: CacheTopology{id=25, phase=NO_REBALANCE, rebalanceId=5, currentCH=DefaultConsistentHash
> {ns=256, owners = (2)[Test-NodeD: 129+127, Test-NodeE: 127+129]}
> , pendingCH=null, unionCH=null, actualMembers=[Test-NodeD, Test-NodeE], persistentUUIDs=[099401f9-c0b6-460d-8dc8-5051699e8287, 72b17309-62d1-4928-abf6-88a8606ef342]}
> 19:48:14,690 TRACE (non-blocking-thread-Test-NodeE-p9541-t5:[Merge-8]) [PreferConsistencyStrategy] Max active partition topology: CacheTopology{id=27, phase=NO_REBALANCE, rebalanceId=5, currentCH=DefaultConsistentHash
> {ns=256, owners = (1)[Test-NodeE: 256+0]}
> , pendingCH=null, unionCH=null, actualMembers=[Test-NodeE], persistentUUIDs=[72b17309-62d1-4928-abf6-88a8606ef342]}
> 19:48:14,690 DEBUG (non-blocking-thread-Test-NodeE-p9541-t3:[]) [LocalTopologyManagerImpl] Ignoring topology 27 for cache testCache from old coordinator Test-NodeD
> {code}
> The old coordinator (NodeD) sent the topology update and the stable topology update, and NodeE received both. However NodeE might ignores the stable topology update because it was processed after it got the new cluster view, with itself as the coordinator. The proper fix is to get rid of the StableTopologyUpdateCommand and add a stable=true/false field in CacheTopology or in TopologyUpdateCommand.
> There's still a small chance that the coordinator will shut down before sending the topology update command to any of the other nodes, but it's a small chance. It's much more likely that a separate stable topology update command will be ignored because it is queued by LocalTopologyManagerImpl after the regular topology update command, and the regular topology update has a lot of processing to do in StateConsumerImpl.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 7 months
[JBoss JIRA] (ISPN-5938) ClusterListenerReplInitialStateTest.testPrimaryOwnerGoesDownAfterBackupRaisesEvent fails randomly
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-5938?page=com.atlassian.jira.plugin... ]
Tristan Tarrant updated ISPN-5938:
----------------------------------
Fix Version/s: 11.0.0.CR1
(was: 11.0.0.Dev05)
> ClusterListenerReplInitialStateTest.testPrimaryOwnerGoesDownAfterBackupRaisesEvent fails randomly
> -------------------------------------------------------------------------------------------------
>
> Key: ISPN-5938
> URL: https://issues.redhat.com/browse/ISPN-5938
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 11.0.0.Alpha1
> Reporter: Roman Macor
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 11.0.0.CR1
>
>
> ClusterListenerReplInitialStateTest.testPrimaryOwnerGoesDownAfterBackupRaisesEvent fails randomly with:
> Stacktrace
> java.util.concurrent.TimeoutException
> at java.util.concurrent.FutureTask.get(FutureTask.java:205)
> at org.infinispan.notifications.cachelistener.cluster.ClusterListenerReplTest.testPrimaryOwnerGoesDownAfterBackupRaisesEvent(ClusterListenerReplTest.java:123)
> 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:497)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 7 months