May 2011 - infinispan-issues - Jboss List Archives

[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

1
4
0 / 0

[JBoss JIRA] Created: (ISPN-517) CacheStore impl based on LibIO, as per HornetQ's disk spooling

by Manik Surtani (JIRA)

CacheStore impl based on LibIO, as per HornetQ's disk spooling -------------------------------------------------------------- Key: ISPN-517 URL: https://jira.jboss.org/browse/ISPN-517 Project: Infinispan Issue Type: Feature Request Components: Loaders and Stores Reporter: Manik Surtani Fix For: 5.1.0.BETA1, 5.1.0.Final HornetQ uses Linux LibIO API to create a very fast and efficient disk spooling mechanism. Should look into the possibility of creating a CacheStore around this. -- 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

5
11
0 / 0

[JBoss JIRA] Created: (ISPN-143) Security needs to be considered

by Manik Surtani (JIRA)

Security needs to be considered ------------------------------- Key: ISPN-143 URL: https://jira.jboss.org/jira/browse/ISPN-143 Project: Infinispan Issue Type: Feature Request Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 4.1.0.CR1, 4.1.0.GA We need to consider security for Infinispan. Storing state on the cloud only makes sense if the data can be secured. Both encryption and authentication need to be considered, and all levels (wire protocol, cache store, public API, server module, etc) need to be taken in to consideration. -- 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

3
6
0 / 0

[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

4
10
0 / 0

[JBoss JIRA] Created: (ISPN-647) Remote InboundInvocationHandler should differentiate between various cache inavailabilities

by Manik Surtani (JIRA)

Remote InboundInvocationHandler should differentiate between various cache inavailabilities ------------------------------------------------------------------------------------------- Key: ISPN-647 URL: https://jira.jboss.org/browse/ISPN-647 Project: Infinispan Issue Type: Feature Request Components: RPC Affects Versions: 4.2.0.ALPHA1, 4.1.0.Final Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 4.2.0.BETA1, 4.2.0.CR1 Currently a RequestIgnoredResponse is returned to any caller if either of these happen: * The cache is not yet started, is in the process of starting, and times out. * The cache doesn't exist. * The cache has been stopped. The latter two should use a different response type - CacheUnavailableResponse ? - that would not trigger a retry or any abort of transactions. -- 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

5
11
0 / 0

[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

7
25
0 / 0

[JBoss JIRA] Created: (ISPN-959) Refactor documentation on wiki

by Manik Surtani (JIRA)

Refactor documentation on wiki ------------------------------ Key: ISPN-959 URL: https://issues.jboss.org/browse/ISPN-959 Project: Infinispan Issue Type: Task Affects Versions: 5.0.0.Final Reporter: Manik Surtani Assignee: Manik Surtani This would take into account the new Confluence setup on docs.jboss.org, as well as docbook exporters and the ability to organise documentation as well as wiki pages based on versions of Infinispan. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

2
2
0 / 0

[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

3
14
0 / 0

[JBoss JIRA] Created: (ISPN-470) HotRod client in C++

by Manik Surtani (JIRA)

HotRod client in C++ -------------------- Key: ISPN-470 URL: https://jira.jboss.org/browse/ISPN-470 Project: Infinispan Issue Type: Feature Request Components: Cache Server Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.0.0.BETA1, 5.0.0.Final .NET client impl for HotRod. Protocol is documented here: http://community.jboss.org/wiki/HotRodProtocol Could be based off the Java reference impl client: http://fisheye.jboss.org/browse/Infinispan/trunk/client/hotrod-client -- 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

2
4
0 / 0

[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

5
10
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2011