September 2011 - infinispan-issues

[JBoss JIRA] Created: (ISPN-1224) Make sure a Lucene Directory can be configured in the general AS configuration independently from the Lucene version

by Sanne Grinovero (JIRA)

Make sure a Lucene Directory can be configured in the general AS configuration independently from the Lucene version -------------------------------------------------------------------------------------------------------------------- Key: ISPN-1224 URL: https://issues.jboss.org/browse/ISPN-1224 Project: Infinispan Issue Type: Enhancement Components: Lucene Directory Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Minor Fix For: 5.1.0.Final As discussed on forums: http://community.jboss.org/message/612561 and mailing list: http://infinispan.markmail.org/thread/hixrdqas4jn5cuok configuring such a cache needs Externalizers and optionally Key2String transformers which are bundled in the infinispan-lucene-directory module, but since this module depends on Lucene people would rather want to avoid having to move this jar to the commons lib path of the application server, but still want to configure the cache in the AS configuration to not have to start a second CacheManager. This issue would not apply anymore if support asymmetric clusters is implemented -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

4
4
0 / 0

[JBoss JIRA] Created: (ISPN-1252) Clearly document the fact asymmetric clusters are not supported

by Sanne Grinovero (JIRA)

Clearly document the fact asymmetric clusters are not supported --------------------------------------------------------------- Key: ISPN-1252 URL: https://issues.jboss.org/browse/ISPN-1252 Project: Infinispan Issue Type: Task Reporter: Sanne Grinovero Assignee: Manik Surtani Fix For: 5.0.0.FINAL While I find myself explaining this quite often, I couldn't find a reference in the docs to point people to. I think it should be made very clear, covered in the introduction, in the configuration and in the FAQ too. (See forum reference) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

5
7
0 / 0

[JBoss JIRA] Created: (ISPN-658) DistributionManager not considerate of cache state changes

by Paul Ferraro (JIRA)

DistributionManager not considerate of cache state changes ---------------------------------------------------------- Key: ISPN-658 URL: https://jira.jboss.org/browse/ISPN-658 Project: Infinispan Issue Type: Bug Components: Distributed Cache Affects Versions: 4.2.0.ALPHA2 Reporter: Paul Ferraro Assignee: Manik Surtani Considering a cache manager with 2 caches in DIST mode (C1 and C2) deployed on 2 nodes (N1 and N2). Currently, the DistributionManager does not properly handle the following scenarios: 1. Stop C1 on N1. This ought to trigger a rehash for the C1 cache. Currently, rehashing is only triggered via view change. Failure to rehash on stopping of a cache can inadvertently cause data loss, if all backups of a given cache entry have stopped. 2. A new DIST mode cache, C3, is started on N2. If N1 is the coordinator, the join request sent to N1 will get stuck in an infinite loop, since the cache manager on N1 does not contain a C3 cache. 3. Less critically, a new node, N3 is started. It does not yet have a C1 or C2 cache, though it's cache manager is started. This prematurely triggers a rehash of C1 and C2, even though there are no new caches instances to consider. -- 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, 6 months

11
24
0 / 0

[JBoss JIRA] Created: (ISPN-1383) Data caching multiplying memory requirements of Hot Rod server

by Galder Zamarreño (JIRA)

Data caching multiplying memory requirements of Hot Rod server -------------------------------------------------------------- Key: ISPN-1383 URL: https://issues.jboss.org/browse/ISPN-1383 Project: Infinispan Issue Type: Bug Components: Cache Server Affects Versions: 5.0.1.FINAL Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.1.0.ALPHA2 , 5.1.0.FINAL After inserting a 160MB object in Hot Rod, the memory consumption of the server goes through the roof. The screenshot shows a couple of interesting things: 1. Both the HotRodDecoder and the DataContainer have a byte[] of approx 160mb each. So, it seems like it's actually two copies of the same byte[]. It's clear though that only the cache container should have it, and any cache decoder data should be cleared when the request is completed. 2. Netty's UnsafeDynamicChannelBuffer is still holding to a byte[] of 268MB approx. Judging by the 2nd screenshot attached, this appears to be belonging to the underlying ReplayingDecoder. That should also, if possible, be cleared up. I'll have a look around in the Netty code and maybe ping Trustin. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

5
12
0 / 0

[JBoss JIRA] Created: (ISPN-1372) Make sure Infinispan works with Cassandra CQL

by Tristan Tarrant (JIRA)

Make sure Infinispan works with Cassandra CQL --------------------------------------------- Key: ISPN-1372 URL: https://issues.jboss.org/browse/ISPN-1372 Project: Infinispan Issue Type: Task Reporter: Tristan Tarrant Assignee: Tristan Tarrant -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

4
4
0 / 0

[JBoss JIRA] Created: (ISPN-1395) Remove TEST_PING workaround that avoids replying to MERGE ping when stopped

by Galder Zamarreño (JIRA)

Remove TEST_PING workaround that avoids replying to MERGE ping when stopped --------------------------------------------------------------------------- Key: ISPN-1395 URL: https://issues.jboss.org/browse/ISPN-1395 Project: Infinispan Issue Type: Enhancement Components: Test Suite Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.1.0.BETA1 Remove workaround in TEST_PING introduced in ISPN-1386 when JGroups is upgraded to 3.0. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

3
3
0 / 0

[JBoss JIRA] Created: (ISPN-1414) Introduce a builder than can create an Infinispan CacheManager

by Pete Muir (JIRA)

Introduce a builder than can create an Infinispan CacheManager -------------------------------------------------------------- Key: ISPN-1414 URL: https://issues.jboss.org/browse/ISPN-1414 Project: Infinispan Issue Type: Feature Request Reporter: Pete Muir Assignee: Manik Surtani Provide a builder class that allows passing in of SPI instances, rather than doing lookup. This allows for much easier integration, as context from the app server bootstrap can be easily passed in. For example: {code} public class CacheManagerBuilder { void setClassLoader(ClassLoader cl); void setTransport(Transport t); ... Cache start(); } {code} We would still want to offer a wrapper around this for Java SE users that would expose a create a CacheManager easily. This factory would want to use a CacheManagerBuilder internally to create the cache, but offer a simplified API. You would want to expose the Builder from the factory as well, offering a sensible set of defaults for SE. This would break backwards compatibility, as doing new EmbeddedCacheManager etc. would no longer be possible. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

2
2
0 / 0

[JBoss JIRA] Created: (ISPN-1307) REST protocol improvements for version 2

by Galder Zamarreño (JIRA)

REST protocol improvements for version 2 ---------------------------------------- Key: ISPN-1307 URL: https://issues.jboss.org/browse/ISPN-1307 Project: Infinispan Issue Type: Enhancement Components: Cache Server Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 6.0.0.FINAL This JIRA is meant to act as an umbrella for improvements we might want to do in the REST protocol. For example: - As shown in ISPN-1285 and https://docs.jboss.org/author/display/ISPN/Accessing+data+in+Infinispan+v..., the use of 0 as timeToLiveSeconds and/or maxIdleTimeSeconds parameter(s) is not very intuitive and it's not even symmetric. This should be sorted out. This JIRA should also figure out how to support multiple REST protocol versions. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

2
1
0 / 0

[JBoss JIRA] Created: (ISPN-1425) Incorrect default settings [timeToLiveSeconds, maxIdleTimeSeconds] when default in REST

by GREG AUTRIC (JIRA)

Incorrect default settings [timeToLiveSeconds,maxIdleTimeSeconds] when default in REST --------------------------------------------------------------------------------------- Key: ISPN-1425 URL: https://issues.jboss.org/browse/ISPN-1425 Project: Infinispan Issue Type: Bug Components: Cache Server Affects Versions: 5.1.0.ALPHA1 Reporter: GREG AUTRIC Assignee: Manik Surtani If HTTP client didn't use timeToLiveSeconds or/and maxIdleTimeSeconds in all PUT/POST header request Cache entry will allways use -1 for timeToLiveSeconds and -1 for maxIdleTimeSeconds instead of current Cache settings -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

7
12
0 / 0

[JBoss JIRA] Created: (ISPN-1136) Locking optimization: for dist lock only main data owner

by Mircea Markus (JIRA)

Locking optimization: for dist lock only main data owner --------------------------------------------------------- Key: ISPN-1136 URL: https://issues.jboss.org/browse/ISPN-1136 Project: Infinispan Issue Type: Feature Request Components: Transactions Affects Versions: 4.2.1.FINAL Reporter: Mircea Markus Assignee: Manik Surtani Detailed here, as the 4th improvement: http://community.jboss.org/wiki/PossibleLockingImprovements As without ISPN-1131 locks are being acquired as the transaction progresses this optimization makes more sense after having ISPN-1131 in place. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

3
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2011