[JBoss JIRA] (ISPN-3129) If the status recovery fails for a cache, it stops recovery for all the caches
by Dan Berindei (JIRA)
Dan Berindei created ISPN-3129:
----------------------------------
Summary: If the status recovery fails for a cache, it stops recovery for all the caches
Key: ISPN-3129
URL: https://issues.jboss.org/browse/ISPN-3129
Project: Infinispan
Issue Type: Bug
Components: State transfer
Affects Versions: 5.2.6.Final
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 5.3.0.Final
When a node becomes coordinator, it sends a GET_STATUS command to recover the status of all the caches in the cluster. Then it sends a CH_UPDATE command for each cache, to install a new topology.
However, if the CH_UPDATE command fails for one cache, the coordinator will interrupt the recovery process, and it won't even install the cache topology for the rest of the caches locally. When a new node joins, it will act as if the cache was just started:
{code}
09:05:22,542 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (OOB-1693,shared=udp) Attempting to execute non-CacheRpcCommand command: CacheTopologyControlCommand{cache=default-host/clusterbench-granular, type=CH_UPDATE, sender=perf03/web, joinInfo=null, topologyId=21, currentCH=DefaultConsistentHash{numSegments=80, numOwners=2, members=[perf04/web, perf01/web, perf02/web]}, pendingCH=null, throwable=null, viewId=7} [sender=perf03/web]
09:06:21,484 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (OOB-2231,shared=udp) Attempting to execute non-CacheRpcCommand command: CacheTopologyControlCommand{cache=null, type=GET_STATUS, sender=perf04/web, joinInfo=null, topologyId=0, currentCH=null, pendingCH=null, throwable=null, viewId=7} [sender=perf04/web]
09:28:21,060 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (OOB-22206,shared=udp) Attempting to execute non-CacheRpcCommand command: CacheTopologyControlCommand{cache=default-host/clusterbench-granular, type=CH_UPDATE, sender=perf04/web, joinInfo=null, topologyId=1, currentCH=DefaultConsistentHash{numSegments=80, numOwners=2, members=[perf04/web, perf02/web, perf03/web]}, pendingCH=null, throwable=null, viewId=10} [sender=perf04/web]
{code}
This is mitigated by the ISPN-2966 fix (https://github.com/infinispan/infinispan/pull/1742). Since the CH_UPDATE command is now sent asynchronously, it ignores any exceptions on the targets. But on the 5.2.x branch, the CH_UPDATE command is sent synchronously, and it can fail with an exception like this:
{code}
05:43:56,513 WARN [org.infinispan.topology.CacheTopologyControlCommand] (notification-thread-0) ISPN000071: Caught exception when handling command CacheTopologyControlCommand{cache=default-host/clusterbench, type=CH_UPDATE, sender=perf21/web, joinInfo=null, topologyId=23, currentCH=DefaultConsistentHash{numSegments=80, numOwners=2, members=[perf21/web, perf18/web, perf19/web]}, pendingCH=null, throwable=null, viewId=8}: java.lang.IllegalArgumentException: The task is already cancelled.
at org.infinispan.statetransfer.InboundTransferTask.cancelSegments(InboundTransferTask.java:167)
at org.infinispan.statetransfer.StateConsumerImpl.cancelTransfers(StateConsumerImpl.java:774)
at org.infinispan.statetransfer.StateConsumerImpl.onTopologyUpdate(StateConsumerImpl.java:314)
at org.infinispan.statetransfer.StateTransferManagerImpl.doTopologyUpdate(StateTransferManagerImpl.java:195)
at org.infinispan.statetransfer.StateTransferManagerImpl.access$000(StateTransferManagerImpl.java:61)
at org.infinispan.statetransfer.StateTransferManagerImpl$1.updateConsistentHash(StateTransferManagerImpl.java:121)
at org.infinispan.topology.LocalTopologyManagerImpl.handleConsistentHashUpdate(LocalTopologyManagerImpl.java:202)
at org.infinispan.topology.CacheTopologyControlCommand.doPerform(CacheTopologyControlCommand.java:165)
at org.infinispan.topology.CacheTopologyControlCommand.perform(CacheTopologyControlCommand.java:137)
at org.infinispan.topology.ClusterTopologyManagerImpl.executeOnClusterSync(ClusterTopologyManagerImpl.java:540)
at org.infinispan.topology.ClusterTopologyManagerImpl.broadcastConsistentHashUpdate(ClusterTopologyManagerImpl.java:332)
at org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheStatusAfterMerge(ClusterTopologyManagerImpl.java:319)
at org.infinispan.topology.ClusterTopologyManagerImpl.handleNewView(ClusterTopologyManagerImpl.java:236)
at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener.handleViewChange(ClusterTopologyManagerImpl.java:579)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_43]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_43]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_43]
at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_43]
at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:212)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) [rt.jar:1.6.0_43]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) [rt.jar:1.6.0_43]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_43]
{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
12 years, 10 months
[JBoss JIRA] (ISPN-3127) Infinispan system requirements
by Kranti Deepak (JIRA)
[ https://issues.jboss.org/browse/ISPN-3127?page=com.atlassian.jira.plugin.... ]
Kranti Deepak commented on ISPN-3127:
-------------------------------------
$ bash --version
GNU bash, version 3.2.16(1)-release (powerpc-ibm-aix5.2.0.0)
Copyright (C) 2005 Free Software Foundation, Inc.
$ java -version
java version "1.6.0"
Java(TM) SE Runtime Environment (build pap6460sr3-20081106_07(SR3))
IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 AIX ppc64-64 jvmap6460-20081105_25433 (JIT enabled, AOT enabled)
J9VM - 20081105_025433_BHdSMr
JIT - r9_20081031_1330
GC - 20081027_AB)
JCL - 20081106_01
I tried the same on 5.2.1.Final and same error is followed.
Could you please specify the system requirements?
> Infinispan system requirements
> ------------------------------
>
> Key: ISPN-3127
> URL: https://issues.jboss.org/browse/ISPN-3127
> Project: Infinispan
> Issue Type: Feature Request
> Reporter: Kranti Deepak
> Assignee: Mircea Markus
>
> Please specify infinispan system requirements.
> I have deployed Infinispan on windows xp, windows7 and linux-redhat (all 32 bit) its working good. But unable to start on AIX 64bit version.
--
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
12 years, 10 months
[JBoss JIRA] (ISPN-3127) Infinispan system requirements
by Kranti Deepak (JIRA)
[ https://issues.jboss.org/browse/ISPN-3127?page=com.atlassian.jira.plugin.... ]
Kranti Deepak edited comment on ISPN-3127 at 5/23/13 4:11 AM:
--------------------------------------------------------------
Could u please detail what needs to be tried?
Do you mean I have to wait for another version of infinispan? I am using infinispan 5.6.1 Final.
was (Author: krantideepak4u):
Could u please detail what needs to be tried?
Do you mean I have to wait for another version of infinispan? I am using infinispan 5.6.1 Final.
(Restricted to jira-users group)
> Infinispan system requirements
> ------------------------------
>
> Key: ISPN-3127
> URL: https://issues.jboss.org/browse/ISPN-3127
> Project: Infinispan
> Issue Type: Feature Request
> Reporter: Kranti Deepak
> Assignee: Mircea Markus
>
> Please specify infinispan system requirements.
> I have deployed Infinispan on windows xp, windows7 and linux-redhat (all 32 bit) its working good. But unable to start on AIX 64bit version.
--
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
12 years, 10 months
[JBoss JIRA] (ISPN-3127) Infinispan system requirements
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-3127?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant edited comment on ISPN-3127 at 5/23/13 3:56 AM:
----------------------------------------------------------------
I guess that means 5.1.6.Final. Firstly upgrade to 5.2.1.Final.
What does bash --version tell you ? The script requires bash regex support which was introduced in Bash 3 I believe.
was (Author: NadirX):
I guess that means 5.1.6.Final. Firstly upgrade to 5.2.1.Final.
What does bash --version tell you ?
> Infinispan system requirements
> ------------------------------
>
> Key: ISPN-3127
> URL: https://issues.jboss.org/browse/ISPN-3127
> Project: Infinispan
> Issue Type: Feature Request
> Reporter: Kranti Deepak
> Assignee: Mircea Markus
>
> Please specify infinispan system requirements.
> I have deployed Infinispan on windows xp, windows7 and linux-redhat (all 32 bit) its working good. But unable to start on AIX 64bit version.
--
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
12 years, 10 months
[JBoss JIRA] (ISPN-470) Native Hot Rod client for C++
by Cliff Jansen (JIRA)
[ https://issues.jboss.org/browse/ISPN-470?page=com.atlassian.jira.plugin.s... ]
Cliff Jansen commented on ISPN-470:
-----------------------------------
Dealing more specifically with the API issues:
The patch provides a basic implementation of get() and put() as a straw man for analysis. It was pointed out to me, before the ink even started drying, that returning objects rather than pointers to objects led to bad usage patterns:
RemoteCache<Ktype, Vtype> cache = cacheManager.getCache<Ktype, Vtype>();
try {
Vtype result = cache.get(key);
// do something with result
} catch (const HotRodKeyNotFoundException& e) {
// do "key not found" processing
}
This gets a thumbs down because a non-existent key is not a rare exceptional condition and should not invoke expensive exception machinery to deal with it.
So to avoid the exception (and be closer to the Java client in this respect), we could switch to return a pointer to the object, allowing the following processing:
TbdType result_ptr = cache.get(key);
if (result_ptr)
// do something with result
else
// do "key not found" processing
Every library hates to be blamed for someone else's sloppy memory management. We could just return the raw pointer and assume the user will act responsibly and always free the object when done.
Or we could return some sort of smart pointer, but the availability and functionality of these varies from C++03 to C++11. We could define TbdType to be essentially unique_ptr or auto_ptr depending on platform. Since auto_ptr is a bit wonky and unfixable without C++11, that is less than perfect, but the downside is understood.
A variant system with extensibility points for custom classes and marshallers is also an option.
> Native Hot Rod client for C++
> -----------------------------
>
> Key: ISPN-470
> URL: https://issues.jboss.org/browse/ISPN-470
> Project: Infinispan
> Issue Type: Feature Request
> Components: Remote protocols
> Environment: Windows, 64-bit, Visual Studio 2010* RHEL 6, 64-bit, RHEL 5, 64-bit
> Reporter: Manik Surtani
> Fix For: 6.0.0.Alpha1, 6.0.0.Final
>
> Attachments: straw.patch
>
>
> C++ client impl for HotRod. Protocol is documented here:
> http://community.jboss.org/wiki/HotRodProtocol
> Could be based off the Java reference impl client:
> https://github.com/infinispan/infinispan/tree/master/client/hotrod-client
--
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
12 years, 10 months
[JBoss JIRA] (ISPN-470) Native Hot Rod client for C++
by Cliff Jansen (JIRA)
[ https://issues.jboss.org/browse/ISPN-470?page=com.atlassian.jira.plugin.s... ]
Cliff Jansen updated ISPN-470:
------------------------------
Attachment: straw.patch
Here is a patch which provides a blueprint for a C++ client implementation. It is a skeletal implementation that allows some tire kicking and opportunity for comments on direction.
The source is divided roughly as follows:
api, include : the public interface
impl: a close match (hopefully) of the Java client/hotrod/impl subdirectory
sys: platform dependent code (or 99% of it)
Another way of describing "sys" is to provide a means to write platform neutral code in the rest of the tree.
The "api" part should feel like a natural C++ use of Hot Rod, as opposed to Java shoehorned into a C++ syntax.
By contrast, the "impl" subdirectory should relax C++ ideology to allow the code logic to resemble the naming and logic flow of the Java client as closely as possible without causing brain tumors. It would be nice if this code eschewed fancier C++ techniques and perhaps even enticed the occasional Java developer to lend a hand.
For an example (that can still be improved) see how RemoteCacheImpl.cpp attempts to match the Java client's RemoteCacheImpl.java for get and put.
I have been a contributor to the Apache Qpid project for many years and should state up front that my biases are mostly shaped from there, including working on its newest Proton messaging library.
Build system:
This patch uses CMake. It builds on RHEL 6 and in Visual Studio 2008 on Windows (release mode only currently).
Testing:
TBD. Proton has used SWIG to good effect to verify that the Java and C bits are in sync. Hopefully that is possible here too.
Scripting:
i.e. scripts needed to support the build or test setup. I would suggest using one scripting language, e.g. python. Qpid used to have a combo of shell scripts (POSIX) and batch files/ powershell scripts (Windows). Proton adopted python as the sole scripting and that has been quite an improvement.
Coding guidelines:
I would propose https://cwiki.apache.org/qpid/cppstyleguide.html
Its rules are quite consistent with writing C++ code that closing matches the Java coding style of the Hot Rod client.
Finally, since a Hot Rod by nature is light and nimble, memory allocations to the heap, locking primitives should be avoided when possible.
> Native Hot Rod client for C++
> -----------------------------
>
> Key: ISPN-470
> URL: https://issues.jboss.org/browse/ISPN-470
> Project: Infinispan
> Issue Type: Feature Request
> Components: Remote protocols
> Environment: Windows, 64-bit, Visual Studio 2010* RHEL 6, 64-bit, RHEL 5, 64-bit
> Reporter: Manik Surtani
> Fix For: 6.0.0.Alpha1, 6.0.0.Final
>
> Attachments: straw.patch
>
>
> C++ client impl for HotRod. Protocol is documented here:
> http://community.jboss.org/wiki/HotRodProtocol
> Could be based off the Java reference impl client:
> https://github.com/infinispan/infinispan/tree/master/client/hotrod-client
--
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
12 years, 10 months
[JBoss JIRA] (ISPN-3128) Better support for (Spring) read caching
by Mike Noordermeer (JIRA)
[ https://issues.jboss.org/browse/ISPN-3128?page=com.atlassian.jira.plugin.... ]
Mike Noordermeer updated ISPN-3128:
-----------------------------------
Description:
We're having a bit of an issue using Infinispan as backing cache for Spring's Caching annotations. The reasons are clear, but I haven't found a proper solution yet. I thought I would describe the issues in a feature request, so we can try to make the necessary changes to fix the situation.
As already described in [the forums|https://community.jboss.org/thread/201086], an Infinispan cache in invalidation mode sends an invalidation message to other cache nodes if something is put into the cache. This conflicts with Spring's idea of {{@Cacheable}} annotations, which are ment to provide read caching for methods. Imagine the following scenario:
- Method A is annotated with {{@Cacheable}}, backed by a cache in invalidation mode
- Node X calls Method A, the method is executed and the return value is locally cached (and an invalidation message is sent to Node Y)
- Node Y calls Method A, the method is executed and the return value is locally cached, *also, the cache of Node X is invalidated*
- Node X calls Method A and has to execute the method again, since its cache is gone, etc... etc...
The reason we want to be able to invalidate the read cache, is because if the application executed an update method for the underlying data (usually marked with {{@CacheEvict}} or {{@CachePut}}) we *do* want to invalidate the other ndoes.
In Infinispan, this problem can be solved by caching using {{cache.putForExternalRead()}}. That will not invalidate other caches on a put, but will invalidate the cache when asked explicitly. However, simply changing {{put()}} to {{putForExternalRead()}} in {{SpringCache}} leads to a couple of other issues:
- This is probably not the behaviour everyone wants (people that do not use Spring annotations, but expect the usual Infinispan behaviour).
- Changing {{put()}} to {{putForExternalRead()}} would break the expected {{@CachePut}} behaviour (a new value is generated, so the old values should be invalidated), but it would fix {{@Cacheable}} behaviour.
Maybe there should be an option in the factory bean to switch between {{put()}} and {{putForExternalRead()}}? Maybe Spring should change or amend its interface so we can differentiate between calls coming from {{@CachePut}} and calls coming from {{@Cacheable}}? An other option is to make the invalidation behaviour configurable in Infinispan (that's the way Ehcache handles this issue, you can choose if puts or updates should be replicated, or just replicate invalidations).
was:
We're having a bit of an issue using Infinispan as backing cache for Spring's Caching annotations. The reasons are clear, but I haven't found a proper solution yet. I thought I would describe the issues in a feature request, so we can try to make the necessary changes to fix the situation.
As already described in [the forums|https://community.jboss.org/thread/201086], an Infinispan cache in invalidation mode sends an invalidation message to other cache nodes if something is put into the cache. This conflicts with Spring's idea of {{@Cacheable}} annotations, which are ment to provide read caching for methods. Imagine the following scenario:
- Method A is annotated with {{@Cacheable}}, backed by a cache in invalidation mode
- Node X calls Method A, the method is executed and the return value is locally cached (and an invalidation message is sent to Node Y)
- Node Y calls Method A, the method is executed and the return value is locally cached, *also, the cache of Node X is invalidated*
- Node X calls Method A and has to execute the method again, since its cache is gone, etc... etc...
The reason we want to be able to invalidate the read cache, is because if the application executed an update method for the underlying data (usually marked with {{@CacheEvict}} or {{@CachePut}}) we *do* want to invalidate the other ndoes.
In Infinispan, this problem can be solved by caching using {{cache.putForExternalRead()}}. That will not invalidate other caches on a put, but will invalidate the cache when asked explicitly. However, simply changing {{put()}} to {{putForExternalRead()}} in {{SpringCache}} leads to a couple of other issues:
- This is probably not the behaviour everyone wants (people that do not use Spring annotations, but expect the usual Infinispan behaviour).
- Changing {{put()}} to {{putForExternalRead()}} would break the expected {{@CachePut}} behaviour (a new value is generated, so the old values should be invalidated), but it would fix {{@Cacheable}} behaviour.
Maybe there should be an option in the factory bean to switch between {{put()}} and {{putForExternalRead()}}? Maybe Spring should change or amend its interface so we can differentiate between calls coming from {{@CachePut}} and calls coming from {{@Cacheable}}?
> Better support for (Spring) read caching
> ----------------------------------------
>
> Key: ISPN-3128
> URL: https://issues.jboss.org/browse/ISPN-3128
> Project: Infinispan
> Issue Type: Feature Request
> Components: Spring integration
> Affects Versions: 5.3.0.Beta2
> Environment: Spring 3.1+
> Reporter: Mike Noordermeer
> Assignee: Mircea Markus
>
> We're having a bit of an issue using Infinispan as backing cache for Spring's Caching annotations. The reasons are clear, but I haven't found a proper solution yet. I thought I would describe the issues in a feature request, so we can try to make the necessary changes to fix the situation.
> As already described in [the forums|https://community.jboss.org/thread/201086], an Infinispan cache in invalidation mode sends an invalidation message to other cache nodes if something is put into the cache. This conflicts with Spring's idea of {{@Cacheable}} annotations, which are ment to provide read caching for methods. Imagine the following scenario:
> - Method A is annotated with {{@Cacheable}}, backed by a cache in invalidation mode
> - Node X calls Method A, the method is executed and the return value is locally cached (and an invalidation message is sent to Node Y)
> - Node Y calls Method A, the method is executed and the return value is locally cached, *also, the cache of Node X is invalidated*
> - Node X calls Method A and has to execute the method again, since its cache is gone, etc... etc...
> The reason we want to be able to invalidate the read cache, is because if the application executed an update method for the underlying data (usually marked with {{@CacheEvict}} or {{@CachePut}}) we *do* want to invalidate the other ndoes.
> In Infinispan, this problem can be solved by caching using {{cache.putForExternalRead()}}. That will not invalidate other caches on a put, but will invalidate the cache when asked explicitly. However, simply changing {{put()}} to {{putForExternalRead()}} in {{SpringCache}} leads to a couple of other issues:
> - This is probably not the behaviour everyone wants (people that do not use Spring annotations, but expect the usual Infinispan behaviour).
> - Changing {{put()}} to {{putForExternalRead()}} would break the expected {{@CachePut}} behaviour (a new value is generated, so the old values should be invalidated), but it would fix {{@Cacheable}} behaviour.
> Maybe there should be an option in the factory bean to switch between {{put()}} and {{putForExternalRead()}}? Maybe Spring should change or amend its interface so we can differentiate between calls coming from {{@CachePut}} and calls coming from {{@Cacheable}}? An other option is to make the invalidation behaviour configurable in Infinispan (that's the way Ehcache handles this issue, you can choose if puts or updates should be replicated, or just replicate invalidations).
--
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
12 years, 10 months