December 2010 - infinispan-issues

[JBoss JIRA] Created: (ISPN-493) Harden rehash leave process

by Vladimir Blagojevic (JIRA)

Harden rehash leave process --------------------------- Key: ISPN-493 URL: https://jira.jboss.org/browse/ISPN-493 Project: Infinispan Issue Type: Task Affects Versions: 4.1.0.BETA2, 4.0.0.Final Reporter: Vladimir Blagojevic Assignee: Vladimir Blagojevic Fix For: 5.0.0.BETA1, 5.0.0.Final We need to make sure that leave rehash process properly handles massive and rapid node failure. Massive failures: JGroups detects multiple node failures and pushes up to Infinispan views that are more "volatile" than we currently assumed (only one member at the time can leave). For example, if we have view V1={A,B,C,D,E} and massive failure causes {C,D,E} to fail, JGroups failure detection and GMS are going to install a view V2={A,B} to surviving members. LeaveTask does not handle this scenario. Rapid node failure: We need to revisit how LeaveTasks are queued up and executed/canceled during rapid node failures. Do we always cancel currently running leave tasks? At what stage are we allowed to cancel it and at what stage of a leave tasks is it better to wait for a completion of a task. -- 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, 3 months

3
6
0 / 0

[JBoss JIRA] Created: (ISPN-293) implement asynchronous get method getAsync()

by Sanne Grinovero (JIRA)

implement asynchronous get method getAsync() -------------------------------------------- Key: ISPN-293 URL: https://jira.jboss.org/jira/browse/ISPN-293 Project: Infinispan Issue Type: Feature Request Components: Core API Reporter: Sanne Grinovero Assignee: Manik Surtani Fix For: 4.0.0.CR3 Like other async methods existing it would be useful (natural) to have a method getAsync() for prefetching of data not immediately required. -- 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
15
0 / 0

[JBoss JIRA] Created: (ISPN-271) Expose global information in RpcManagerImpl via CacheManager

by Galder Zamarreno (JIRA)

Expose global information in RpcManagerImpl via CacheManager ------------------------------------------------------------ Key: ISPN-271 URL: https://jira.jboss.org/jira/browse/ISPN-271 Project: Infinispan Issue Type: Feature Request Components: JMX, reporting and management, RPC Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.1.0.BETA1 RpcManagerImpl exposes information that are both global to all caches under a cache manager and information that is specific to a cache. An idea would be to expose any global information via CacheManager mbean instead, i.e. address, cluster members And the rest, stuff that is cache specific, expose via rpc manager mbean, -- 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, 4 months

4
7
0 / 0

[JBoss JIRA] Created: (ISPN-849) testTransactional doesn't ever work

by luca stancapiano (JIRA)

testTransactional doesn't ever work ----------------------------------- Key: ISPN-849 URL: https://issues.jboss.org/browse/ISPN-849 Project: Infinispan Issue Type: Bug Environment: mac osx Reporter: luca stancapiano Assignee: Manik Surtani I'm triing testTransactional inside distribution.rehash.ConcurrentNonOverlappingLeaveTest . Often it doesn't update the c1 cache with the value "transactionally_replaced" instead of "v1". I thought about a syncronization problem of the Threads but I see that the put of the field always is executed before the get. Actually the problem seems be in org.infinispan.distribution.rehash.RehashTestBase class (95-109): TransactionManager t1 = TestingUtil.getTransactionManager(c1); t1.begin(); c1.put(keys.get(0), "transactionally_replaced"); Transaction tx = t1.getTransaction(); tx.enlistResource(new XAResourceAdapter() { public int prepare(Xid id) { // this would be called *after* the cache prepares. try { l.await(); } catch (InterruptedException e) { } return XAResource.XA_OK; } }); t1.commit(); maybe sometime there is a rollback -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

2
6
0 / 0

[JBoss JIRA] Created: (ISPN-845) Memory leaks for 2 phase commit readonly transaction

by Changgeng Li (JIRA)

Memory leaks for 2 phase commit readonly transaction ---------------------------------------------------- Key: ISPN-845 URL: https://issues.jboss.org/browse/ISPN-845 Project: Infinispan Issue Type: Bug Components: Transactions Affects Versions: 4.2.0.Final Reporter: Changgeng Li Assignee: Manik Surtani Priority: Blocker If a method that is declared with read only transactional attribute by '@Transactional(readOnly=true)', using jboss transaction manager, and inside this method two caches are visited, there will be memory leak after the method is invoked. The leak happens in TransactionTable instances, localTransactions map and xid2LocalTx map. It seems the commit phrase is skipped and the cleanup method is failed to be called to clean entries in these two maps. My test shows if the transaction just enlists one cache, there won't be any problems, but I haven't test whether using DummyTransactionManagerLookup will resolve this. This bug break our system where readOnly DAO methods are heavily used with infinispan as hibernate second level cache. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

4
16
0 / 0

[JBoss JIRA] Created: (ISPN-654) Lost cache data on insert and state transfer with async DIST cache

by Erik Salter (JIRA)

Lost cache data on insert and state transfer with async DIST cache ------------------------------------------------------------------ Key: ISPN-654 URL: https://jira.jboss.org/browse/ISPN-654 Project: Infinispan Issue Type: Bug Affects Versions: 4.1.0.Final Reporter: Erik Salter Assignee: Manik Surtani We have a performance test that is putting 10K objects into a 4-node cluster, with each of the nodes on separate physical machines. We are seeing loss of data after an insert and loss of a data node. The test directions and code are attached to this JIRA. -- 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, 4 months

4
23
0 / 0

[JBoss JIRA] Created: (ISPN-777) Eager cluster wide locks not cleaned upon rollback

by Vladimir Blagojevic (JIRA)

Eager cluster wide locks not cleaned upon rollback -------------------------------------------------- Key: ISPN-777 URL: https://jira.jboss.org/browse/ISPN-777 Project: Infinispan Issue Type: Bug Components: Locking and Concurrency Affects Versions: 4.2.0.BETA1 Reporter: Vladimir Blagojevic Assignee: Mircea Markus Fix For: 4.2.0.CR1 It seems that rollback sometimes does not release acquired eager locks. See attached test program and run two JVM instances on the same machine. Program schedules a task to run every 5 seconds. Tasks simply locks a key, gets the value, increases the value and puts it back surrounded by begin/commit/rollback tx boundary. Steps to reproduce: 1) Kill one running instance. 2) Restart it See attached example output of a run. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

4
23
0 / 0

[JBoss JIRA] Created: (ISPN-832) TimeoutException with 2 or more nodes when there are Entity inserts, updates or removes.

by Cyrille Charron (JIRA)

TimeoutException with 2 or more nodes when there are Entity inserts, updates or removes. ---------------------------------------------------------------------------------------- Key: ISPN-832 URL: https://issues.jboss.org/browse/ISPN-832 Project: Infinispan Issue Type: Bug Components: State transfer Affects Versions: 4.2.0.CR3 Environment: Windows XP + Hibernate 3.6.1-SNAPSHOT + OpenEjb 3.2-SNAPSHOT Reporter: Cyrille Charron Assignee: Manik Surtani Hello, I have some difficulties to run more than one Node with Infinispan as a JPA Level2 cache (default configuration) with Hibernate as JPA provider and with OpenEjb as JEE container. There are a lot of Locks between Nodes when I try to insert entities, even if each Node insert entities with a unique ID. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

3
29
0 / 0

[JBoss JIRA] Created: (ISPN-846) In HotRod, errors reading the header should not be hidden

by Galder Zamarreño (JIRA)

In HotRod, errors reading the header should not be hidden --------------------------------------------------------- Key: ISPN-846 URL: https://issues.jboss.org/browse/ISPN-846 Project: Infinispan Issue Type: Bug Components: Cache Server Affects Versions: 5.0.0.ALPHA1, 4.2.0.Final Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.0.0.BETA1, 5.0.0.Final If Hot Rod has an issue reading the header (for example, the cache name), the actual issue gets hidden in the logs: 2010-12-21 10:02:49,948 TRACE [HotRodEncoder$] (HotRodServerWorker-1-1) Encode msg GetResponse{messageId=1, operation=GetResponse, status=KeyDoesNotExist, data=null} 2010-12-21 10:02:50,100 TRACE [Decoder10$] (HotRodServerWorker-1-2) Operation code: 3 has been matched to GetRequest 2010-12-21 10:02:50,538 ERROR [AbstractProtocolDecoder$] (HotRodServerWorker-1-2) Exception reported java.util.NoSuchElementException: None.get at scala.None$.get(Option.scala:262) at scala.None$.get(Option.scala:260) at org.infinispan.server.hotrod.HotRodDecoder.createServerException(HotRodDecoder.scala:138) at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:55) Add better error handling for such situations. This came from trying to debug the Python Hot Rod client. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

2
7
0 / 0

[JBoss JIRA] Created: (ISPN-844) Better documentation for infinispan.module.name

by Galder Zamarreño (JIRA)

Better documentation for infinispan.module.name ----------------------------------------------- Key: ISPN-844 URL: https://issues.jboss.org/browse/ISPN-844 Project: Infinispan Issue Type: Task Components: Configuration Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.0.0.BETA1 In the Infinispan Module Lifecycle configuration, "infinispan.module.name" needs to be better documented. All it's used is to differentiate between diff modules, since it becomes the key of an internal map. So, you can actually use anything for this property, but you don't want two diff modules using the same string. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

2
4
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues December 2010