February 2012 - infinispan-issues

[JBoss JIRA] Created: (ISPN-132) FIFO queu support

by Bryan Grunow (JIRA)

FIFO queu support ----------------- Key: ISPN-132 URL: https://jira.jboss.org/jira/browse/ISPN-132 Project: Infinispan Issue Type: Feature Request Components: Core API Reporter: Bryan Grunow Assignee: Manik Surtani Add support for retrieving entries from the cache via insertion (FIFO) order. For example, cache.getNext(); would return the next entry in the queue. -- 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, 9 months

2
2
0 / 0

[JBoss JIRA] (ISPN-1540) Refactor distribution interceptor

by Mircea Markus (Created) (JIRA)

Refactor distribution interceptor --------------------------------- Key: ISPN-1540 URL: https://issues.jboss.org/browse/ISPN-1540 Project: Infinispan Issue Type: Feature Request Components: Distributed Cache Reporter: Mircea Markus Assignee: Mircea Markus DistributionInterceptor, as it looks now is unnecessary complex. Before adding more functionality on top of it (i.e. ISPN-1539) it should be refactored: - extract L1 logic into a different interceptor - this would require moving the StateTransferLock logic into another interceptor as well - now that we have separation between tx and non-tx caches, we can extract the remaining logic into TransactionalDistributionInterceptor and NonTransactional... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

7
10
0 / 0

[JBoss JIRA] (ISPN-1495) Implement a GlusterFS client to be used as a CacheLoader

by Sanne Grinovero (Created) (JIRA)

Implement a GlusterFS client to be used as a CacheLoader -------------------------------------------------------- Key: ISPN-1495 URL: https://issues.jboss.org/browse/ISPN-1495 Project: Infinispan Issue Type: Feature Request Reporter: Sanne Grinovero Assignee: Manik Surtani -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

2
1
0 / 0

[JBoss JIRA] Created: (ISPN-492) Use map implementations that do array equality based on contents

by Galder Zamarreno (JIRA)

Use map implementations that do array equality based on contents ---------------------------------------------------------------- Key: ISPN-492 URL: https://jira.jboss.org/browse/ISPN-492 Project: Infinispan Issue Type: Feature Request Reporter: Galder Zamarreno Assignee: Manik Surtani Make Infinispan use backing maps that do array equality based on its contents and not on reference. This would for example allow us to have maps with byte[] as keys without the need of wrapping these arrays into something else. This would need subclassing or reimplementing maps to make comparisons based on contents. An config option could be added if someone needed standard JDK map behavior. -- 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, 9 months

2
1
0 / 0

[JBoss JIRA] (ISPN-1869) EvictionConfigurationBuilder.validate() should warn if user setd a maxEntry but forgot strategy

by Christophe Domas (JIRA)

Christophe Domas created ISPN-1869: -------------------------------------- Summary: EvictionConfigurationBuilder.validate() should warn if user setd a maxEntry but forgot strategy Key: ISPN-1869 URL: https://issues.jboss.org/browse/ISPN-1869 Project: Infinispan Issue Type: Enhancement Components: Configuration Affects Versions: 5.1.1.FINAL Reporter: Christophe Domas Assignee: Manik Surtani Maybe the NONE default strategy should be replaced by another one when invoking {{evition()}}? By the way, options should be uniformized: implicit enable on eviction when set a strategy and expilicit {{async().enable()}} on write-behind. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

4
9
0 / 0

[JBoss JIRA] (ISPN-1879) Add RSVP message flag to state transfer RPCs

by Manik Surtani (JIRA)

Manik Surtani created ISPN-1879: ----------------------------------- Summary: Add RSVP message flag to state transfer RPCs Key: ISPN-1879 URL: https://issues.jboss.org/browse/ISPN-1879 Project: Infinispan Issue Type: Enhancement Components: State transfer Affects Versions: 5.1.1.FINAL Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.1.2.CR1, 5.1.2.FINAL This is specific to JGroups 3.1.x, and allows UNICAST2 to detect the missing final packet when performing a state transfer -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

3
9
0 / 0

[JBoss JIRA] (ISPN-1837) Add support for configuration file based configuration override

by William Burns (JIRA)

William Burns created ISPN-1837: ----------------------------------- Summary: Add support for configuration file based configuration override Key: ISPN-1837 URL: https://issues.jboss.org/browse/ISPN-1837 Project: Infinispan Issue Type: Enhancement Affects Versions: 5.1.0.FINAL Reporter: William Burns Assignee: Manik Surtani I totally like the new configuration changes. However one thing that was available before was a way to allow for overrides of configuration to occur from multiple configuration files. This was available with the defineConfiguration method on the CacheManager. This is how I was able to do this in the past and it worked great. {code} for (File file : files) { InfinispanConfiguration readConfig = ...; cacheManager.getDefaultConfiguration().applyOverrides(readConfig.parseDefaultConfiguration()); for (Entry<String, Configuration> entry : readConfig.parseNamedConfigurations().entrySet()) { cacheManager.defineConfiguration(entry.getKey(), entry.getValue()); } } {code} This ability was taken away and the replacement is to use the read method on the various ConfigurationBuilders. This works great for programmatic override of various values. However there is no easy way to do overrides based on a configuration file. This is due to the fact that the only way a user can get ConfigurationBuilder objects from a configuration file is with all the default values provided. Thus you are basically replacing a configuration instead of overriding it. I wanted to propose a simple change to the Parser class so it can now also take a ConfigurationBuilderHolder so then a user can retain their own holder and pass it on to subsequent parse calls. This way only the values read from the parser will be set on the configuration builder objects. With t his small change I am then able to do the following: {code} Parser parser = new Parser(Thread.currentThread().getContextClassLoader()); for (File file : files) { parser.parse(file.getAbsolutePath(), holder); } {code} Also a side note but the way the transport is handled right now kind of throws a wrench in this. I noticed that if the global section is provied if no transport is in the xml it will null out the transport in the configuration on the override. This can be problematic if the transport is defined in a starting xml file and later a different xml file may want to say add some additional externalizers or something (which we do) and then the transport will be set to null. Right now I am working around this by overriding the transport last, but would be nice if I didn't have to do that. I could also define an empty transport element in all of the xml files to workaround it as well. The transport issue occurs because of line 1209 in the Parser class. I don't know if it can be changed without breaking something else and as such didn't include it in my pull request, but would be nice if this could also be changed. {code} if (!transportParsed) { // make sure there is no "default" transport builder.transport().transport(null); } {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

4
5
0 / 0

[JBoss JIRA] Created: (ISPN-1367) Add SPI which can be used to attach extra info to a serialized data and callback when data is deserialized

by Pete Muir (JIRA)

Add SPI which can be used to attach extra info to a serialized data and callback when data is deserialized ---------------------------------------------------------------------------------------------------------- Key: ISPN-1367 URL: https://issues.jboss.org/browse/ISPN-1367 Project: Infinispan Issue Type: Feature Request Affects Versions: 5.0.0.FINAL Reporter: Pete Muir Assignee: Manik Surtani Fix For: 5.1.0.ALPHA1 In an environment such as JBoss AS, where there is some sort of consistent identification of deployments across nodes (i.e. a deployment id) this SPI can be used to attach the deployment id to the serialized data, and then on deserialization used to locate the correct classloader to use -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

4
16
0 / 0

[JBoss JIRA] (ISPN-1466) Async configuration tag affects communication between cache and HotRod client

by Martin Gencur (Created) (JIRA)

Async configuration tag affects communication between cache and HotRod client ----------------------------------------------------------------------------- Key: ISPN-1466 URL: https://issues.jboss.org/browse/ISPN-1466 Project: Infinispan Issue Type: Bug Affects Versions: 5.1.0.ALPHA1 Reporter: Martin Gencur Assignee: Manik Surtani When using a REPL (replicated) cache with configuration tag <async useReplQueue="true" replQueueMaxElements="3" replQueueInterval="1000" />, HotRod client cannot see a cache entry which was just stored into a cache. The entry is visible not before the replication queue is flushed (either because of MaxElements limit or QueueInterval). I'll attach a testcase but here's a test snippet that fails at first assert: {code} @Test public void testQueueSize() throws Exception { RemoteCache<String, String> asyncCache1 = rcm1.getCache(asyncCacheSize); RemoteCache<String, String> asyncCache2 = rcm2.getCache(asyncCacheSize); asyncCache1.clear(); asyncCache1.put("k1", "v1"); assertTrue(null != asyncCache1.get("k1")); assertTrue(null == asyncCache2.get("k2")); asyncCache1.put("k2", "v2"); //k3 fills up the queue -> flush asyncCache1.put("k3", "v3"); Thread.sleep(1000); //wait for the queue to be flushed assertTrue(null != asyncCache1.get("k1")); assertTrue(null != asyncCache2.get("k2")); } {code} IMO when I have cache A and B in a cluster and the cache entry is stored into the cache A, it should be visible at A and not in B. After flushing the queue it should be visible also at B. Here's the test: https://svn.devel.redhat.com/repos/jboss-qa/edg/infinispan-functional-tes... (to run it, one has to install infinispan-arquillian-container into local maven repository, set ISPN_HOME pointing to Infinispan distribution and run "mvn clean verify") -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

9
36
0 / 0

[JBoss JIRA] Created: (ISPN-1318) replaceWithVersionAsync on RemoteCache (HotRod) fails to set lifespan of cache entries

by Martin Gencur (JIRA)

replaceWithVersionAsync on RemoteCache (HotRod) fails to set lifespan of cache entries -------------------------------------------------------------------------------------- Key: ISPN-1318 URL: https://issues.jboss.org/browse/ISPN-1318 Project: Infinispan Issue Type: Bug Affects Versions: 5.0.0.FINAL Reporter: Martin Gencur Assignee: Manik Surtani Cache entries remain in the cache even after their lifespan expires (when setting the lifespan via replaceWithVersionAsync and also via replaceWithVersion (sync)) The test verifying this can be found at https://svn.devel.redhat.com/repos/jboss-qa/edg/infinispan-functional-tes... - test method testReplaceWithVersionWithLifespanAsync() The test is failing on line assertEquals(null, cache.getVersioned("aKey")); To run it, one has to set ISPN_HOME property pointing to Infinispan build and run "mvn clean verify". -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

8
13
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues February 2012