[JBoss JIRA] (ISPN-2402) Cache operations or transactions should never fail with SuspectException
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-2402?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-2402:
------------------------------------
Sanne, what is the exception you get when you do a cache operation? I don't think the exception you posted can ever be thrown from a Cache method.
> Cache operations or transactions should never fail with SuspectException
> ------------------------------------------------------------------------
>
> Key: ISPN-2402
> URL: https://issues.jboss.org/browse/ISPN-2402
> Project: Infinispan
> Issue Type: Task
> Components: RPC, State transfer
> Affects Versions: 5.2.0.Beta2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 5.3.0.Alpha1
>
> Attachments: vrstt.log
>
>
> This is an extension of ISPN-1896 of sorts, but for all the cache operations that are visible to the user.
> After a node leaves, the other nodes that have sent commands to that node should either ignore SuspectExceptions or, if not possible, they should retry the operation (e.g. if they didn't get any response back).
> For example, VersionReplStateTransferTest quite often on my machine with a SuspectException, because the versioned prepare command expects a response from the coordinator and the coordinator has just left.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (ISPN-2537) LockCleanupStateTransferTest fails randomly
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-2537?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-2537:
-------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1663
> LockCleanupStateTransferTest fails randomly
> -------------------------------------------
>
> Key: ISPN-2537
> URL: https://issues.jboss.org/browse/ISPN-2537
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 5.2.0.Beta4
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 5.3.0.Final
>
>
> LockCleanupStateTransferTest assumes that once the tx is done on one remote node it's done on all of them (and on the originator as well).
> It sometimes fails with this stack trace:
> {noformat}
> java.lang.AssertionError: For cache 0 expected:<0> but was:<1>
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.failNotEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:128)
> at org.junit.Assert.assertEquals(Assert.java:472)
> at org.infinispan.tx.LockCleanupStateTransferTest.testLockReleasedCorrectly(LockCleanupStateTransferTest.java:164)
> at org.infinispan.tx.LockCleanupStateTransferTest.testBelatedCommit(LockCleanupStateTransferTest.java:76)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (ISPN-2537) LockCleanupStateTransferTest fails randomly
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-2537?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-2537:
-------------------------------
Labels: 5.2.x (was: )
> LockCleanupStateTransferTest fails randomly
> -------------------------------------------
>
> Key: ISPN-2537
> URL: https://issues.jboss.org/browse/ISPN-2537
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 5.2.0.Beta4
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: 5.2.x
> Fix For: 5.3.0.Final
>
>
> LockCleanupStateTransferTest assumes that once the tx is done on one remote node it's done on all of them (and on the originator as well).
> It sometimes fails with this stack trace:
> {noformat}
> java.lang.AssertionError: For cache 0 expected:<0> but was:<1>
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.failNotEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:128)
> at org.junit.Assert.assertEquals(Assert.java:472)
> at org.infinispan.tx.LockCleanupStateTransferTest.testLockReleasedCorrectly(LockCleanupStateTransferTest.java:164)
> at org.infinispan.tx.LockCleanupStateTransferTest.testBelatedCommit(LockCleanupStateTransferTest.java:76)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (ISPN-2636) Support for Total Order Broadcast(TOB) Transactions
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-2636?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-2636:
------------------------------
Description:
The Total Order based commit protocol is a multi-master scheme as currently Two Phase Commit implementation.
This protocol relies on the concept of totally ordered delivery of messages which, informally, implies that each node which delivers a set of messages M, delivers them in the same order.
This protocol comes with two advantages.
1) transactions can be committed in one phase, as they are delivered in the same order by the nodes that receive them.
2) it totally avoids deadlocks.
The weakness point of this protocol is the fact that its implementation relies on a single thread per node which validates and commit transactions.
was:
The Total Order based commit protocol is a multi-master scheme as currently Two Phase Commit implementation.
This protocol relies on the concept of totally ordered delivery of messages which, informally, implies that each node which delivers a set of messages M, delivers them in the same order.
This protocol comes with two advantages.
1) transactions can be committed in one phase, as they are delivered in the same order by the nodes that receive them.
2) it totally avoids deadlocks. The weakness point of this protocol is the fact that its implementation relies on a single thread per node which validates and commit transactions.
> Support for Total Order Broadcast(TOB) Transactions
> ---------------------------------------------------
>
> Key: ISPN-2636
> URL: https://issues.jboss.org/browse/ISPN-2636
> Project: Infinispan
> Issue Type: Feature Request
> Components: Transactions
> Reporter: Mircea Markus
> Assignee: Pedro Ruivo
> Fix For: 5.3.0.Final
>
>
> The Total Order based commit protocol is a multi-master scheme as currently Two Phase Commit implementation.
> This protocol relies on the concept of totally ordered delivery of messages which, informally, implies that each node which delivers a set of messages M, delivers them in the same order.
> This protocol comes with two advantages.
> 1) transactions can be committed in one phase, as they are delivered in the same order by the nodes that receive them.
> 2) it totally avoids deadlocks.
> The weakness point of this protocol is the fact that its implementation relies on a single thread per node which validates and commit transactions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (ISPN-2635) Support for Total Order Multicast Transactions
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-2635?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-2635:
------------------------------
Description:
Based on CloudTM's implementation.
The Total Order based commit protocol is a multi-master scheme as currently Two Phase Commit implementation.
This protocol relies on the concept of totally ordered delivery of messages which, informally, implies that each node which delivers a set of messages M, delivers them in the same order.
This protocol comes with two advantages.
1) transactions can be committed in one phase, as they are delivered in the same order by the nodes that receive them.
2) it totally avoids deadlocks.
The weakness point of this protocol is the fact that its implementation relies on a single thread per node which validates and commit transactions.
was:
Based on CloudTM's implementation.
The Total Order based commit protocol is a multi-master scheme as currently Two Phase Commit implementation.
This protocol relies on the concept of totally ordered delivery of messages which, informally, implies that each node which delivers a set of messages M, delivers them in the same order.
This protocol comes with two advantages.
1) transactions can be committed in one phase, as they are delivered in the same order by the nodes that receive them.
2) it totally avoids deadlocks. The weakness point of this protocol is the fact that its implementation relies on a single thread per node which validates and commit transactions.
> Support for Total Order Multicast Transactions
> ----------------------------------------------
>
> Key: ISPN-2635
> URL: https://issues.jboss.org/browse/ISPN-2635
> Project: Infinispan
> Issue Type: Feature Request
> Components: Transactions
> Reporter: Mircea Markus
> Assignee: Pedro Ruivo
> Fix For: 5.3.0.Final
>
>
> Based on CloudTM's implementation.
> The Total Order based commit protocol is a multi-master scheme as currently Two Phase Commit implementation.
> This protocol relies on the concept of totally ordered delivery of messages which, informally, implies that each node which delivers a set of messages M, delivers them in the same order.
> This protocol comes with two advantages.
> 1) transactions can be committed in one phase, as they are delivered in the same order by the nodes that receive them.
> 2) it totally avoids deadlocks.
> The weakness point of this protocol is the fact that its implementation relies on a single thread per node which validates and commit transactions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (ISPN-2787) NPE after ReplaceCommand
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2787?page=com.atlassian.jira.plugin.... ]
Work on ISPN-2787 started by Adrian Nistor.
> NPE after ReplaceCommand
> ------------------------
>
> Key: ISPN-2787
> URL: https://issues.jboss.org/browse/ISPN-2787
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.0.Final
> Reporter: Michal Linhard
> Assignee: Adrian Nistor
> Fix For: 5.2.2.Final, 5.3.0.Final
>
>
> (from https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EDG6/view/EDG-REPOR...)
> {code}
> 05:11:10,804 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/].[Resteasy]] (http-/172.18.1.7:8080-15) Servlet.service() for servlet Resteasy threw exception: org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException
> at org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:351) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:220) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:196) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:551) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:513) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:125) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.1.Final-redhat-2.jar:1.0.1.Final-redhat-2]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:372) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_38]
> Caused by: java.lang.NullPointerException
> at org.infinispan.CacheImpl.replaceInternal(CacheImpl.java:828) [infinispan-core-5.2.0.CR3-redhat-1.jar:5.2.0.CR3-redhat-1]
> at org.infinispan.CacheImpl.replace(CacheImpl.java:822) [infinispan-core-5.2.0.CR3-redhat-1.jar:5.2.0.CR3-redhat-1]
> at org.infinispan.CacheImpl.replace(CacheImpl.java:817) [infinispan-core-5.2.0.CR3-redhat-1.jar:5.2.0.CR3-redhat-1]
> at org.infinispan.AbstractDelegatingCache.replace(AbstractDelegatingCache.java:153) [infinispan-core-5.2.0.CR3-redhat-1.jar:5.2.0.CR3-redhat-1]
> at org.infinispan.rest.Server.putOrReplace(Server.scala:186) [infinispan-server-rest-5.2.0.CR3-redhat-1-classes.jar:]
> at org.infinispan.rest.Server.org$infinispan$rest$Server$$putInCache(Server.scala:157) [infinispan-server-rest-5.2.0.CR3-redhat-1-classes.jar:]
> at org.infinispan.rest.Server$$anonfun$putEntry$1.apply(Server.scala:133) [infinispan-server-rest-5.2.0.CR3-redhat-1-classes.jar:]
> at org.infinispan.rest.Server$$anonfun$putEntry$1.apply(Server.scala:120) [infinispan-server-rest-5.2.0.CR3-redhat-1-classes.jar:]
> at org.infinispan.rest.Server.protectCacheNotFound(Server.scala:254) [infinispan-server-rest-5.2.0.CR3-redhat-1-classes.jar:]
> at org.infinispan.rest.Server.putEntry(Server.scala:120) [infinispan-server-rest-5.2.0.CR3-redhat-1-classes.jar:]
> at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source) [:1.6.0_38]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_38]
> at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_38]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:257) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:222) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:211) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:536) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> ... 18 more
> {code}
> Seems like the NPE is caused by ReplaceCommand.perform returning null:
> https://github.com/infinispan/infinispan/blob/5.2.0.Final/core/src/main/j...
> Made possible here:
> https://github.com/infinispan/infinispan/blob/5.2.0.Final/core/src/main/j...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (ISPN-2636) Support for Total Order Broadcast(TOB) Transactions
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-2636?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-2636:
------------------------------
Description:
The Total Order based commit protocol is a multi-master scheme as currently Two Phase Commit implementation.
This protocol relies on the concept of totally ordered delivery of messages which, informally, implies that each node which delivers a set of messages M, delivers them in the same order.
This protocol comes with two advantages.
1) transactions can be committed in one phase, as they are delivered in the same order by the nodes that receive them.
2) it totally avoids deadlocks. The weakness point of this protocol is the fact that its implementation relies on a single thread per node which validates and commit transactions.
> Support for Total Order Broadcast(TOB) Transactions
> ---------------------------------------------------
>
> Key: ISPN-2636
> URL: https://issues.jboss.org/browse/ISPN-2636
> Project: Infinispan
> Issue Type: Feature Request
> Components: Transactions
> Reporter: Mircea Markus
> Assignee: Pedro Ruivo
> Fix For: 5.3.0.Final
>
>
> The Total Order based commit protocol is a multi-master scheme as currently Two Phase Commit implementation.
> This protocol relies on the concept of totally ordered delivery of messages which, informally, implies that each node which delivers a set of messages M, delivers them in the same order.
> This protocol comes with two advantages.
> 1) transactions can be committed in one phase, as they are delivered in the same order by the nodes that receive them.
> 2) it totally avoids deadlocks. The weakness point of this protocol is the fact that its implementation relies on a single thread per node which validates and commit transactions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (ISPN-2635) Support for Total Order Multicast Transactions
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-2635?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-2635:
------------------------------
Description:
Based on CloudTM's implementation.
The Total Order based commit protocol is a multi-master scheme as currently Two Phase Commit implementation.
This protocol relies on the concept of totally ordered delivery of messages which, informally, implies that each node which delivers a set of messages M, delivers them in the same order.
This protocol comes with two advantages.
1) transactions can be committed in one phase, as they are delivered in the same order by the nodes that receive them.
2) it totally avoids deadlocks. The weakness point of this protocol is the fact that its implementation relies on a single thread per node which validates and commit transactions.
was:Based on CloudTM's implementation.
> Support for Total Order Multicast Transactions
> ----------------------------------------------
>
> Key: ISPN-2635
> URL: https://issues.jboss.org/browse/ISPN-2635
> Project: Infinispan
> Issue Type: Feature Request
> Components: Transactions
> Reporter: Mircea Markus
> Assignee: Pedro Ruivo
> Fix For: 5.3.0.Final
>
>
> Based on CloudTM's implementation.
> The Total Order based commit protocol is a multi-master scheme as currently Two Phase Commit implementation.
> This protocol relies on the concept of totally ordered delivery of messages which, informally, implies that each node which delivers a set of messages M, delivers them in the same order.
> This protocol comes with two advantages.
> 1) transactions can be committed in one phase, as they are delivered in the same order by the nodes that receive them.
> 2) it totally avoids deadlocks. The weakness point of this protocol is the fact that its implementation relies on a single thread per node which validates and commit transactions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (ISPN-2402) Cache operations or transactions should never fail with SuspectException
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-2402?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on ISPN-2402:
---------------------------------------
I've also hit failures on simple Cache operations because of
{code}2013-02-14 18:50:08,520 WARN [CacheTopologyControlCommand] (OOB-1,Infinispan-Query-Cluster,NodeA-17773) ISPN000071: Caught exception when handling command CacheTopologyControlCommand{cache=LuceneIndexesData, type=REBALANCE_CONFIRM, sender=NodeD-64761, joinInfo=null, topologyId=8, currentCH=null, pendingCH=null, throwable=null, viewId=3}
org.infinispan.CacheException: Received invalid rebalance confirmation from NodeD-64761 for cache LuceneIndexesData, we don't have a rebalance in progress
at org.infinispan.topology.ClusterTopologyManagerImpl.handleRebalanceCompleted(ClusterTopologyManagerImpl.java:206)
at org.infinispan.topology.CacheTopologyControlCommand.doPerform(CacheTopologyControlCommand.java:160)
at org.infinispan.topology.CacheTopologyControlCommand.perform(CacheTopologyControlCommand.java:137)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:253)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:220)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:484)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:391)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:249)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:598)
at org.jgroups.JChannel.up(JChannel.java:707)
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020)
at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
at org.jgroups.protocols.FC.up(FC.java:479)
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:896)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:245)
at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:765)
at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:420)
at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:606)
at org.jgroups.protocols.Discovery.up(Discovery.java:359)
at org.jgroups.protocols.TP.passMessageUp(TP.java:1263)
at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1825)
at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1798)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886){code}
Dan, is part of this same issue or should I open a separate one?
> Cache operations or transactions should never fail with SuspectException
> ------------------------------------------------------------------------
>
> Key: ISPN-2402
> URL: https://issues.jboss.org/browse/ISPN-2402
> Project: Infinispan
> Issue Type: Task
> Components: RPC, State transfer
> Affects Versions: 5.2.0.Beta2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 5.3.0.Alpha1
>
> Attachments: vrstt.log
>
>
> This is an extension of ISPN-1896 of sorts, but for all the cache operations that are visible to the user.
> After a node leaves, the other nodes that have sent commands to that node should either ignore SuspectExceptions or, if not possible, they should retry the operation (e.g. if they didn't get any response back).
> For example, VersionReplStateTransferTest quite often on my machine with a SuspectException, because the versioned prepare command expects a response from the coordinator and the coordinator has just left.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (ISPN-2756) Enabling/disabling RpcManager statistics via JMX doesn't work
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2756?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2756:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 906236|https://bugzilla.redhat.com/show_bug.cgi?id=906236] from MODIFIED to ON_QA
> Enabling/disabling RpcManager statistics via JMX doesn't work
> -------------------------------------------------------------
>
> Key: ISPN-2756
> URL: https://issues.jboss.org/browse/ISPN-2756
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 5.2.0.CR2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 5.2.0.Final
>
>
> The test RpcManagerMBeanTest.testEnableJmxStats tries to write to the "StatisticsEnabled" attribute but fails. The operation doesn't throw an exception, but it does log this WARN message:
> {noformat}
> 10:43:42,079 WARN (testng-RpcManagerMBeanTest:) [ResourceDMBean] ISPN000043: Exception while writing value for attribute statisticsEnabled
> java.lang.NullPointerException
> at org.infinispan.jmx.ResourceDMBean$InvokableSetterBasedMBeanAttributeInfo.invoke(ResourceDMBean.java:391)
> at org.infinispan.jmx.ResourceDMBean.setNamedAttribute(ResourceDMBean.java:325)
> at org.infinispan.jmx.ResourceDMBean.setAttribute(ResourceDMBean.java:212)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.setAttribute(DefaultMBeanServerInterceptor.java:746)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.setAttribute(JmxMBeanServer.java:729)
> at org.infinispan.jmx.RpcManagerMBeanTest.testEnableJmxStats(RpcManagerMBeanTest.java:134)
> {noformat}
> Because statistics are still enabled, the test then fails with an assertion error:
> {noformat}
> 10:43:42,464 ERROR (testng-RpcManagerMBeanTest:) [UnitTestTestNGListener] Test testEnableJmxStats(org.infinispan.jmx.RpcManagerMBeanTest) failed.
> java.lang.AssertionError: expected [-1] but found [1]
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.failNotEquals(Assert.java:494)
> at org.testng.Assert.assertEquals(Assert.java:123)
> at org.testng.Assert.assertEquals(Assert.java:165)
> at org.infinispan.jmx.RpcManagerMBeanTest.testEnableJmxStats(RpcManagerMBeanTest.java:138)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month