[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-825) Consider staggering remote get requests when using DIST
by Manik Surtani (JIRA)
Consider staggering remote get requests when using DIST
-------------------------------------------------------
Key: ISPN-825
URL: https://jira.jboss.org/browse/ISPN-825
Project: Infinispan
Issue Type: Feature Request
Components: RPC
Affects Versions: 4.1.0.Final
Reporter: Manik Surtani
Assignee: Manik Surtani
Fix For: 5.0.0.BETA1, 5.0.0.Final
In DIST mode, when a request is made on a key that is not mapped locally, a remote get is sent to all data owners of that key and the first response is used. This can add unnecessary load on the network as all nodes still eventually respond, and if values are large this can cause a lot of unnecessary network traffic.
The purpose of broadcasting to all data owners is so that (1) if one is down, another could still respond (2) if one is overloaded, others may respond faster.
A solution around this could be based on either (or both) of:
* Provide a configurable stagger timeout, e.g. 100ms. E.g., RPC to (random) Owner1. Wait for timeout t. If no response, RPC to Owner2. etc.
* Always broadcast to a (configurable) subset of owners, e.g., always 2 even if numOwners is 5.
Needs careful thought and design.
--
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-317) when unsafeReturnValues is false, combine put, remove, replace, putIfAbsent, to pull back responses in 1 command
by Mircea Markus (JIRA)
when unsafeReturnValues is false, combine put, remove, replace, putIfAbsent, to pull back responses in 1 command
----------------------------------------------------------------------------------------------------------------
Key: ISPN-317
URL: https://jira.jboss.org/jira/browse/ISPN-317
Project: Infinispan
Issue Type: Feature Request
Reporter: Mircea Markus
Assignee: Manik Surtani
Fix For: 4.1.0.CR1
at the moment this is split in two operations: a remote get followed by an put. Optimize this to only reside in one operation.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] Created: (ISPN-761) Cache.keySet(), entrySet(), values(), size() ignore contents of cache loader
by Paul Ferraro (JIRA)
Cache.keySet(),entrySet(),values(),size() ignore contents of cache loader
-------------------------------------------------------------------------
Key: ISPN-761
URL: https://jira.jboss.org/browse/ISPN-761
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores
Affects Versions: 4.2.0.BETA1
Reporter: Paul Ferraro
Assignee: Manik Surtani
Passivated cache entries are not represented in values returned by the keySet(), entrySet(), values(), and size() Cache methods. This results in inconsistent behavior, since it is possible that a given cache key may not be contained in keySet() even though Cache.get(...) would return a non-null value if the entry was previously passivated.
I think CacheLoaderInterceptor needs to implement the following methods:
Object visitSizeCommand(InvocationContext ctx, SizeCommand command) throws Throwable
Object visitValuesCommand(InvocationContext ctx, ValuesCommand command) throws Throwable
Object visitEntrySetCommand(InvocationContext ctx, EntrySetCommand command) throws Throwable
Object visitKeySetCommand(InvocationContext ctx, KeySetCommand command) throws Throwable
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] Created: (ISPN-791) On node startup, ensure all peers have compatible configurations
by Manik Surtani (JIRA)
On node startup, ensure all peers have compatible configurations
----------------------------------------------------------------
Key: ISPN-791
URL: https://jira.jboss.org/browse/ISPN-791
Project: Infinispan
Issue Type: Feature Request
Components: Configuration
Affects Versions: 4.1.0.Final
Reporter: Manik Surtani
Assignee: Manik Surtani
Fix For: 5.0.0.BETA1, 5.0.0.Final
This is to prevent caches that are supposed to be symmetric/identical from being misconfigured. Some elements are allowed to be unique, of course, such as bind addresses in JGroups as well as node names, server hints, certain props passed to cache stores, etc.
A simple test could be a hash (MD5 or SHA1?) of the config XML (or a serial form of the generated Configuration bean) which is exchanged as a part of the join method. On failure of the hash check, the entire object could be checked, and if that fails as well, an appropriate ConfigurationException could be thrown.
--
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-201) make JDBC cache store use DB transactions for commit/rollback
by Mircea Markus (JIRA)
make JDBC cache store use DB transactions for commit/rollback
-------------------------------------------------------------
Key: ISPN-201
URL: https://jira.jboss.org/jira/browse/ISPN-201
Project: Infinispan
Issue Type: Feature Request
Components: Loaders and Stores
Reporter: Mircea Markus
Assignee: Manik Surtani
Fix For: 4.0.0.GA
current impl of JDBC cache store does not use DB transaction (nor local transactions/Connection.setAutocommit(false)) for storing the modifications created within a transaction. This might leave the store in an inconsistent state one operation fails during commit. This should be changed to either 1. use local transactions or 2. register the driver as an XAResource and rely on the TM to manage the boundaries. I would go for 1, as it would be more consistent with other CStore implementation (different cache store interceptor should be used for managing the 2'nd approach).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month