[JBoss JIRA] (ISPN-2814) RpcManager doesn't return values properly
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-2814?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-2814:
--------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/1658, https://github.com/infinispan/infinispan/pull/1708 (was: https://github.com/infinispan/infinispan/pull/1658)
Added pull request that has tests for the 2 commands in question. Note how the first works properly now with the change.
> RpcManager doesn't return values properly
> -----------------------------------------
>
> Key: ISPN-2814
> URL: https://issues.jboss.org/browse/ISPN-2814
> Project: Infinispan
> Issue Type: Bug
> Components: RPC
> Affects Versions: 5.1.5.FINAL
> Reporter: William Burns
> Assignee: Adrian Nistor
> Fix For: 5.2.3.Final, 5.3.0.Final
>
>
> We currently use some custom commands with Infinispan. We have since moved over to wanting to use a custom command with a return value for the response.
> We have tried using the various methods on the RpcManager and have found a few issues.
> 1. Map<Address, Response> invokeRemotely(Collection<Address> recipients, ReplicableCommand rpc, boolean sync, boolean usePriorityQueue) throws RpcException;
> This method always returns a null for cluster responses. This is a simple issue that can be solved with the following diff
> {code}
> diff --git a/core/src/main/java/org/infinispan/commands/remote/SingleRpcCommand.
> index bf369bc..79bc02e 100644
> --- a/core/src/main/java/org/infinispan/commands/remote/SingleRpcCommand.java
> +++ b/core/src/main/java/org/infinispan/commands/remote/SingleRpcCommand.java
> @@ -107,6 +107,6 @@ public ReplicableCommand getCommand() {
>
> @Override
> public boolean isReturnValueExpected() {
> - return false;
> + return command.isReturnValueExpected();
> }
> }
> {code}
> The SingleRpcCommand wraps the given command always forcing the return value expectation to be false.
> 2. Map<Address, Response> invokeRemotely(Collection<Address> recipients, ReplicableCommand rpcCommand, ResponseMode mode, long timeout);
> This method doesn't wrap the return value in a Response thus causing a ClassCastException when the client node gets the response back. I haven't looked into detail with this one yet.
> If needed I can send a sample project that shows the behavior.
--
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 resolved ISPN-2897.
---------------------------------
Resolution: Done
integrated both 5.2.x and master.
> 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.2.4.Final, 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-2814) RpcManager doesn't return values properly
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-2814?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-2814:
--------------------------------
Fix Version/s: 5.2.3.Final
I see that this was merged into the 5.2 branch as well and is in the 5.2.3 final version.
> RpcManager doesn't return values properly
> -----------------------------------------
>
> Key: ISPN-2814
> URL: https://issues.jboss.org/browse/ISPN-2814
> Project: Infinispan
> Issue Type: Bug
> Components: RPC
> Affects Versions: 5.1.5.FINAL
> Reporter: William Burns
> Assignee: Adrian Nistor
> Fix For: 5.2.3.Final, 5.3.0.Final
>
>
> We currently use some custom commands with Infinispan. We have since moved over to wanting to use a custom command with a return value for the response.
> We have tried using the various methods on the RpcManager and have found a few issues.
> 1. Map<Address, Response> invokeRemotely(Collection<Address> recipients, ReplicableCommand rpc, boolean sync, boolean usePriorityQueue) throws RpcException;
> This method always returns a null for cluster responses. This is a simple issue that can be solved with the following diff
> {code}
> diff --git a/core/src/main/java/org/infinispan/commands/remote/SingleRpcCommand.
> index bf369bc..79bc02e 100644
> --- a/core/src/main/java/org/infinispan/commands/remote/SingleRpcCommand.java
> +++ b/core/src/main/java/org/infinispan/commands/remote/SingleRpcCommand.java
> @@ -107,6 +107,6 @@ public ReplicableCommand getCommand() {
>
> @Override
> public boolean isReturnValueExpected() {
> - return false;
> + return command.isReturnValueExpected();
> }
> }
> {code}
> The SingleRpcCommand wraps the given command always forcing the return value expectation to be false.
> 2. Map<Address, Response> invokeRemotely(Collection<Address> recipients, ReplicableCommand rpcCommand, ResponseMode mode, long timeout);
> This method doesn't wrap the return value in a Response thus causing a ClassCastException when the client node gets the response back. I haven't looked into detail with this one yet.
> If needed I can send a sample project that shows the behavior.
--
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-2903) CLONE - Eviction causes lost AtomicMap entries
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/ISPN-2903?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated ISPN-2903:
-------------------------------
Attachment: server.log
server.log
TRACE logs from test run on each server.
> CLONE - Eviction causes lost AtomicMap entries
> ----------------------------------------------
>
> Key: ISPN-2903
> URL: https://issues.jboss.org/browse/ISPN-2903
> Project: Infinispan
> Issue Type: Bug
> Components: Eviction
> Affects Versions: 5.2.3.Final
> Reporter: Paul Ferraro
> Assignee: Galder Zamarreño
> Priority: Critical
> Labels: jdg6
> Fix For: 5.2.4.Final, 5.3.0.Alpha1, 5.3.0.Final
>
> Attachments: AtomicMapServlet.java, AtomicMapTestCase.java, server.log, server.log
>
>
> Here's the scenario:
> Given 2 nodes with REPL_SYNC cache with passivating cache store (e.g. default web cache in AS7).
> 1. Create cache entry containing atomic map with 2 map entries on node1.
> 2. Passivate that cache entry on node2 via manual evict.
> 3. Modify 1 of the atomic map entries within the cache entry on node1.
> 4. Lookup atomic map on node2. It only contains 1 map entry - the map entry modified in step 3. The other map entry is lost.
--
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-2903) CLONE - Eviction causes lost AtomicMap entries
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/ISPN-2903?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on ISPN-2903:
------------------------------------
The issue can be reproduced against AS master, the 7.2 branch.
> CLONE - Eviction causes lost AtomicMap entries
> ----------------------------------------------
>
> Key: ISPN-2903
> URL: https://issues.jboss.org/browse/ISPN-2903
> Project: Infinispan
> Issue Type: Bug
> Components: Eviction
> Affects Versions: 5.2.3.Final
> Reporter: Paul Ferraro
> Assignee: Galder Zamarreño
> Priority: Critical
> Labels: jdg6
> Fix For: 5.2.4.Final, 5.3.0.Alpha1, 5.3.0.Final
>
> Attachments: AtomicMapServlet.java, AtomicMapTestCase.java
>
>
> Here's the scenario:
> Given 2 nodes with REPL_SYNC cache with passivating cache store (e.g. default web cache in AS7).
> 1. Create cache entry containing atomic map with 2 map entries on node1.
> 2. Passivate that cache entry on node2 via manual evict.
> 3. Modify 1 of the atomic map entries within the cache entry on node1.
> 4. Lookup atomic map on node2. It only contains 1 map entry - the map entry modified in step 3. The other map entry is lost.
--
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-2903) CLONE - Eviction causes lost AtomicMap entries
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/ISPN-2903?page=com.atlassian.jira.plugin.... ]
Paul Ferraro edited comment on ISPN-2903 at 3/7/13 11:58 AM:
-------------------------------------------------------------
The issue can be reproduced against AS master or the 7.2 branch.
was (Author: pferraro):
The issue can be reproduced against AS master, the 7.2 branch.
> CLONE - Eviction causes lost AtomicMap entries
> ----------------------------------------------
>
> Key: ISPN-2903
> URL: https://issues.jboss.org/browse/ISPN-2903
> Project: Infinispan
> Issue Type: Bug
> Components: Eviction
> Affects Versions: 5.2.3.Final
> Reporter: Paul Ferraro
> Assignee: Galder Zamarreño
> Priority: Critical
> Labels: jdg6
> Fix For: 5.2.4.Final, 5.3.0.Alpha1, 5.3.0.Final
>
> Attachments: AtomicMapServlet.java, AtomicMapTestCase.java
>
>
> Here's the scenario:
> Given 2 nodes with REPL_SYNC cache with passivating cache store (e.g. default web cache in AS7).
> 1. Create cache entry containing atomic map with 2 map entries on node1.
> 2. Passivate that cache entry on node2 via manual evict.
> 3. Modify 1 of the atomic map entries within the cache entry on node1.
> 4. Lookup atomic map on node2. It only contains 1 map entry - the map entry modified in step 3. The other map entry is lost.
--
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-2903) CLONE - Eviction causes lost AtomicMap entries
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-2903?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-2903:
-----------------------------------
Fix Version/s: 5.3.0.Final
> CLONE - Eviction causes lost AtomicMap entries
> ----------------------------------------------
>
> Key: ISPN-2903
> URL: https://issues.jboss.org/browse/ISPN-2903
> Project: Infinispan
> Issue Type: Bug
> Components: Eviction
> Affects Versions: 5.2.3.Final
> Reporter: Paul Ferraro
> Assignee: Galder Zamarreño
> Priority: Critical
> Labels: jdg6
> Fix For: 5.2.4.Final, 5.3.0.Alpha1, 5.3.0.Final
>
> Attachments: AtomicMapServlet.java, AtomicMapTestCase.java
>
>
> Here's the scenario:
> Given 2 nodes with REPL_SYNC cache with passivating cache store (e.g. default web cache in AS7).
> 1. Create cache entry containing atomic map with 2 map entries on node1.
> 2. Passivate that cache entry on node2 via manual evict.
> 3. Modify 1 of the atomic map entries within the cache entry on node1.
> 4. Lookup atomic map on node2. It only contains 1 map entry - the map entry modified in step 3. The other map entry is lost.
--
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