[JBoss JIRA] (ISPN-7558) IllegalLifecycleStateException due to Cache marshaller has been stopped
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/ISPN-7558?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated ISPN-7558:
---------------------------------
Affects Version/s: 8.2.6.Final
> IllegalLifecycleStateException due to Cache marshaller has been stopped
> -----------------------------------------------------------------------
>
> Key: ISPN-7558
> URL: https://issues.jboss.org/browse/ISPN-7558
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.2.6.Final
> Reporter: Radoslav Husar
> Assignee: Paul Ferraro
> Priority: Minor
>
> We saw this error in *failover* scenarios:
> {code}
> 14:28:41,783 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 85) WFLYCLINF0003: Stopped client-mappings cache from ejb container
> [JBossINF] 14:28:41,783 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 77) WFLYCLINF0003: Stopped routing cache from web container
> [JBossINF] 14:28:41,790 INFO [org.infinispan.CLUSTER] (remote-thread--p8-t3) [Context=client-mappings][Scope=perf20]ISPN100003: Finished local rebalance
> [JBossINF] 14:28:41,791 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting JGroups channel ejb
> [JBossINF] 14:28:41,791 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher for channel ejb
> [JBossINF] 14:28:41,792 INFO [org.infinispan.CLUSTER] (remote-thread--p7-t6) [Context=routing][Scope=perf20]ISPN100003: Finished local rebalance
> [JBossINF] 14:28:41,797 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000080: Disconnecting JGroups channel web
> [JBossINF] 14:28:41,799 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000082: Stopping the RpcDispatcher for channel web
> [JBossINF] 14:28:41,818 ERROR [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (thread-19) ISPN000065: Exception while marshalling object: CacheNotFoundResponse: org.infinispan.IllegalLifecycleStateException: Cache marshaller has been stopped
> [JBossINF] at org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.getExternalizerTable(JBossMarshaller.java:155)
> [JBossINF] at org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.getObjectWriter(JBossMarshaller.java:144)
> [JBossINF] at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:132)
> [JBossINF] at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:58)
> [JBossINF] at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:111)
> [JBossINF] at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectToObjectStream(AbstractJBossMarshaller.java:72)
> [JBossINF] at org.infinispan.marshall.core.VersionAwareMarshaller.objectToBuffer(VersionAwareMarshaller.java:77)
> [JBossINF] at org.infinispan.commons.marshall.AbstractMarshaller.objectToBuffer(AbstractMarshaller.java:41)
> [JBossINF] at org.infinispan.commons.marshall.AbstractDelegatingMarshaller.objectToBuffer(AbstractDelegatingMarshaller.java:85)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.MarshallerAdapter.objectToBuffer(MarshallerAdapter.java:23)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.reply(CommandAwareRpcDispatcher.java:248)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.lambda$executeCommandFromLocalCluster$1(CommandAwareRpcDispatcher.java:199)
> [JBossINF] at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleCacheRpcCommand(GlobalInboundInvocationHandler.java:121)
> [JBossINF] at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleFromCluster(GlobalInboundInvocationHandler.java:75)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:200)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:169)
> [JBossINF] at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:455)
> [JBossINF] at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:406)
> [JBossINF] at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357)
> [JBossINF] at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245)
> [JBossINF] at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664)
> [JBossINF] at org.jgroups.JChannel.up(JChannel.java:738)
> [JBossINF] at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120)
> [JBossINF] at org.jgroups.stack.Protocol.up(Protocol.java:380)
> [JBossINF] at org.jgroups.protocols.FORK.up(FORK.java:114)
> [JBossINF] at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> [JBossINF] at org.jgroups.protocols.FlowControl.up(FlowControl.java:374)
> [JBossINF] at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> [JBossINF] at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1037)
> [JBossINF] at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234)
> [JBossINF] at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:442)
> [JBossINF] at org.jgroups.protocols.pbcast.NAKACK2.deliver(NAKACK2.java:968)
> [JBossINF] at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:848)
> [JBossINF] at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:611)
> [JBossINF] at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
> [JBossINF] at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:200)
> [JBossINF] at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:325)
> [JBossINF] at org.jgroups.protocols.MERGE3.up(MERGE3.java:292)
> [JBossINF] at org.jgroups.protocols.Discovery.up(Discovery.java:296)
> [JBossINF] at org.jgroups.protocols.TP.passMessageUp(TP.java:1657)
> [JBossINF] at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1872)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> [JBossINF] Caused by: an exception which occurred:
> [JBossINF] in object org.infinispan.IllegalLifecycleStateException@244b87df
> [JBossINF] -> toString = org.infinispan.IllegalLifecycleStateException: Cache marshaller has been stopped
> [JBossINF]
> [JBossINF] 14:28:41,912 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0009: Undeployed "clusterbench-ee7.ear" (runtime-name: "clusterbench-ee7.ear")
> {code}
> Error occurs on *server* in three *async* scenarios during server stopping.
> Client is not affected.
> Scenarios affected:
> ejb-ejbremote-shutdown-repl-async (2 occurences)
> ejb-ejbremote-undeploy-dist-async (1 occurence)
> ejb-ejbservlet-undeploy-repl-sync (2 occurences)
> http-granular-shutdown-dist-sync (1 occurence)
> http-session-shutdown-repl-async (1 occurence)
> http-session-shutdown-concurrent-async (1 occurence)
> Link to server log:
> http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap-7x-fa...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ISPN-7558) IllegalLifecycleStateException due to Cache marshaller has been stopped
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/ISPN-7558?page=com.atlassian.jira.plugin.... ]
Radoslav Husar moved JBEAP-9302 to ISPN-7558:
---------------------------------------------
Project: Infinispan (was: JBoss Enterprise Application Platform)
Key: ISPN-7558 (was: JBEAP-9302)
Workflow: GIT Pull Request with Triage workflow (was: CDW with loose statuses v1)
Component/s: Core
(was: Clustering)
Affects Version/s: (was: 7.1.0.DR12)
> IllegalLifecycleStateException due to Cache marshaller has been stopped
> -----------------------------------------------------------------------
>
> Key: ISPN-7558
> URL: https://issues.jboss.org/browse/ISPN-7558
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Reporter: Radoslav Husar
> Assignee: Paul Ferraro
> Priority: Minor
>
> We saw this error in *failover* scenarios:
> {code}
> 14:28:41,783 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 85) WFLYCLINF0003: Stopped client-mappings cache from ejb container
> [JBossINF] 14:28:41,783 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 77) WFLYCLINF0003: Stopped routing cache from web container
> [JBossINF] 14:28:41,790 INFO [org.infinispan.CLUSTER] (remote-thread--p8-t3) [Context=client-mappings][Scope=perf20]ISPN100003: Finished local rebalance
> [JBossINF] 14:28:41,791 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting JGroups channel ejb
> [JBossINF] 14:28:41,791 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher for channel ejb
> [JBossINF] 14:28:41,792 INFO [org.infinispan.CLUSTER] (remote-thread--p7-t6) [Context=routing][Scope=perf20]ISPN100003: Finished local rebalance
> [JBossINF] 14:28:41,797 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000080: Disconnecting JGroups channel web
> [JBossINF] 14:28:41,799 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000082: Stopping the RpcDispatcher for channel web
> [JBossINF] 14:28:41,818 ERROR [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (thread-19) ISPN000065: Exception while marshalling object: CacheNotFoundResponse: org.infinispan.IllegalLifecycleStateException: Cache marshaller has been stopped
> [JBossINF] at org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.getExternalizerTable(JBossMarshaller.java:155)
> [JBossINF] at org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.getObjectWriter(JBossMarshaller.java:144)
> [JBossINF] at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:132)
> [JBossINF] at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:58)
> [JBossINF] at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:111)
> [JBossINF] at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectToObjectStream(AbstractJBossMarshaller.java:72)
> [JBossINF] at org.infinispan.marshall.core.VersionAwareMarshaller.objectToBuffer(VersionAwareMarshaller.java:77)
> [JBossINF] at org.infinispan.commons.marshall.AbstractMarshaller.objectToBuffer(AbstractMarshaller.java:41)
> [JBossINF] at org.infinispan.commons.marshall.AbstractDelegatingMarshaller.objectToBuffer(AbstractDelegatingMarshaller.java:85)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.MarshallerAdapter.objectToBuffer(MarshallerAdapter.java:23)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.reply(CommandAwareRpcDispatcher.java:248)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.lambda$executeCommandFromLocalCluster$1(CommandAwareRpcDispatcher.java:199)
> [JBossINF] at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleCacheRpcCommand(GlobalInboundInvocationHandler.java:121)
> [JBossINF] at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleFromCluster(GlobalInboundInvocationHandler.java:75)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:200)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:169)
> [JBossINF] at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:455)
> [JBossINF] at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:406)
> [JBossINF] at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357)
> [JBossINF] at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245)
> [JBossINF] at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664)
> [JBossINF] at org.jgroups.JChannel.up(JChannel.java:738)
> [JBossINF] at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120)
> [JBossINF] at org.jgroups.stack.Protocol.up(Protocol.java:380)
> [JBossINF] at org.jgroups.protocols.FORK.up(FORK.java:114)
> [JBossINF] at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> [JBossINF] at org.jgroups.protocols.FlowControl.up(FlowControl.java:374)
> [JBossINF] at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> [JBossINF] at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1037)
> [JBossINF] at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234)
> [JBossINF] at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:442)
> [JBossINF] at org.jgroups.protocols.pbcast.NAKACK2.deliver(NAKACK2.java:968)
> [JBossINF] at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:848)
> [JBossINF] at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:611)
> [JBossINF] at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
> [JBossINF] at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:200)
> [JBossINF] at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:325)
> [JBossINF] at org.jgroups.protocols.MERGE3.up(MERGE3.java:292)
> [JBossINF] at org.jgroups.protocols.Discovery.up(Discovery.java:296)
> [JBossINF] at org.jgroups.protocols.TP.passMessageUp(TP.java:1657)
> [JBossINF] at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1872)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> [JBossINF] Caused by: an exception which occurred:
> [JBossINF] in object org.infinispan.IllegalLifecycleStateException@244b87df
> [JBossINF] -> toString = org.infinispan.IllegalLifecycleStateException: Cache marshaller has been stopped
> [JBossINF]
> [JBossINF] 14:28:41,912 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0009: Undeployed "clusterbench-ee7.ear" (runtime-name: "clusterbench-ee7.ear")
> {code}
> Error occurs on *server* in three *async* scenarios during server stopping.
> Client is not affected.
> Scenarios affected:
> ejb-ejbremote-shutdown-repl-async (2 occurences)
> ejb-ejbremote-undeploy-dist-async (1 occurence)
> ejb-ejbservlet-undeploy-repl-sync (2 occurences)
> http-granular-shutdown-dist-sync (1 occurence)
> http-session-shutdown-repl-async (1 occurence)
> http-session-shutdown-concurrent-async (1 occurence)
> Link to server log:
> http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap-7x-fa...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ISPN-7556) Decoder2x.readOptionalParams should not call markReaderIndex()
by Dan Berindei (JIRA)
Dan Berindei created ISPN-7556:
----------------------------------
Summary: Decoder2x.readOptionalParams should not call markReaderIndex()
Key: ISPN-7556
URL: https://issues.jboss.org/browse/ISPN-7556
Project: Infinispan
Issue Type: Bug
Components: Server
Affects Versions: 9.0.0.CR2
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 9.0.0.Final
{{Decoder2x.readOptionalParams()}} calls {{buffer.markReaderIndex()}} after reading each parameter, but doesn't save the parameters anywhere. That means if the buffer doesn't contain all the parameters, the decode pass ends unsuccessfully, and the next decode pass doesn't see the parameters read by the previous pass.
Higher-level methods like {{Decoder2x.readMaybeNamedFactory()}} also call {{readOptionalParams()}} without saving their own state first, meaning their state can be lost as well.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ISPN-6040) FunctionalNonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringRemove random failures
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-6040?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo commented on ISPN-6040:
-----------------------------------
I think Radim's changes to the entry wrapping interceptor may fixed this test. I enabled again in https://github.com/infinispan/infinispan/pull/4934
> FunctionalNonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringRemove random failures
> -------------------------------------------------------------------------------------------------------
>
> Key: ISPN-6040
> URL: https://issues.jboss.org/browse/ISPN-6040
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite - Core
> Affects Versions: 8.1.0.Final
> Reporter: Dan Berindei
> Assignee: Galder Zamarreño
> Priority: Blocker
> Labels: testsuite_stability
> Fix For: 9.0.0.Final
>
>
> Similar to ISPN-6039, the test failure is caused by the state transfer put happening after the test's remove.
> In this case, the command types are different, so blocking works correctly. However, when the {{ReadWriteKeyValueCommand}} executes before the state transfer put, it doesn't find any value, and it doesn't commit the entry. This means the key is not added to {{CommitManager}}'s {{tracker}} map, and the state transfer put is allowed to write to it - effectively undoing the remove.
> {noformat}
> java.lang.AssertionError: expected:<null> but was:<v0>
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
> at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:88)
> at org.infinispan.distribution.rehash.NonTxBackupOwnerBecomingPrimaryOwnerTest.doTest(NonTxBackupOwnerBecomingPrimaryOwnerTest.java:194)
> at org.infinispan.functional.distribution.rehash.FunctionalNonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringRemove(FunctionalNonTxBackupOwnerBecomingPrimaryOwnerTest.java:103)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ISPN-6039) NonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringPutOverwrite random failures
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-6039?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-6039:
------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/4934
> NonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringPutOverwrite random failures
> ---------------------------------------------------------------------------------------------------
>
> Key: ISPN-6039
> URL: https://issues.jboss.org/browse/ISPN-6039
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 8.1.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Blocker
> Labels: testsuite_stability
> Fix For: 9.0.0.Final
>
>
> The problem is that the state transfer write can happen after we started the regular put, and is blocked by the {{BlockingInterceptor}}. The test then unblocks the state transfer put, but never unblocks the regular put, which eventually times out.
> {noformat}
> java.util.concurrent.TimeoutException
> at java.util.concurrent.FutureTask.get(FutureTask.java:205)
> at org.infinispan.distribution.rehash.NonTxBackupOwnerBecomingPrimaryOwnerTest.doTest(NonTxBackupOwnerBecomingPrimaryOwnerTest.java:193)
> at org.infinispan.distribution.rehash.NonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringPutOverwrite(NonTxBackupOwnerBecomingPrimaryOwnerTest.java:75)
> {noformat}
> The test should be more explicit about the state transfer put - ideally it should have 2 cases, one with the state transfer put happening before the regular put, and one after.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ISPN-6039) NonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringPutOverwrite random failures
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-6039?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo reassigned ISPN-6039:
---------------------------------
Assignee: Pedro Ruivo (was: Dan Berindei)
> NonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringPutOverwrite random failures
> ---------------------------------------------------------------------------------------------------
>
> Key: ISPN-6039
> URL: https://issues.jboss.org/browse/ISPN-6039
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 8.1.0.Final
> Reporter: Dan Berindei
> Assignee: Pedro Ruivo
> Priority: Blocker
> Labels: testsuite_stability
> Fix For: 9.0.0.Final
>
>
> The problem is that the state transfer write can happen after we started the regular put, and is blocked by the {{BlockingInterceptor}}. The test then unblocks the state transfer put, but never unblocks the regular put, which eventually times out.
> {noformat}
> java.util.concurrent.TimeoutException
> at java.util.concurrent.FutureTask.get(FutureTask.java:205)
> at org.infinispan.distribution.rehash.NonTxBackupOwnerBecomingPrimaryOwnerTest.doTest(NonTxBackupOwnerBecomingPrimaryOwnerTest.java:193)
> at org.infinispan.distribution.rehash.NonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringPutOverwrite(NonTxBackupOwnerBecomingPrimaryOwnerTest.java:75)
> {noformat}
> The test should be more explicit about the state transfer put - ideally it should have 2 cases, one with the state transfer put happening before the regular put, and one after.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ISPN-5021) Nodes that finish the rebalance later can see outdated values
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/ISPN-5021?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated ISPN-5021:
---------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/4862 (was: https://github.com/infinispan/infinispan/pull/4827, https://github.com/infinispan/infinispan/pull/4862)
> Nodes that finish the rebalance later can see outdated values
> -------------------------------------------------------------
>
> Key: ISPN-5021
> URL: https://issues.jboss.org/browse/ISPN-5021
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 7.0.2.Final
> Reporter: Dan Berindei
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: consistency, testsuite_stability
> Fix For: 9.0.0.Final
>
>
> Copied from [ISPN-4444|https://issues.jboss.org/browse/ISPN-4444?focusedCommentId=1302...]
> If the CH_UPDATE command is delayed on the old owner, the new owners might update the key without the old owner knowing, and a locality check on the old owner won't help.
> I remember one thing that struck me when reading the Raft algorithm was that they install configuration changes symmetrically, in 3 phases. We might need to do the same for our rebalance:
> 1. T0: read_ch=old, write_ch=old
> 2. start a rebalance
> 3. T1: read_ch=old, write_ch=old+new
> 4. new owners have all the data
> 5. T2: read_ch=new, write_ch=old+new
> 6. remove old cache entries and ignore further writes
> 7. T3: read_ch=new, write_ch=new
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ISPN-5021) Nodes that finish the rebalance later can see outdated values
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/ISPN-5021?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on ISPN-5021:
------------------------------------
FYI - we are running into this bug on EAP 7.1. Please backport this fix to 8.2.x.
> Nodes that finish the rebalance later can see outdated values
> -------------------------------------------------------------
>
> Key: ISPN-5021
> URL: https://issues.jboss.org/browse/ISPN-5021
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 7.0.2.Final
> Reporter: Dan Berindei
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: consistency, testsuite_stability
> Fix For: 9.0.0.Final
>
>
> Copied from [ISPN-4444|https://issues.jboss.org/browse/ISPN-4444?focusedCommentId=1302...]
> If the CH_UPDATE command is delayed on the old owner, the new owners might update the key without the old owner knowing, and a locality check on the old owner won't help.
> I remember one thing that struck me when reading the Raft algorithm was that they install configuration changes symmetrically, in 3 phases. We might need to do the same for our rebalance:
> 1. T0: read_ch=old, write_ch=old
> 2. start a rebalance
> 3. T1: read_ch=old, write_ch=old+new
> 4. new owners have all the data
> 5. T2: read_ch=new, write_ch=old+new
> 6. remove old cache entries and ignore further writes
> 7. T3: read_ch=new, write_ch=new
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ISPN-7555) Originator node in launch new task dialog is not displayed correctly in standalone mode
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-7555?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic reassigned ISPN-7555:
-----------------------------------------
Assignee: Vladimir Blagojevic
> Originator node in launch new task dialog is not displayed correctly in standalone mode
> ---------------------------------------------------------------------------------------
>
> Key: ISPN-7555
> URL: https://issues.jboss.org/browse/ISPN-7555
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 9.0.0.CR2
> Reporter: Roman Macor
> Assignee: Vladimir Blagojevic
> Priority: Minor
>
> - start server in standalone clustered mode - bin/standalone.sh -c clustered.xml
> - click on cache container - Tasks execution tab -> Launch new task -> click on Originator node
> result: the node is displayed like this: terminator:terminator, if we set the server name, e.g. server-one, it's displayed like this: server-one:server-one ("terminator" is hostname from /etc/hostname)
> expected result: host-name:server-name (same as in domain mode)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month