[JBoss JIRA] Created: (ISPN-928) Interceptor that allows invocations only when cluster is formed of N nodes
by Galder Zamarreño (JIRA)
Interceptor that allows invocations only when cluster is formed of N nodes
--------------------------------------------------------------------------
Key: ISPN-928
URL: https://issues.jboss.org/browse/ISPN-928
Project: Infinispan
Issue Type: Feature Request
Components: Configuration, RPC
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Fix For: 5.0.0.BETA1, 5.0.0.Final
Following from https://github.com/pmuir/infinispan-examples/commit/f5d090092fa7b3660025b...
It'd be great to have an configurable StrictCluster interceptor in Infinispan which would basically make all invocations wait until the cluster of N nodes has been formed. I think it'd be a great addition and would allow clients to verify whether the cluster actually forms without the need to verify whether data replicates...etc.
In principle, the configuration would be at the CacheManager, i.e.:
<transport strictNumMembers="4"... />
However, it could also be useful to configure it at the cache level. So, could maybe want to do this: I want cache X to allow invocations the moment I have 2 nodes (in spite of the cluster being formed of 4 noes), whereas I want cache Y to allow invocations once I have 3 nodes.
Apart from an strict number of nodes, you could have a minimum number of nodes: allow invocations once I have 4 or more nodes. The strict value could still be useful to make sure intrusive machines don't get into the cluster, i.e. I expect 4 nodes in the cluster and if I have 5, something is wrong.
I think it's an interesting concept that would get rid of cluster validation code in examples and RadarGun.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] Created: (ISPN-1220) Add classloader hooks to cache listener events
by Paul Ferraro (JIRA)
Add classloader hooks to cache listener events
----------------------------------------------
Key: ISPN-1220
URL: https://issues.jboss.org/browse/ISPN-1220
Project: Infinispan
Issue Type: Enhancement
Components: Listeners
Affects Versions: 5.0.0.CR7
Reporter: Paul Ferraro
Assignee: Manik Surtani
This issue seeks to extend the classloading api changes made in ISPN-1096 to the Event API. Currently, cache listener events do not allow a classloader to be specified to perform any necessary deserialization triggered by the getKey(), getValue() methods. Can the event api be enhanced such that calls to getKey(), getValue() use a specific classloader?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] Created: (ISPN-1293) Enable default lifespan/maxIdle values to be used by the Hot Rod server
by Galder Zamarreño (JIRA)
Enable default lifespan/maxIdle values to be used by the Hot Rod server
-----------------------------------------------------------------------
Key: ISPN-1293
URL: https://issues.jboss.org/browse/ISPN-1293
Project: Infinispan
Issue Type: Enhancement
Components: Cache Server
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Fix For: 5.2.0.FINAL
Hot Rod clients should be able to tell the server that no lifespan/maxIdle value was given, and so that the server should use the default lifespan+maxIdle values set in configuration. This is not currently possible in v1 of the protocol and so requires a change of protocol.
This is the result of the investigation for ISPN-1285, and so when this is resolved:
1. Make sure you revert the javadoc added to ISPN-1285 to document the limitation
2. Enable and expand client/hotrod-client/src/test/java/org/infinispan/client/hotrod/ExpiryTest.java
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] Created: (ISPN-1263) Allow a type safe selection of the cache used by the JCache interceptors
by Kevin Pollet (JIRA)
Allow a type safe selection of the cache used by the JCache interceptors
------------------------------------------------------------------------
Key: ISPN-1263
URL: https://issues.jboss.org/browse/ISPN-1263
Project: Infinispan
Issue Type: Feature Request
Components: CDI integration
Reporter: Kevin Pollet
Assignee: Kevin Pollet
Priority: Minor
Currently the name of the cache which will be used by the JCache interceptors has to be specified in JCache annotations (e.g {{@CacheResult(cacheName="greeting-cache"}}).
This can be error prone (typo, refactoring ...). The CDI integration module provides the possibility to associate a qualifier to a cache. This qualifier could be re-used to provide a type safe selection of the cache used by a JCache interceptor. Something like:
{code}
public class GreetingService {
@CacheResult @GreetingCache
public String greet(String name) {
return "Hello" + name;
}
}
{code}
Here we need to be in sync with JCache specification. In my understanding of the spec the cache name is required for {{@CacheRemoveEntry}} and {{@CacheRemoveAll}} (but currently in the API there is a default value). For {{@CacheResult}} if no cache name is defined a default one is used.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months