February 2010 - infinispan-issues

[JBoss JIRA] Created: (ISPN-89) Document all configuration options available in XML and the Configuration beans on the wiki

by Manik Surtani (JIRA)

Document all configuration options available in XML and the Configuration beans on the wiki ------------------------------------------------------------------------------------------- Key: ISPN-89 URL: https://jira.jboss.org/jira/browse/ISPN-89 Project: Infinispan Issue Type: Task Components: Configuration Reporter: Manik Surtani Assignee: Galder Zamarreño Fix For: 4.0.0.GA This used to be in the User Guide of JBC, and now since we don't have a User Guide and everything is maintained on the wiki, we need a table on the wiki. Perhaps something that looks like this: http://www.jboss.org/file-access/default/members/jbosscache/freezone/docs... Should explain each XML element, attribute, allowed values, default values, and equivalent setter in the Configuration bean. -- 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

14 years, 1 month

3
15
0 / 0

[JBoss JIRA] Created: (ISPN-97) Improve configuration processing and maintenance

by Vladimir Blagojevic (JIRA)

Improve configuration processing and maintenance ------------------------------------------------ Key: ISPN-97 URL: https://jira.jboss.org/jira/browse/ISPN-97 Project: Infinispan Issue Type: Task Affects Versions: 4.0.0.ALPHA4 Reporter: Vladimir Blagojevic Assignee: Vladimir Blagojevic Fix For: 4.0.0.BETA1 In order to improve configuration processing and maintenance we have to use Java annotations. We could keep all current configuration beans, that is all subclasses of AbstractConfigurationBean but introduce annotation(s) for those beans that would: - annotate each bean setter with a reference to the XML element in question (full path to it - e.g., infinispan/namedCache/cluster/sync) - provide default configuration value - describe human readable documentation for each configuration option in plain english - references to classes to process certain complex elements and others as the need arise. Furthermore we could also: - remove current hand maintained schema - create schema by automated tools given metadata in annotations - create all human readable documentation from these annotations for manuals. wiki etc etc - read all configuration elements from xml configuration files using metadata in annotations thus avoiding "by hand" reading we have now -- 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

14 years, 1 month

2
6
0 / 0

[JBoss JIRA] Created: (ISPN-304) REST API should not use POST

by Jozef Hartinger (JIRA)

REST API should not use POST ---------------------------- Key: ISPN-304 URL: https://jira.jboss.org/jira/browse/ISPN-304 Project: Infinispan Issue Type: Bug Components: Cache Server Affects Versions: 4.0.0.CR2 Reporter: Jozef Hartinger Assignee: Manik Surtani Priority: Optional Fix For: 4.0.0.CR3 Currently, the REST API provided by Infinispan uses POST for creating new resources, for example: POST to /infinispan/rest/data/foo containing "bar" will create a new key-value pair (foo, bar) However, the HTTP spec says that POST should be used for creating *subordinate* resources, which is not done in this case because the resource itself is created and not a subordinate one. Moreover, the RESTful Web Services book which is kind of a bible for writting RESTful applications claims that the POST method can be used for creating resources *only if the server is in charge of choosing the URI for a new resource* (for example if a POST sent to /infinispan/rest/data would cause server to choose a key for the given value and make it available under /infinispan/rest/data/choosenKey). In contrast, if the *client is responsible for creating the URI* (which is the case of Infinispan), the client should use a PUT sent to the chosen URI (PUT /infinispan/rest/data/foo) to create the resource. That means that there is no difference between the initial creation of a resource and a subsequent update (both request are PUT requests to the same URI) - fits exactly how cache.put() works. The downside of this approach is that the client does not get 409 when he/she tries to overwrite an existing value. Nevertheless, if this behavior is really needed, it can be achieved alternatively, for example by introducing a path parameter "overwrite" which if set to "false" and the resource already exists, will cause the server to return 409. To summarize, IMHO it would be cleaner to stop using POST for creating new cache records and use PUT for this purpose instead. -- 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

14 years, 1 month

3
14
0 / 0

[JBoss JIRA] Created: (ISPN-262) Geographically distributed data grid

by Manik Surtani (JIRA)

Geographically distributed data grid ------------------------------------ Key: ISPN-262 URL: https://jira.jboss.org/jira/browse/ISPN-262 Project: Infinispan Issue Type: Feature Request Components: Distributed Cache, RPC, State transfer Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.0.0.BETA1, 5.0.0.GA WAN replication, either Live-Live or Live-Standby. Some interesting thoughts can be gleaned from JBCACHE-816 -- 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

14 years, 1 month

2
2
0 / 0

[JBoss JIRA] Created: (ISPN-311) CacheLoader.loadKeys(), and performance improvements when rehashing from a cache store

by Manik Surtani (JIRA)

CacheLoader.loadKeys(), and performance improvements when rehashing from a cache store -------------------------------------------------------------------------------------- Key: ISPN-311 URL: https://jira.jboss.org/jira/browse/ISPN-311 Project: Infinispan Issue Type: Feature Request Components: Distributed Cache, Loaders and Stores Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 4.1.0.BETA1, 4.1.0.GA Rehashing can be improved a bit, specifically with the addition of something like CacheLoader.loadKeys(Set<Object> excludes). This will allow the rehash code to load just the necessary keys, excluding keys already considered from the data container directly, and then inspect each key to test if the key needs to be rehashed elsewhere. If so, the value could be loaded using load(), considering that as cluster sizes increase, rehashing would only affect a smaller percentage of overall data. -- 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

14 years, 1 month

1
1
0 / 0

[JBoss JIRA] Created: (ISPN-310) CacheLoader preload should only load as many entries as configured by eviction max entries

by Manik Surtani (JIRA)

CacheLoader preload should only load as many entries as configured by eviction max entries ------------------------------------------------------------------------------------------ Key: ISPN-310 URL: https://jira.jboss.org/jira/browse/ISPN-310 Project: Infinispan Issue Type: Feature Request Components: Loaders and Stores Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 4.1.0.BETA1, 4.1.0.GA This will prevent loading too much into memory causing OOMs, as well as unnecessary eviction thread churn. Probably would require another CacheLoader interface method such as loadAll(int maxEntries). A default version of this method could just call loadAll() and trim the resultset to size, and more sophisticated impls could only load the necessary number of entries, such as a LIMIT SQL query for the JDBC cache stores. -- 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

14 years, 1 month

1
3
0 / 0

[JBoss JIRA] Created: (ISPN-322) BucketBasedCacheStore - insertBucket and updateBucket should be combined

by Manik Surtani (JIRA)

BucketBasedCacheStore - insertBucket and updateBucket should be combined ------------------------------------------------------------------------ Key: ISPN-322 URL: https://jira.jboss.org/jira/browse/ISPN-322 Project: Infinispan Issue Type: Task Components: Loaders and Stores Affects Versions: 4.0.0.GA Reporter: Manik Surtani Assignee: Mircea Markus Fix For: 4.1.0.BETA1, 4.1.0.GA insertBucket and updateBucket in BucketBasedCacheStore should be combined into 1 method (storeBucket?). Javadocs should be updated accordingly, to reflect that the bucket is persisted, and if it doesn't already exist, it will be created anew. 2 impls of this (FileCacheStore and CloudCacheStore) already delegate updateBucket() --> insertBucket(). The only impl that treats these 2 calls differently is the JdbcBinaryCacheStore. But this is incorrect since JdbcBinaryCacheStore.insertBucket() throws an exception if the row already exists. And this can happen if, for example, the cache store is in async mode. Or if it is shared. So the JdbcBinaryCacheStore would first have to be fixed, to use SQL such as "INSERT... OR UPDATE", e.g.: http://dev.mysql.com/doc/refman/5.0/en/insert-on-duplicate.html -- 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

14 years, 1 month

1
2
0 / 0

[JBoss JIRA] Created: (ISPN-353) Add a single shell script to handle cache server startup

by Manik Surtani (JIRA)

Add a single shell script to handle cache server startup -------------------------------------------------------- Key: ISPN-353 URL: https://jira.jboss.org/jira/browse/ISPN-353 Project: Infinispan Issue Type: Feature Request Components: Cache Server Reporter: Manik Surtani Assignee: Galder Zamarreno Fix For: 4.1.0.ALPHA1, 4.1.0.Final Rather than having separate startup scripts for memcached and hotrod, a single script should be used, which would take in a "protocol" parameter to determine which server module to start. >From my email to infinispan-dev: "I notice you have a memcached.sh script to start the memcached server. I believe this should be something like startServer.sh, given that we are not actually starting memcached? ;) And perhaps the script could be reused for HotRod as well ... passing in a flag to specify which protocol to speak, perhaps something like: $ startServer.sh -p memcached or $ startServer.sh -p hotrod Perhaps org.infinispan.server.memcached.Main could be in the server/core module instead, and based on the protocol flag passed in, kick start the appropriate server? WDYT?" -- 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

14 years, 1 month

2
4
0 / 0

[JBoss JIRA] Created: (ISPN-358) Rename Infinispan-server-REST distribution archive to Infinispan-servers and include hotrod and memcached servers

by Manik Surtani (JIRA)

Rename Infinispan-server-REST distribution archive to Infinispan-servers and include hotrod and memcached servers ----------------------------------------------------------------------------------------------------------------- Key: ISPN-358 URL: https://jira.jboss.org/jira/browse/ISPN-358 Project: Infinispan Issue Type: Feature Request Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 4.1.0.ALPHA1, 4.1.0.Final Would need to be organised as: /memcached /hotrod /rest README-servers.txt <-- with details on what's in the 3 directories and how to start/deploy them -- 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

14 years, 1 month

1
1
0 / 0

[JBoss JIRA] Created: (ISPN-333) Cache Loader Class Instantiated Twice

by Amin Abbaspour (JIRA)

Cache Loader Class Instantiated Twice ------------------------------------- Key: ISPN-333 URL: https://jira.jboss.org/jira/browse/ISPN-333 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 4.0.0.GA Reporter: Amin Abbaspour Assignee: Manik Surtani Priority: Minor Cache Loader Class Instantiated Twice. Place a static counter in the constructor and see this happen. -- 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

14 years, 1 month

2
7
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues February 2010