[JBoss JIRA] (ISPN-2609) Infinispan SpringCache throws java.lang.NullPointerException: Null values are not supported!
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2609?page=com.atlassian.jira.plugin.... ]
Mircea Markus reopened ISPN-2609:
---------------------------------
> Infinispan SpringCache throws java.lang.NullPointerException: Null values are not supported!
> --------------------------------------------------------------------------------------------
>
> Key: ISPN-2609
> URL: https://issues.jboss.org/browse/ISPN-2609
> Project: Infinispan
> Issue Type: Bug
> Components: Spring integration
> Affects Versions: 5.1.6.FINAL
> Reporter: Roland Csupor
> Assignee: Mircea Markus
>
> I trying to use Infinispan as Spring cache, but if my function returns null, I got an exception, cause Spring tries to cache this result value:
> {noformat}
> Caused by: java.lang.NullPointerException: Null values are not supported!
> at org.infinispan.CacheImpl.assertKeyValueNotNull(CacheImpl.java:203) ~[infinispan-core-5.1.6.FINAL.jar:5.1.6.FINAL]
> at org.infinispan.CacheImpl.put(CacheImpl.java:699) ~[infinispan-core-5.1.6.FINAL.jar:5.1.6.FINAL]
> at org.infinispan.CacheImpl.put(CacheImpl.java:694) ~[infinispan-core-5.1.6.FINAL.jar:5.1.6.FINAL]
> at org.infinispan.CacheSupport.put(CacheSupport.java:53) ~[infinispan-core-5.1.6.FINAL.jar:5.1.6.FINAL]
> at org.infinispan.spring.provider.SpringCache.put(SpringCache.java:83) ~[infinispan-spring-5.1.6.FINAL.jar:5.1.6.FINAL]
> at org.springframework.cache.interceptor.CacheAspectSupport.update(CacheAspectSupport.java:390) ~[spring-context-3.1.2.RELEASE.jar:3.1.2.RELEASE]
> at org.springframework.cache.interceptor.CacheAspectSupport.execute(CacheAspectSupport.java:218) ~[spring-context-3.1.2.RELEASE.jar:3.1.2.RELEASE]
> at org.springframework.cache.interceptor.CacheInterceptor.invoke(CacheInterceptor.java:66) ~[spring-context-3.1.2.RELEASE.jar:3.1.2.RELEASE]
> {noformat}
> Did I misconfigured something?
--
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, 3 months
[JBoss JIRA] (ISPN-2609) Infinispan SpringCache throws java.lang.NullPointerException: Null values are not supported!
by Roland Csupor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2609?page=com.atlassian.jira.plugin.... ]
Roland Csupor commented on ISPN-2609:
-------------------------------------
No, it doesn't mean this. I have a method with a org.springframework.cache.annotation.Cacheable annotation, which sometimes returns null. In this case I got a NullPointerException. I used ehcache before, and Null return value is supported by this. I switched to infinispan some weaks ago, and I got exceptions.
I attach my solution below:
I created a cache implementation which handles null values and forwards the wrapped null and the values to the original, infinispan cache implementation:
{noformat}
import java.io.Serializable;
import org.springframework.cache.Cache;
import org.springframework.cache.support.SimpleValueWrapper;
public class NullValueSupportCache implements Cache {
private static final Object NULL_VALUE_HOLDER = new NullHolder();
private final Cache nativeCache;
public NullValueSupportCache(final Cache nativeCache) {
this.nativeCache = nativeCache;
}
private static class NullHolder implements Serializable {
private static final long serialVersionUID = 7697658481336079443L;
}
@Override
public String getName() {
return this.nativeCache.getName();
}
@Override
public Object getNativeCache() {
return this.nativeCache.getNativeCache();
}
@Override
public ValueWrapper get(final Object key) {
final ValueWrapper valueWrapper = this.nativeCache.get(key);
if (valueWrapper == null) {
return null;
}
final Object value = valueWrapper.get();
if (value instanceof NullHolder) {
return new SimpleValueWrapper(null);
} else {
return valueWrapper;
}
}
@Override
public void put(final Object key, final Object value) {
if (value == null) {
this.nativeCache.put(key, NULL_VALUE_HOLDER);
} else {
this.nativeCache.put(key, value);
}
}
@Override
public void evict(final Object key) {
this.nativeCache.evict(key);
}
@Override
public void clear() {
this.nativeCache.clear();
}
}
{noformat}
And I have a CacheManager to use this implementation:
{noformat}
import java.util.Collection;
import java.util.Collections;
import java.util.HashSet;
import org.springframework.cache.Cache;
import org.springframework.cache.CacheManager;
public class NullValueSupportSpringCacheManager implements CacheManager {
private final CacheManager nativeCacheManager;
private final Collection<String> cacheNames = new HashSet<String>();
public NullValueSupportSpringCacheManager(final CacheManager nativeCacheManager) {
this.nativeCacheManager = nativeCacheManager;
}
@Override
public Cache getCache(final String name) {
this.cacheNames.add(name);
return new NullValueSupportCache(this.nativeCacheManager.getCache(name));
}
@Override
public Collection<String> getCacheNames() {
return Collections.unmodifiableCollection(this.cacheNames);
}
}
{noformat}
> Infinispan SpringCache throws java.lang.NullPointerException: Null values are not supported!
> --------------------------------------------------------------------------------------------
>
> Key: ISPN-2609
> URL: https://issues.jboss.org/browse/ISPN-2609
> Project: Infinispan
> Issue Type: Bug
> Components: Spring integration
> Affects Versions: 5.1.6.FINAL
> Reporter: Roland Csupor
> Assignee: Mircea Markus
>
> I trying to use Infinispan as Spring cache, but if my function returns null, I got an exception, cause Spring tries to cache this result value:
> {noformat}
> Caused by: java.lang.NullPointerException: Null values are not supported!
> at org.infinispan.CacheImpl.assertKeyValueNotNull(CacheImpl.java:203) ~[infinispan-core-5.1.6.FINAL.jar:5.1.6.FINAL]
> at org.infinispan.CacheImpl.put(CacheImpl.java:699) ~[infinispan-core-5.1.6.FINAL.jar:5.1.6.FINAL]
> at org.infinispan.CacheImpl.put(CacheImpl.java:694) ~[infinispan-core-5.1.6.FINAL.jar:5.1.6.FINAL]
> at org.infinispan.CacheSupport.put(CacheSupport.java:53) ~[infinispan-core-5.1.6.FINAL.jar:5.1.6.FINAL]
> at org.infinispan.spring.provider.SpringCache.put(SpringCache.java:83) ~[infinispan-spring-5.1.6.FINAL.jar:5.1.6.FINAL]
> at org.springframework.cache.interceptor.CacheAspectSupport.update(CacheAspectSupport.java:390) ~[spring-context-3.1.2.RELEASE.jar:3.1.2.RELEASE]
> at org.springframework.cache.interceptor.CacheAspectSupport.execute(CacheAspectSupport.java:218) ~[spring-context-3.1.2.RELEASE.jar:3.1.2.RELEASE]
> at org.springframework.cache.interceptor.CacheInterceptor.invoke(CacheInterceptor.java:66) ~[spring-context-3.1.2.RELEASE.jar:3.1.2.RELEASE]
> {noformat}
> Did I misconfigured something?
--
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, 3 months
[JBoss JIRA] (ISPN-2612) Problem broadcasting CH_UPDATE command
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2612?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2612:
--------------------------------
Priority: Critical (was: Major)
> Problem broadcasting CH_UPDATE command
> --------------------------------------
>
> Key: ISPN-2612
> URL: https://issues.jboss.org/browse/ISPN-2612
> Project: Infinispan
> Issue Type: Bug
> Components: RPC
> Affects Versions: 5.2.0.Beta5
> Reporter: Michal Linhard
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 5.2.0.CR2
>
> Attachments: session-cluster.xml, test.zip
>
>
> Infinispan 5.2.0.Beta5
> JGroups 3.2.4.Final
> Steps to reproduce (I'm using two virtual interfaces test1, test2)
> 1. Start org.jboss.qa.jdg.Test with -Djgroups.udp.bind_addr=test1 -Djava.net.preferIPv4Stack=true
> 2. wait 10 sec
> 3. Start org.jboss.qa.jdg.Test with -Djgroups.udp.bind_addr=test2 -Djava.net.preferIPv4Stack=true
> After 5 seconds there should be this timeout exception:
> {code}
> 19:42:14,146 WARN [org.infinispan.topology.CacheTopologyControlCommand] (OOB-2,mlinhard-work-37329) ISPN000071: Caught exception when handling command CacheTopologyControlCommand{cache=___defaultcache, type=REBALANCE_CONFIRM, sender=mlinhard-work-47337, joinInfo=null, topologyId=1, currentCH=null, pendingCH=null, throwable=null, viewId=1}
> java.util.concurrent.ExecutionException: org.infinispan.CacheException: org.jgroups.TimeoutException: TimeoutException
> at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:232)
> at java.util.concurrent.FutureTask.get(FutureTask.java:91)
> at org.infinispan.topology.ClusterTopologyManagerImpl.executeOnClusterSync(ClusterTopologyManagerImpl.java:563)
> at org.infinispan.topology.ClusterTopologyManagerImpl.broadcastConsistentHashUpdate(ClusterTopologyManagerImpl.java:349)
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleRebalanceCompleted(ClusterTopologyManagerImpl.java:213)
> 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:252)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:219)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:483)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:390)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:248)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:598)
> at org.jgroups.JChannel.up(JChannel.java:703)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020)
> at org.jgroups.protocols.RSVP.up(RSVP.java:172)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:418)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:400)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:896)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
> at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:736)
> at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:414)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:606)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:187)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
> at org.jgroups.protocols.MERGE2.up(MERGE2.java:205)
> at org.jgroups.protocols.Discovery.up(Discovery.java:359)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1287)
> at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1850)
> at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1823)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: org.infinispan.CacheException: org.jgroups.TimeoutException: TimeoutException
> at org.infinispan.util.Util.rewrapAsCacheException(Util.java:532)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommands(CommandAwareRpcDispatcher.java:152)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:518)
> at org.infinispan.topology.ClusterTopologyManagerImpl$2.call(ClusterTopologyManagerImpl.java:545)
> at org.infinispan.topology.ClusterTopologyManagerImpl$2.call(ClusterTopologyManagerImpl.java:542)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> ... 3 more
> Caused by: org.jgroups.TimeoutException: TimeoutException
> at org.jgroups.util.Promise._getResultWithTimeout(Promise.java:145)
> at org.jgroups.util.Promise.getResultWithTimeout(Promise.java:40)
> at org.jgroups.util.AckCollector.waitForAllAcks(AckCollector.java:93)
> at org.jgroups.protocols.RSVP$Entry.block(RSVP.java:287)
> at org.jgroups.protocols.RSVP.down(RSVP.java:118)
> at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1025)
> at org.jgroups.JChannel.down(JChannel.java:718)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.down(MessageDispatcher.java:616)
> at org.jgroups.blocks.RequestCorrelator.sendRequest(RequestCorrelator.java:173)
> at org.jgroups.blocks.GroupRequest.sendRequest(GroupRequest.java:360)
> at org.jgroups.blocks.GroupRequest.sendRequest(GroupRequest.java:103)
> at org.jgroups.blocks.Request.execute(Request.java:83)
> at org.jgroups.blocks.MessageDispatcher.cast(MessageDispatcher.java:335)
> at org.jgroups.blocks.MessageDispatcher.castMessage(MessageDispatcher.java:249)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processCalls(CommandAwareRpcDispatcher.java:330)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommands(CommandAwareRpcDispatcher.java:145)
> ... 8 more
> {code}
> Analysis:
> These are the messages sent after view change:
> {code}
> test1 test2
> <--- JOIN ----
> ---- REBALANCE_START --->
> <--- StateRequestCommand ----
> ---- StateResponseCommand --->
> <--- REBALANCE_CONFIRM ----
> ---- CH_UPDATE --->
> {code}
> The last CH_UPDATE message is broadcast, test2 successfully processes it, but test1 stays in waiting state, because it for some reason awaits response also from itself - local variable entry in the method RSVP.down
> (https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/...)
> contained local address.
--
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, 3 months
[JBoss JIRA] (ISPN-2612) Problem broadcasting CH_UPDATE command
by Erik Salter (JIRA)
[ https://issues.jboss.org/browse/ISPN-2612?page=com.atlassian.jira.plugin.... ]
Erik Salter updated ISPN-2612:
------------------------------
Attachment: session-cluster.xml
Sample configuration
> Problem broadcasting CH_UPDATE command
> --------------------------------------
>
> Key: ISPN-2612
> URL: https://issues.jboss.org/browse/ISPN-2612
> Project: Infinispan
> Issue Type: Bug
> Components: RPC
> Affects Versions: 5.2.0.Beta5
> Reporter: Michal Linhard
> Assignee: Dan Berindei
> Fix For: 5.2.0.CR2
>
> Attachments: session-cluster.xml, test.zip
>
>
> Infinispan 5.2.0.Beta5
> JGroups 3.2.4.Final
> Steps to reproduce (I'm using two virtual interfaces test1, test2)
> 1. Start org.jboss.qa.jdg.Test with -Djgroups.udp.bind_addr=test1 -Djava.net.preferIPv4Stack=true
> 2. wait 10 sec
> 3. Start org.jboss.qa.jdg.Test with -Djgroups.udp.bind_addr=test2 -Djava.net.preferIPv4Stack=true
> After 5 seconds there should be this timeout exception:
> {code}
> 19:42:14,146 WARN [org.infinispan.topology.CacheTopologyControlCommand] (OOB-2,mlinhard-work-37329) ISPN000071: Caught exception when handling command CacheTopologyControlCommand{cache=___defaultcache, type=REBALANCE_CONFIRM, sender=mlinhard-work-47337, joinInfo=null, topologyId=1, currentCH=null, pendingCH=null, throwable=null, viewId=1}
> java.util.concurrent.ExecutionException: org.infinispan.CacheException: org.jgroups.TimeoutException: TimeoutException
> at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:232)
> at java.util.concurrent.FutureTask.get(FutureTask.java:91)
> at org.infinispan.topology.ClusterTopologyManagerImpl.executeOnClusterSync(ClusterTopologyManagerImpl.java:563)
> at org.infinispan.topology.ClusterTopologyManagerImpl.broadcastConsistentHashUpdate(ClusterTopologyManagerImpl.java:349)
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleRebalanceCompleted(ClusterTopologyManagerImpl.java:213)
> 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:252)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:219)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:483)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:390)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:248)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:598)
> at org.jgroups.JChannel.up(JChannel.java:703)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020)
> at org.jgroups.protocols.RSVP.up(RSVP.java:172)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:418)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:400)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:896)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
> at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:736)
> at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:414)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:606)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:187)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
> at org.jgroups.protocols.MERGE2.up(MERGE2.java:205)
> at org.jgroups.protocols.Discovery.up(Discovery.java:359)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1287)
> at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1850)
> at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1823)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: org.infinispan.CacheException: org.jgroups.TimeoutException: TimeoutException
> at org.infinispan.util.Util.rewrapAsCacheException(Util.java:532)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommands(CommandAwareRpcDispatcher.java:152)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:518)
> at org.infinispan.topology.ClusterTopologyManagerImpl$2.call(ClusterTopologyManagerImpl.java:545)
> at org.infinispan.topology.ClusterTopologyManagerImpl$2.call(ClusterTopologyManagerImpl.java:542)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> ... 3 more
> Caused by: org.jgroups.TimeoutException: TimeoutException
> at org.jgroups.util.Promise._getResultWithTimeout(Promise.java:145)
> at org.jgroups.util.Promise.getResultWithTimeout(Promise.java:40)
> at org.jgroups.util.AckCollector.waitForAllAcks(AckCollector.java:93)
> at org.jgroups.protocols.RSVP$Entry.block(RSVP.java:287)
> at org.jgroups.protocols.RSVP.down(RSVP.java:118)
> at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1025)
> at org.jgroups.JChannel.down(JChannel.java:718)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.down(MessageDispatcher.java:616)
> at org.jgroups.blocks.RequestCorrelator.sendRequest(RequestCorrelator.java:173)
> at org.jgroups.blocks.GroupRequest.sendRequest(GroupRequest.java:360)
> at org.jgroups.blocks.GroupRequest.sendRequest(GroupRequest.java:103)
> at org.jgroups.blocks.Request.execute(Request.java:83)
> at org.jgroups.blocks.MessageDispatcher.cast(MessageDispatcher.java:335)
> at org.jgroups.blocks.MessageDispatcher.castMessage(MessageDispatcher.java:249)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processCalls(CommandAwareRpcDispatcher.java:330)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommands(CommandAwareRpcDispatcher.java:145)
> ... 8 more
> {code}
> Analysis:
> These are the messages sent after view change:
> {code}
> test1 test2
> <--- JOIN ----
> ---- REBALANCE_START --->
> <--- StateRequestCommand ----
> ---- StateResponseCommand --->
> <--- REBALANCE_CONFIRM ----
> ---- CH_UPDATE --->
> {code}
> The last CH_UPDATE message is broadcast, test2 successfully processes it, but test1 stays in waiting state, because it for some reason awaits response also from itself - local variable entry in the method RSVP.down
> (https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/...)
> contained local address.
--
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, 3 months
[JBoss JIRA] (ISPN-2612) Problem broadcasting CH_UPDATE command
by Erik Salter (JIRA)
[ https://issues.jboss.org/browse/ISPN-2612?page=com.atlassian.jira.plugin.... ]
Erik Salter commented on ISPN-2612:
-----------------------------------
Here's a separate stack trace.
2013-02-10 06:41:35,432 ERROR [org.infinispan.topology.ClusterTopologyManagerImpl] (transport-thread-18) Failed to start rebalance on cache session: org.infinispan.CacheException: org.jgroups.TimeoutException: TimeoutException
java.util.concurrent.ExecutionException: org.infinispan.CacheException: org.jgroups.TimeoutException: TimeoutException
at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:232)
at java.util.concurrent.FutureTask.get(FutureTask.java:91)
at org.infinispan.topology.ClusterTopologyManagerImpl.executeOnClusterSync(ClusterTopologyManagerImpl.java:567)
at org.infinispan.topology.ClusterTopologyManagerImpl.broadcastRebalanceStart(ClusterTopologyManagerImpl.java:410)
at org.infinispan.topology.ClusterTopologyManagerImpl.startRebalance(ClusterTopologyManagerImpl.java:399)
at org.infinispan.topology.ClusterTopologyManagerImpl.access$000(ClusterTopologyManagerImpl.java:66)
at org.infinispan.topology.ClusterTopologyManagerImpl$1.call(ClusterTopologyManagerImpl.java:128)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: org.infinispan.CacheException: org.jgroups.TimeoutException: TimeoutException
at org.infinispan.util.Util.rewrapAsCacheException(Util.java:539)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommands(CommandAwareRpcDispatcher.java:151)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.broadcastRemoteCommands(CommandAwareRpcDispatcher.java:195)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:498)
at org.infinispan.topology.ClusterTopologyManagerImpl$2.call(ClusterTopologyManagerImpl.java:549)
at org.infinispan.topology.ClusterTopologyManagerImpl$2.call(ClusterTopologyManagerImpl.java:546)
... 5 more
Caused by: org.jgroups.TimeoutException: TimeoutException
at org.jgroups.util.Promise._getResultWithTimeout(Promise.java:145)
at org.jgroups.util.Promise.getResultWithTimeout(Promise.java:40)
at org.jgroups.util.AckCollector.waitForAllAcks(AckCollector.java:93)
at org.jgroups.protocols.RSVP$Entry.block(RSVP.java:287)
at org.jgroups.protocols.RSVP.down(RSVP.java:118)
at org.jgroups.protocols.relay.RELAY2.down(RELAY2.java:302)
at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1025)
at org.jgroups.JChannel.down(JChannel.java:718)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.down(MessageDispatcher.java:616)
at org.jgroups.blocks.RequestCorrelator.sendRequest(RequestCorrelator.java:173)
at org.jgroups.blocks.GroupRequest.sendRequest(GroupRequest.java:360)
at org.jgroups.blocks.GroupRequest.sendRequest(GroupRequest.java:103)
at org.jgroups.blocks.Request.execute(Request.java:83)
at org.jgroups.blocks.MessageDispatcher.cast(MessageDispatcher.java:335)
at org.jgroups.blocks.MessageDispatcher.castMessage(MessageDispatcher.java:249)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processCalls(CommandAwareRpcDispatcher.java:329)
Interestingly enough, this happens for all defined caches within a cache manager. These cache managers are unique in that they have a RELAY2 config AND an AsyncTransportExecutor configuration as well.
> Problem broadcasting CH_UPDATE command
> --------------------------------------
>
> Key: ISPN-2612
> URL: https://issues.jboss.org/browse/ISPN-2612
> Project: Infinispan
> Issue Type: Bug
> Components: RPC
> Affects Versions: 5.2.0.Beta5
> Reporter: Michal Linhard
> Assignee: Dan Berindei
> Fix For: 5.2.0.CR2
>
> Attachments: test.zip
>
>
> Infinispan 5.2.0.Beta5
> JGroups 3.2.4.Final
> Steps to reproduce (I'm using two virtual interfaces test1, test2)
> 1. Start org.jboss.qa.jdg.Test with -Djgroups.udp.bind_addr=test1 -Djava.net.preferIPv4Stack=true
> 2. wait 10 sec
> 3. Start org.jboss.qa.jdg.Test with -Djgroups.udp.bind_addr=test2 -Djava.net.preferIPv4Stack=true
> After 5 seconds there should be this timeout exception:
> {code}
> 19:42:14,146 WARN [org.infinispan.topology.CacheTopologyControlCommand] (OOB-2,mlinhard-work-37329) ISPN000071: Caught exception when handling command CacheTopologyControlCommand{cache=___defaultcache, type=REBALANCE_CONFIRM, sender=mlinhard-work-47337, joinInfo=null, topologyId=1, currentCH=null, pendingCH=null, throwable=null, viewId=1}
> java.util.concurrent.ExecutionException: org.infinispan.CacheException: org.jgroups.TimeoutException: TimeoutException
> at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:232)
> at java.util.concurrent.FutureTask.get(FutureTask.java:91)
> at org.infinispan.topology.ClusterTopologyManagerImpl.executeOnClusterSync(ClusterTopologyManagerImpl.java:563)
> at org.infinispan.topology.ClusterTopologyManagerImpl.broadcastConsistentHashUpdate(ClusterTopologyManagerImpl.java:349)
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleRebalanceCompleted(ClusterTopologyManagerImpl.java:213)
> 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:252)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:219)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:483)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:390)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:248)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:598)
> at org.jgroups.JChannel.up(JChannel.java:703)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020)
> at org.jgroups.protocols.RSVP.up(RSVP.java:172)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:418)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:400)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:896)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
> at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:736)
> at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:414)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:606)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:187)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
> at org.jgroups.protocols.MERGE2.up(MERGE2.java:205)
> at org.jgroups.protocols.Discovery.up(Discovery.java:359)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1287)
> at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1850)
> at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1823)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: org.infinispan.CacheException: org.jgroups.TimeoutException: TimeoutException
> at org.infinispan.util.Util.rewrapAsCacheException(Util.java:532)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommands(CommandAwareRpcDispatcher.java:152)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:518)
> at org.infinispan.topology.ClusterTopologyManagerImpl$2.call(ClusterTopologyManagerImpl.java:545)
> at org.infinispan.topology.ClusterTopologyManagerImpl$2.call(ClusterTopologyManagerImpl.java:542)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> ... 3 more
> Caused by: org.jgroups.TimeoutException: TimeoutException
> at org.jgroups.util.Promise._getResultWithTimeout(Promise.java:145)
> at org.jgroups.util.Promise.getResultWithTimeout(Promise.java:40)
> at org.jgroups.util.AckCollector.waitForAllAcks(AckCollector.java:93)
> at org.jgroups.protocols.RSVP$Entry.block(RSVP.java:287)
> at org.jgroups.protocols.RSVP.down(RSVP.java:118)
> at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1025)
> at org.jgroups.JChannel.down(JChannel.java:718)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.down(MessageDispatcher.java:616)
> at org.jgroups.blocks.RequestCorrelator.sendRequest(RequestCorrelator.java:173)
> at org.jgroups.blocks.GroupRequest.sendRequest(GroupRequest.java:360)
> at org.jgroups.blocks.GroupRequest.sendRequest(GroupRequest.java:103)
> at org.jgroups.blocks.Request.execute(Request.java:83)
> at org.jgroups.blocks.MessageDispatcher.cast(MessageDispatcher.java:335)
> at org.jgroups.blocks.MessageDispatcher.castMessage(MessageDispatcher.java:249)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processCalls(CommandAwareRpcDispatcher.java:330)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommands(CommandAwareRpcDispatcher.java:145)
> ... 8 more
> {code}
> Analysis:
> These are the messages sent after view change:
> {code}
> test1 test2
> <--- JOIN ----
> ---- REBALANCE_START --->
> <--- StateRequestCommand ----
> ---- StateResponseCommand --->
> <--- REBALANCE_CONFIRM ----
> ---- CH_UPDATE --->
> {code}
> The last CH_UPDATE message is broadcast, test2 successfully processes it, but test1 stays in waiting state, because it for some reason awaits response also from itself - local variable entry in the method RSVP.down
> (https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/...)
> contained local address.
--
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, 3 months
[JBoss JIRA] (ISPN-2598) NullPointerException in case of passing customized FetchOptions to ClusteredQuery iterator() method
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2598?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2598:
--------------------------------
Fix Version/s: 5.3.0.Final
> NullPointerException in case of passing customized FetchOptions to ClusteredQuery iterator() method
> ---------------------------------------------------------------------------------------------------
>
> Key: ISPN-2598
> URL: https://issues.jboss.org/browse/ISPN-2598
> Project: Infinispan
> Issue Type: Bug
> Components: Querying
> Reporter: Anna Manukyan
> Assignee: Sanne Grinovero
> Fix For: 5.3.0.Final
>
> Attachments: ClusteredQueryTest.java
>
>
> While running tests for query module, I've found the following thing. I'm not sure whether this is a bug, but the same flow for CacheQueryImpl works in different way rather than for ClusteredCacheQueryImpl.
> I'm running the following command on already created ClusteredQuery:
> {code}
> ResultIterator iterator = cacheQuery.iterator(new FetchOptions() {
> public FetchOptions fetchMode(FetchMode fetchMode) {
> return null;
> }
> });
> {code}
> This code throws NullPointerException, as the check of FetchMode is done in switch/case statement.
> The same code for CacheQuery throws IllegalArgumentException, as the check is done with if/else statement.
> Please find the test attached.
--
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, 3 months
[JBoss JIRA] (ISPN-2602) Busy wait in BaseStateTransferManagerImpl#waitForStateTransferToStart
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2602?page=com.atlassian.jira.plugin.... ]
Mircea Markus commented on ISPN-2602:
-------------------------------------
Lowering priority as this runs on old state transfer logic. Should only be investigated investigated if it is a re-occurring problem.
> Busy wait in BaseStateTransferManagerImpl#waitForStateTransferToStart
> ---------------------------------------------------------------------
>
> Key: ISPN-2602
> URL: https://issues.jboss.org/browse/ISPN-2602
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.1.4.FINAL
> Reporter: Dennis Reed
> Assignee: Mircea Markus
> Priority: Minor
> Fix For: 6.0.0.Final
>
>
> BaseStateTransferManagerImpl#waitForStateTransferToStart does a busy wait, sleeping for 10ms in between checking the condition, instead of synchronizing using condition variables (or the equivalent).
> This can cause excessive CPU load if a lot of threads are waiting
> (we have seen 300 threads waiting in this loop at once).
--
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, 3 months
[JBoss JIRA] (ISPN-2604) When accessing a Transient entry on one node of a cluster, make sure all copies are touched to avoid expiration
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2604?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2604:
--------------------------------
Fix Version/s: 8.0.0.Final
> When accessing a Transient entry on one node of a cluster, make sure all copies are touched to avoid expiration
> ---------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-2604
> URL: https://issues.jboss.org/browse/ISPN-2604
> Project: Infinispan
> Issue Type: Enhancement
> Components: Distributed Cache
> Reporter: Ray Tsang
> Assignee: Mircea Markus
> Fix For: 8.0.0.Final
>
>
> Following up on this topic, this is what I have setup:
> 2 nodes in cluster (either lib mode or remote) - node-1 and node-2
> a cache setup as distributed, synchronous (dist_sync)
> cache.put("key", "value", -1, TimeUnit.MILLISECONDS, 2000, TimeUnit.MILLISECONDS);
> for (i = 0; i < 10; i++) {
> sleep(1000) // sleep 1 second
> cache.get("key");
> }
> Here is the weird thing, after a few gets, I'm starting to get null results. This doesn't occur when there is only 1 node in the cluster.
> I'm suspecting that, w/ when accessing the data, it could be accessing 1 of the 2 nodes based on load balancing.
> cache.get("key") -> node-1 // 1s
> cache.get("key") -> node-1 // 2s
> cache.get("key") -> node-1 // 3s
> cache.get("key") -> node-2 // oops, this is already expired on node-2
> It would be nice to be able to make sure when accessing an entry from one node, the entry copies on other nodes are also "touched".
--
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, 3 months