[JBoss JIRA] (ISPN-2825) ClusterTopologyManagerImpl should not hold a lock while invoking an RPC
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2825?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2825:
--------------------------------
Priority: Critical (was: Major)
> ClusterTopologyManagerImpl should not hold a lock while invoking an RPC
> -----------------------------------------------------------------------
>
> Key: ISPN-2825
> URL: https://issues.jboss.org/browse/ISPN-2825
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 5.3.0.Alpha1
>
>
> On the coordinator, ClusterTopologyManagerImpl holds a lock on a cache's ClusterCacheStatus while it is invoking a synchronous REBALANCE_START or CH_UPDATE command. This helps ensure the ordering of the commands is the same on all the members.
> However, this has some downsides. On a joining node, it takes quite some time before replying to the coordinator (as it needs to request transactions from the other nodes). The nodes that don't need to request any data will send a REBALANCE_CONFIRM command to the coordinator right away, but that command will block on the ClusterCacheStatus lock. If the number of OOB threads is limited, this can even lead to a deadlock.
> Now that CH_UPDATE commands also increment the topology id, we don't really need to enforce the same ordering. If a CH_UPDATE command is sent after a REBALANCE_START command but arrives before it, LocalTopologyManagerImpl just needs to act as if the CH_UPDATE command was actually a REBALANCE_START. (It knows there should be a rebalance when a CH_UPDATE command has pendingCH != null.)
--
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
11 years, 10 months
[JBoss JIRA] (ISPN-2825) ClusterTopologyManagerImpl should not hold a lock while invoking an RPC
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2825?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2825:
--------------------------------
Fix Version/s: 5.3.0.Final
> ClusterTopologyManagerImpl should not hold a lock while invoking an RPC
> -----------------------------------------------------------------------
>
> Key: ISPN-2825
> URL: https://issues.jboss.org/browse/ISPN-2825
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 5.3.0.Alpha1, 5.3.0.Final
>
>
> On the coordinator, ClusterTopologyManagerImpl holds a lock on a cache's ClusterCacheStatus while it is invoking a synchronous REBALANCE_START or CH_UPDATE command. This helps ensure the ordering of the commands is the same on all the members.
> However, this has some downsides. On a joining node, it takes quite some time before replying to the coordinator (as it needs to request transactions from the other nodes). The nodes that don't need to request any data will send a REBALANCE_CONFIRM command to the coordinator right away, but that command will block on the ClusterCacheStatus lock. If the number of OOB threads is limited, this can even lead to a deadlock.
> Now that CH_UPDATE commands also increment the topology id, we don't really need to enforce the same ordering. If a CH_UPDATE command is sent after a REBALANCE_START command but arrives before it, LocalTopologyManagerImpl just needs to act as if the CH_UPDATE command was actually a REBALANCE_START. (It knows there should be a rebalance when a CH_UPDATE command has pendingCH != null.)
--
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
11 years, 10 months
[JBoss JIRA] (ISPN-2897) NPE in DefaultConsistentHash
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2897?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2897:
--------------------------------
Priority: Critical (was: Major)
> NPE in DefaultConsistentHash
> ----------------------------
>
> Key: ISPN-2897
> URL: https://issues.jboss.org/browse/ISPN-2897
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 5.2.3.Final
> Reporter: Michal Linhard
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 5.2.x
> Fix For: 5.3.0.Alpha1, 5.3.0.Final
>
> Attachments: serverlogs.zip
>
>
> Happened in local testing on my laptop with 4 nodes JDG 6.1.0.CR1 (ISPN 5.2.3.Final)
> For some reason there's a rebalance with pendingCH=null and this is not handled well by DefaultConsistentHash.union:
> {code}
> 15:11:04,782 DEBUG [org.infinispan.topology.LocalTopologyManagerImpl] (OOB-5,shared=udp) Starting local rebalance for cache testCache, topology = CacheTopology{id=3, currentCH=DefaultConsistentHash{numSegments=40, numOwners=2, members=[node04/default]}, pendingCH=null}
> 15:11:04,782 WARN [org.infinispan.topology.CacheTopologyControlCommand] (OOB-5,shared=udp) ISPN000071: Caught exception when handling command CacheTopologyControlCommand{cache=testCache, type=REBALANCE_START, sender=node04/default, joinInfo=null, topologyId=3, currentCH=DefaultConsistentHash{numSegments=40, numOwners=2, members=[node04/default]}, pendingCH=null, throwable=null, viewId=4}: java.lang.NullPointerException
> at org.infinispan.distribution.ch.DefaultConsistentHash.union(DefaultConsistentHash.java:243) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.distribution.ch.DefaultConsistentHashFactory.union(DefaultConsistentHashFactory.java:120) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.distribution.ch.DefaultConsistentHashFactory.union(DefaultConsistentHashFactory.java:45) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.topology.LocalTopologyManagerImpl.handleRebalance(LocalTopologyManagerImpl.java:228) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.topology.CacheTopologyControlCommand.doPerform(CacheTopologyControlCommand.java:168) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.topology.CacheTopologyControlCommand.perform(CacheTopologyControlCommand.java:137) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:253) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:220) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:484) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:391) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:249) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:598) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.JChannel.up(JChannel.java:707) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.RSVP.up(RSVP.java:172) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:181) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:400) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:418) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:896) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:245) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:453) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:721) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:574) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:187) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.MERGE2.up(MERGE2.java:205) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.Discovery.up(Discovery.java:359) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2616) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1263) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1825) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1798) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_37]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_37]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_37]
> {code}
--
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
11 years, 10 months
[JBoss JIRA] (ISPN-2891) Calls to replace don't update cache until after tx commits
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2891?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-2891:
-------------------------------------
Is this a REPL or DIST cache?
> Calls to replace don't update cache until after tx commits
> ----------------------------------------------------------
>
> Key: ISPN-2891
> URL: https://issues.jboss.org/browse/ISPN-2891
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 5.2.1.Final
> Reporter: Jim Crossley
> Assignee: Galder Zamarreño
> Labels: 5.2.x
> Fix For: 5.3.0.Alpha1, 5.3.0.Final
>
> Attachments: bad.log, good.log, ugly.log
>
>
> Since upgrading our AS7.2 dependency in Immutant (transitively pulling in 5.2.1.Final), one of our integration tests has begun failing intermittently on our CI server. We've yet to see the failure in local runs, only on CI, so I suspect there's something racist going on.
> The two tests (one for optimistic locking, the other for pessimistic) integrate an Infinispan cache (on which the Immutant cache is built) with HornetQ and XA transactions. A number of queue listeners respond to messages by attempting to increment a value in the cache. The failure occurs with both locking schemes, but much more often with optimistic.
> We've confirmed the failure on 5.2.2 as well.
> Attached you'll find three traces of the optimistic test: the good, the bad, and the ugly. All three correspond to this test: https://github.com/immutant/immutant/blob/31a2ef6222088ccb828898e9e3e4531...
> So you can correlate the log messages prefixed with "JC:" in the traces to the code. Note in particular the last two lines in locking.clj: a logged message containing the count, and then an assertion of the count. Note that the "bad" trace was an actual failing test, but the "ugly" trace was a successful test, even though the trace clearly shows the count logged as 2, not 3. The Infinispan TRACE output clearly shows the value as 3, hence the ugliness of this test.
> It's important to understand that the "work" function occurs within an XA transaction. This means, as I understand it, that if three messages are published to "/queue/done", the cached count should equal 3. Line #44 in locking.clj will block until it receives 3 messages, after which the cached count should be 3.
> These tests always pass locally. They only ever fail on CI, which runs *very* slowly.
--
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
11 years, 10 months
[JBoss JIRA] (ISPN-2897) NPE in DefaultConsistentHash
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2897?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2897:
--------------------------------
Fix Version/s: 5.3.0.Alpha1
5.3.0.Final
> NPE in DefaultConsistentHash
> ----------------------------
>
> Key: ISPN-2897
> URL: https://issues.jboss.org/browse/ISPN-2897
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 5.2.3.Final
> Reporter: Michal Linhard
> Assignee: Dan Berindei
> Fix For: 5.3.0.Alpha1, 5.3.0.Final
>
> Attachments: serverlogs.zip
>
>
> Happened in local testing on my laptop with 4 nodes JDG 6.1.0.CR1 (ISPN 5.2.3.Final)
> For some reason there's a rebalance with pendingCH=null and this is not handled well by DefaultConsistentHash.union:
> {code}
> 15:11:04,782 DEBUG [org.infinispan.topology.LocalTopologyManagerImpl] (OOB-5,shared=udp) Starting local rebalance for cache testCache, topology = CacheTopology{id=3, currentCH=DefaultConsistentHash{numSegments=40, numOwners=2, members=[node04/default]}, pendingCH=null}
> 15:11:04,782 WARN [org.infinispan.topology.CacheTopologyControlCommand] (OOB-5,shared=udp) ISPN000071: Caught exception when handling command CacheTopologyControlCommand{cache=testCache, type=REBALANCE_START, sender=node04/default, joinInfo=null, topologyId=3, currentCH=DefaultConsistentHash{numSegments=40, numOwners=2, members=[node04/default]}, pendingCH=null, throwable=null, viewId=4}: java.lang.NullPointerException
> at org.infinispan.distribution.ch.DefaultConsistentHash.union(DefaultConsistentHash.java:243) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.distribution.ch.DefaultConsistentHashFactory.union(DefaultConsistentHashFactory.java:120) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.distribution.ch.DefaultConsistentHashFactory.union(DefaultConsistentHashFactory.java:45) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.topology.LocalTopologyManagerImpl.handleRebalance(LocalTopologyManagerImpl.java:228) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.topology.CacheTopologyControlCommand.doPerform(CacheTopologyControlCommand.java:168) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.topology.CacheTopologyControlCommand.perform(CacheTopologyControlCommand.java:137) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:253) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:220) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:484) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:391) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:249) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:598) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.JChannel.up(JChannel.java:707) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.RSVP.up(RSVP.java:172) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:181) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:400) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:418) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:896) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:245) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:453) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:721) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:574) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:187) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.MERGE2.up(MERGE2.java:205) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.Discovery.up(Discovery.java:359) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2616) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1263) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1825) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1798) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_37]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_37]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_37]
> {code}
--
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
11 years, 10 months
[JBoss JIRA] (ISPN-2897) NPE in DefaultConsistentHash
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2897?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2897:
--------------------------------
Labels: 5.2.x (was: )
> NPE in DefaultConsistentHash
> ----------------------------
>
> Key: ISPN-2897
> URL: https://issues.jboss.org/browse/ISPN-2897
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 5.2.3.Final
> Reporter: Michal Linhard
> Assignee: Dan Berindei
> Labels: 5.2.x
> Fix For: 5.3.0.Alpha1, 5.3.0.Final
>
> Attachments: serverlogs.zip
>
>
> Happened in local testing on my laptop with 4 nodes JDG 6.1.0.CR1 (ISPN 5.2.3.Final)
> For some reason there's a rebalance with pendingCH=null and this is not handled well by DefaultConsistentHash.union:
> {code}
> 15:11:04,782 DEBUG [org.infinispan.topology.LocalTopologyManagerImpl] (OOB-5,shared=udp) Starting local rebalance for cache testCache, topology = CacheTopology{id=3, currentCH=DefaultConsistentHash{numSegments=40, numOwners=2, members=[node04/default]}, pendingCH=null}
> 15:11:04,782 WARN [org.infinispan.topology.CacheTopologyControlCommand] (OOB-5,shared=udp) ISPN000071: Caught exception when handling command CacheTopologyControlCommand{cache=testCache, type=REBALANCE_START, sender=node04/default, joinInfo=null, topologyId=3, currentCH=DefaultConsistentHash{numSegments=40, numOwners=2, members=[node04/default]}, pendingCH=null, throwable=null, viewId=4}: java.lang.NullPointerException
> at org.infinispan.distribution.ch.DefaultConsistentHash.union(DefaultConsistentHash.java:243) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.distribution.ch.DefaultConsistentHashFactory.union(DefaultConsistentHashFactory.java:120) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.distribution.ch.DefaultConsistentHashFactory.union(DefaultConsistentHashFactory.java:45) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.topology.LocalTopologyManagerImpl.handleRebalance(LocalTopologyManagerImpl.java:228) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.topology.CacheTopologyControlCommand.doPerform(CacheTopologyControlCommand.java:168) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.topology.CacheTopologyControlCommand.perform(CacheTopologyControlCommand.java:137) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:253) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:220) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:484) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:391) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:249) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:598) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.JChannel.up(JChannel.java:707) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.RSVP.up(RSVP.java:172) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:181) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:400) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:418) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:896) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:245) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:453) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:721) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:574) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:187) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.MERGE2.up(MERGE2.java:205) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.Discovery.up(Discovery.java:359) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2616) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1263) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1825) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1798) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_37]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_37]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_37]
> {code}
--
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
11 years, 10 months
[JBoss JIRA] (ISPN-2897) NPE in DefaultConsistentHash
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2897?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2897:
--------------------------------
Assignee: Dan Berindei (was: Mircea Markus)
> NPE in DefaultConsistentHash
> ----------------------------
>
> Key: ISPN-2897
> URL: https://issues.jboss.org/browse/ISPN-2897
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 5.2.3.Final
> Reporter: Michal Linhard
> Assignee: Dan Berindei
> Attachments: serverlogs.zip
>
>
> Happened in local testing on my laptop with 4 nodes JDG 6.1.0.CR1 (ISPN 5.2.3.Final)
> For some reason there's a rebalance with pendingCH=null and this is not handled well by DefaultConsistentHash.union:
> {code}
> 15:11:04,782 DEBUG [org.infinispan.topology.LocalTopologyManagerImpl] (OOB-5,shared=udp) Starting local rebalance for cache testCache, topology = CacheTopology{id=3, currentCH=DefaultConsistentHash{numSegments=40, numOwners=2, members=[node04/default]}, pendingCH=null}
> 15:11:04,782 WARN [org.infinispan.topology.CacheTopologyControlCommand] (OOB-5,shared=udp) ISPN000071: Caught exception when handling command CacheTopologyControlCommand{cache=testCache, type=REBALANCE_START, sender=node04/default, joinInfo=null, topologyId=3, currentCH=DefaultConsistentHash{numSegments=40, numOwners=2, members=[node04/default]}, pendingCH=null, throwable=null, viewId=4}: java.lang.NullPointerException
> at org.infinispan.distribution.ch.DefaultConsistentHash.union(DefaultConsistentHash.java:243) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.distribution.ch.DefaultConsistentHashFactory.union(DefaultConsistentHashFactory.java:120) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.distribution.ch.DefaultConsistentHashFactory.union(DefaultConsistentHashFactory.java:45) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.topology.LocalTopologyManagerImpl.handleRebalance(LocalTopologyManagerImpl.java:228) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.topology.CacheTopologyControlCommand.doPerform(CacheTopologyControlCommand.java:168) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.topology.CacheTopologyControlCommand.perform(CacheTopologyControlCommand.java:137) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:253) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:220) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:484) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:391) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:249) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:598) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.JChannel.up(JChannel.java:707) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.RSVP.up(RSVP.java:172) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:181) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:400) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:418) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:896) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:245) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:453) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:721) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:574) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:187) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.MERGE2.up(MERGE2.java:205) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.Discovery.up(Discovery.java:359) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2616) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1263) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1825) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1798) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_37]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_37]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_37]
> {code}
--
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
11 years, 10 months
[JBoss JIRA] (ISPN-2892) View installation loop when restarting cache on multiple nodes
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2892?page=com.atlassian.jira.plugin.... ]
Mircea Markus commented on ISPN-2892:
-------------------------------------
The workaround for this would be to start the cluster one node at a time.
Upgrading to Infinispan 5.2 should fix as the state transfer was re-written and this situation should be covered as well.
> View installation loop when restarting cache on multiple nodes
> --------------------------------------------------------------
>
> Key: ISPN-2892
> URL: https://issues.jboss.org/browse/ISPN-2892
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.1.7.Final
> Reporter: Dennis Reed
> Assignee: Mircea Markus
>
> Restarting a cache on multiple nodes at the same time can cause the following error:
> ERROR [org.infinispan.cacheviews.CacheViewsManagerImpl] (CacheViewInstaller-19,node1/web) ISPN000172: Failed to prepare view CacheView{viewId=18, members=[node2/web]} for cache default-host/test, rolling back to view CacheView{viewId=17, members=[node1/web, node2/web]}: java.util.concurrent.ExecutionException: org.infinispan.CacheException: java.lang.IllegalStateException: default-host/test: Received cache view prepare request after the local node has already shut down
> After the initial error, the following error began repeating every second for a few minutes until BaseStateTransferManagerImpl.waitForJoinToComplete() timed out and the cache failed to start:
> ERROR [org.infinispan.cacheviews.CacheViewsManagerImpl] (CacheViewInstaller-19,node1/web) ISPN000172: Failed to prepare view CacheView{viewId=21, members=[node2/web]} for cache default-host/test, rolling back to view CacheView{viewId=20, members=[]}: java.util.concurrent.ExecutionException: org.infinispan.CacheException: java.lang.IllegalStateException: Cannot prepare new view CacheView{viewId=21, members=[node2/web]} on cache default-host/test, we are currently preparing view CacheView{viewId=18, members=[node2/web]}
--
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
11 years, 10 months
[JBoss JIRA] (ISPN-2897) NPE in DefaultConsistentHash
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2897?page=com.atlassian.jira.plugin.... ]
Adrian Nistor edited comment on ISPN-2897 at 3/6/13 9:54 AM:
-------------------------------------------------------------
The log indicates node2 receives a REBALACE_START with null pendingCH. This is illegal.
was (Author: anistor):
The log inficates node2 receives a REBALACE_START with null pendingCH. This is illegal.
> NPE in DefaultConsistentHash
> ----------------------------
>
> Key: ISPN-2897
> URL: https://issues.jboss.org/browse/ISPN-2897
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 5.2.3.Final
> Reporter: Michal Linhard
> Assignee: Mircea Markus
> Attachments: serverlogs.zip
>
>
> Happened in local testing on my laptop with 4 nodes JDG 6.1.0.CR1 (ISPN 5.2.3.Final)
> For some reason there's a rebalance with pendingCH=null and this is not handled well by DefaultConsistentHash.union:
> {code}
> 15:11:04,782 DEBUG [org.infinispan.topology.LocalTopologyManagerImpl] (OOB-5,shared=udp) Starting local rebalance for cache testCache, topology = CacheTopology{id=3, currentCH=DefaultConsistentHash{numSegments=40, numOwners=2, members=[node04/default]}, pendingCH=null}
> 15:11:04,782 WARN [org.infinispan.topology.CacheTopologyControlCommand] (OOB-5,shared=udp) ISPN000071: Caught exception when handling command CacheTopologyControlCommand{cache=testCache, type=REBALANCE_START, sender=node04/default, joinInfo=null, topologyId=3, currentCH=DefaultConsistentHash{numSegments=40, numOwners=2, members=[node04/default]}, pendingCH=null, throwable=null, viewId=4}: java.lang.NullPointerException
> at org.infinispan.distribution.ch.DefaultConsistentHash.union(DefaultConsistentHash.java:243) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.distribution.ch.DefaultConsistentHashFactory.union(DefaultConsistentHashFactory.java:120) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.distribution.ch.DefaultConsistentHashFactory.union(DefaultConsistentHashFactory.java:45) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.topology.LocalTopologyManagerImpl.handleRebalance(LocalTopologyManagerImpl.java:228) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.topology.CacheTopologyControlCommand.doPerform(CacheTopologyControlCommand.java:168) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.topology.CacheTopologyControlCommand.perform(CacheTopologyControlCommand.java:137) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:253) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:220) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:484) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:391) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:249) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:598) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.JChannel.up(JChannel.java:707) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.RSVP.up(RSVP.java:172) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:181) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:400) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:418) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:896) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:245) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:453) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:721) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:574) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:187) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.MERGE2.up(MERGE2.java:205) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.Discovery.up(Discovery.java:359) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2616) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1263) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1825) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1798) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_37]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_37]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_37]
> {code}
--
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
11 years, 10 months
[JBoss JIRA] (ISPN-2897) NPE in DefaultConsistentHash
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2897?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-2897:
-------------------------------------
The log inficates node2 receives a REBALACE_START with null pendingCH. This is illegal.
> NPE in DefaultConsistentHash
> ----------------------------
>
> Key: ISPN-2897
> URL: https://issues.jboss.org/browse/ISPN-2897
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 5.2.3.Final
> Reporter: Michal Linhard
> Assignee: Mircea Markus
> Attachments: serverlogs.zip
>
>
> Happened in local testing on my laptop with 4 nodes JDG 6.1.0.CR1 (ISPN 5.2.3.Final)
> For some reason there's a rebalance with pendingCH=null and this is not handled well by DefaultConsistentHash.union:
> {code}
> 15:11:04,782 DEBUG [org.infinispan.topology.LocalTopologyManagerImpl] (OOB-5,shared=udp) Starting local rebalance for cache testCache, topology = CacheTopology{id=3, currentCH=DefaultConsistentHash{numSegments=40, numOwners=2, members=[node04/default]}, pendingCH=null}
> 15:11:04,782 WARN [org.infinispan.topology.CacheTopologyControlCommand] (OOB-5,shared=udp) ISPN000071: Caught exception when handling command CacheTopologyControlCommand{cache=testCache, type=REBALANCE_START, sender=node04/default, joinInfo=null, topologyId=3, currentCH=DefaultConsistentHash{numSegments=40, numOwners=2, members=[node04/default]}, pendingCH=null, throwable=null, viewId=4}: java.lang.NullPointerException
> at org.infinispan.distribution.ch.DefaultConsistentHash.union(DefaultConsistentHash.java:243) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.distribution.ch.DefaultConsistentHashFactory.union(DefaultConsistentHashFactory.java:120) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.distribution.ch.DefaultConsistentHashFactory.union(DefaultConsistentHashFactory.java:45) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.topology.LocalTopologyManagerImpl.handleRebalance(LocalTopologyManagerImpl.java:228) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.topology.CacheTopologyControlCommand.doPerform(CacheTopologyControlCommand.java:168) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.topology.CacheTopologyControlCommand.perform(CacheTopologyControlCommand.java:137) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:253) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:220) [infinispan-core-5.2.3.Final-redhat-1.jar:5.2.3.Final-redhat-1]
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:484) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:391) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:249) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:598) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.JChannel.up(JChannel.java:707) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.RSVP.up(RSVP.java:172) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:181) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:400) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:418) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:896) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:245) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:453) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:721) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:574) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:187) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.MERGE2.up(MERGE2.java:205) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.Discovery.up(Discovery.java:359) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2616) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1263) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1825) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1798) [jgroups-3.2.7.Final-redhat-1.jar:3.2.7.Final-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_37]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_37]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_37]
> {code}
--
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
11 years, 10 months