December 2011 - infinispan-issues

[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, 1 month

2
1
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, 2 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, 2 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, 2 months

8
13
0 / 0

[JBoss JIRA] (ISPN-1611) Hotrod server memory leak after enable idle timeout

by hs z (Created) (JIRA)

Hotrod server memory leak after enable idle timeout --------------------------------------------------- Key: ISPN-1611 URL: https://issues.jboss.org/browse/ISPN-1611 Project: Infinispan Issue Type: Bug Components: Cache Server Affects Versions: 5.1.0.CR1 Reporter: hs z Assignee: Manik Surtani i set --idle_timeout=15 as param, threads count and memory usage always grow, i got a heap dump and found many netty HashedWheelTimer instances cost much memory. in HashedWheelTimer javadoc, it says: "Do not create many instances. HashedWheelTimer creates a new thread whenever it is instantiated and started. Therefore, you should make sure to create only one instance and share it across your application. One of the common mistakes, that makes your application unresponsive, is to create a new instance in ChannelPipelineFactory, which results in the creation of a new thread for every connection.". but in infinispan NettyChannelPipelineFactory.scala, there is "timer = new HashedWheelTimer", it's misused. -- 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, 2 months

5
10
0 / 0

[JBoss JIRA] (ISPN-1508) Failures during hotrod server cluster formation

by Michal Linhard (Created) (JIRA)

Failures during hotrod server cluster formation ----------------------------------------------- Key: ISPN-1508 URL: https://issues.jboss.org/browse/ISPN-1508 Project: Infinispan Issue Type: Bug Affects Versions: 5.1.0.BETA3 Reporter: Michal Linhard Assignee: Manik Surtani failing build: https://hudson.qa.jboss.com/hudson/job/edg-60-client-stress-test/87 server logs: https://hudson.qa.jboss.com/hudson/job/edg-60-client-stress-test/87/artif... in this test I'm starting 4 standalone infinispan hotrod servers (startServer.sh style) and they take too long to form a cluster (more than 2 min) there errors related to CacheViewControlCommand the infinispan version is 5.1.0-SNAPSHOT (c642be2c8a64c13e7e74283f38e2037cef9a362f) + a quick patch for ISPN-1498 -- 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, 2 months

15
35
0 / 0

[JBoss JIRA] (ISPN-1621) SharedResourceMisuseDetector warning

by Michal Linhard (Created) (JIRA)

SharedResourceMisuseDetector warning ------------------------------------ Key: ISPN-1621 URL: https://issues.jboss.org/browse/ISPN-1621 Project: Infinispan Issue Type: Bug Components: Cache Server Affects Versions: 5.1.0.CR1 Reporter: Michal Linhard Assignee: Manik Surtani Priority: Minor This warning message can be seen when starting EDG {code} node1: 09:07:45,110 WARNING [org.jboss.netty.util.internal.SharedResourceMisuseDetector] (MemcachedServerMaster-2 ([id: 0x4d815146, /10.16.90.106:11222])) You are creating too many HashedWheelTimer instances. HashedWheelTimer is a shared resource that must be reused across the application, so that only a few instances are created. node2: 09:07:45,381 WARNING [org.jboss.netty.util.internal.SharedResourceMisuseDetector] (HotRodServerMaster-2 ([id: 0x35612600, /10.16.90.107:11222])) You are creating too many HashedWheelTimer instances. HashedWheelTimer is a shared resource that must be reused across the application, so that only a few instances are created. node3: 09:07:45,526 WARNING [org.jboss.netty.util.internal.SharedResourceMisuseDetector] (HotRodServerMaster-2 ([id: 0x4263f6ea, /10.16.90.108:11222])) You are creating too many HashedWheelTimer instances. HashedWheelTimer is a shared resource that must be reused across the application, so that only a few instances are created. node4: 09:07:48,125 WARNING [org.jboss.netty.util.internal.SharedResourceMisuseDetector] (HotRodServerMaster-2 ([id: 0x7d05e560, /10.16.90.109:11222])) You are creating too many HashedWheelTimer instances. HashedWheelTimer is a shared resource that must be reused across the application, so that only a few instances are created. {code} EDG build: http://hudson.qa.jboss.com/hudson/view/EDG6/view/EDG-QE/job/edg-60-build-... huson job with the issue: http://hudson.qa.jboss.com/hudson/view/EDG6/view/EDG-REPORTS-PERF/job/edg... -- 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, 2 months

7
10
0 / 0

[JBoss JIRA] Created: (ISPN-203) REST interface to Infinispan DB

by Michael Neale (JIRA)

REST interface to Infinispan DB ------------------------------- Key: ISPN-203 URL: https://jira.jboss.org/jira/browse/ISPN-203 Project: Infinispan Issue Type: Feature Request Components: Cache Server, Querying Reporter: Michael Neale Assignee: Michael Neale Fix For: 5.1.0.BETA1 As described here: http://www.jboss.org/community/wiki/InfinispanDB This will build on (or perhaps be built in) the server/rest module - as well as some additions of helper classes to core, and a query language to query module. -- 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, 3 months

4
4
0 / 0

[JBoss JIRA] Created: (ISPN-1319) topology changes makes entire cluster inconsistent

by Jan Slezak (JIRA)

topology changes makes entire cluster inconsistent -------------------------------------------------- Key: ISPN-1319 URL: https://issues.jboss.org/browse/ISPN-1319 Project: Infinispan Issue Type: Bug Components: Distributed Cache Affects Versions: 5.0.0.FINAL Environment: linux / devel environment / 1.6.0_26 Reporter: Jan Slezak Assignee: Manik Surtani Priority: Blocker Invoke timeout exception in replicated or distributed environment (the issue occurred in both) during topology change on producer node - after that the data may end up in inconsistent state on other nodes (in my case n+1 entities on some of the nodes). I tried that with many TM / ISPN configurations in sync mode using DummyTransactionManagerLookup. Same behavior using invocation batching ... example xml: <infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:infinispan:config:5.0 http://www.infinispan.org/schemas/infinispan-config-5.0.xsd" xmlns="urn:infinispan:config:5.0"> <global> <transport clusterName="ifprotocluster"/> </global> <default> <clustering mode="distribution"> <l1 enabled="false"/> <hash numOwners="100" rehashRpcTimeout="120000" /> <sync/> </clustering> <transaction transactionManagerLookupClass="org.infinispan.transaction.lookup.DummyTransactionManagerLookup" syncRollbackPhase="true" syncCommitPhase="true" useEagerLocking="true" /> </default> </infinispan> -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

3
5
0 / 0

[JBoss JIRA] (ISPN-1441) Better and more sensible executor configuration

by Galder Zamarreño (Created) (JIRA)

Better and more sensible executor configuration ----------------------------------------------- Key: ISPN-1441 URL: https://issues.jboss.org/browse/ISPN-1441 Project: Infinispan Issue Type: Enhancement Components: Configuration Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 6.0.0.FINAL Dan and I had a chat about ISPN-1396 and we both agreed that a better configuration and management approach is needed for Infinispan's executors: - Firstly, out of the box for SE environments, Infinispan should have executors configured with newCachedThreadPool because they provide better queuing performance than a fixed thread pool. - Sure, in an managed env (i.e. AS), this won't fly, which is why all executors need to be injectable. This should be in place once ISPN-1396 is in place. - So, if we go for cached thread pools for SE environments, we don't need any of the properties of executors any more. Besides, these can be more confusing for the user (there is knowledged of at least one case where things went wrong due to bad config here). So, the configuration would be limited to injecting executors. If you need any specific executor settings, pass us the right executors. To aid these cases, we could have some executor builders available with some common executor configuration for managed envs (i.e. we could borrow settings from AS?) -- 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, 3 months

3
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues December 2011