July 2010 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-272) recover from transaction failures

by Mircea Markus (JIRA)

recover from transaction failures --------------------------------- Key: ISPN-272 URL: https://jira.jboss.org/jira/browse/ISPN-272 Project: Infinispan Issue Type: Feature Request Components: Transactions Affects Versions: 5.0.0.GA Reporter: Mircea Markus Assignee: Manik Surtani We currently don't support any sort of recovery from transaction failures. E.g. tm.start(); database.delete(account); ispnCache.put(account); tm.commit(): At tm commit: -prepare is successful on both enlisted resources. - database.commit - fails What shall we do with the locks/state from ispnCache. Possible solutions: - configure to automatically commit/rollback after a timeout - keep locks on resources and allow manual intervention through JMX - others? -- 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

13 years, 1 month

4
19
0 / 0

[JBoss JIRA] Created: (ISPN-362) allow pluggable data container in infinispan

by Mircea Markus (JIRA)

allow pluggable data container in infinispan -------------------------------------------- Key: ISPN-362 URL: https://jira.jboss.org/jira/browse/ISPN-362 Project: Infinispan Issue Type: Feature Request Reporter: Mircea Markus Assignee: Manik Surtani In relation to http://community.jboss.org/message/529586#529586 Users might want to write their own data container and be able to plug that in infinispan. Implementing this would require: - change configuration to support an dataContainer element perhaps under "eviction" elements. This will be passed to DataContainerFacvtory, which will build an instance of the class and pass it back. Actually, in order to allow parameters to this container, it can look like: <eviction wakeUpInterval="500" maxEntries="5000"> <dataContainer class="custom.data.Conatiner"> <properties> <propery name="configParam" value="configValue"/> </properties> </dataContainer> </eviction> -- 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

13 years, 1 month

5
8
0 / 0

[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

13 years, 2 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

13 years, 2 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

13 years, 2 months

4
7
0 / 0

[JBoss JIRA] Created: (ISPN-133) Upgrade JClouds to a version that depends on Apache HTTP Core that fixes HTTPCORE-199

by Galder Zamarreno (JIRA)

Upgrade JClouds to a version that depends on Apache HTTP Core that fixes HTTPCORE-199 ------------------------------------------------------------------------------------- Key: ISPN-133 URL: https://jira.jboss.org/jira/browse/ISPN-133 Project: Infinispan Issue Type: Thirdparty Change Components: Loaders and Stores Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.0.0.CR1 https://issues.apache.org/jira/browse/HTTPCORE-199 Remove temporary workaround in ISPN-119 as part of this: http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/main/java/org/i... -- 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

13 years, 3 months

4
14
0 / 0

[JBoss JIRA] Created: (ISPN-376) Enable Infinispan standalone's Channel to be plugged with MessageListeners

by Galder Zamarreno (JIRA)

Enable Infinispan standalone's Channel to be plugged with MessageListeners -------------------------------------------------------------------------- Key: ISPN-376 URL: https://jira.jboss.org/jira/browse/ISPN-376 Project: Infinispan Issue Type: Feature Request Components: RPC Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 5.0.0.BETA1, 5.0.0.Final Investigate what would need doing to enable Infinispan to receive a JGroups' Channel or ChannelFactory that allows users to add their own message listeners when such clients want to be sending rpcs around. Brian will be using a solution like this for the AS case but since AS is owner of the Channel, this is relatively easy for it assuming that JGroups has the right API for it. -- 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

13 years, 3 months

2
1
0 / 0

[JBoss JIRA] Created: (ISPN-329) Move coalesced logic from Unscheduled to Scheduled Write-Behind or asynchronous cache store

by Galder Zamarreno (JIRA)

Move coalesced logic from Unscheduled to Scheduled Write-Behind or asynchronous cache store ------------------------------------------------------------------------------------------- Key: ISPN-329 URL: https://jira.jboss.org/jira/browse/ISPN-329 Project: Infinispan Issue Type: Task Components: Loaders and Stores Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.1.0.BETA1 In the async cache store, remove coalescing of modifications from Unscheduled Write-Behind or strategy and move it to the Scheduled Write-Behind strategy. The aim of the Unscheduled strategy is to be as fast as possible. Having to deal with coalescing changes is only going to slow it down for very little gain. Coalescing changes in an schedule strategy makes a lot more sense. -- 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

13 years, 3 months

2
2
0 / 0

[JBoss JIRA] Created: (ISPN-313) Provide an StandaloneJGroupsChannelLookup implementation

by Galder Zamarreno (JIRA)

Provide an StandaloneJGroupsChannelLookup implementation -------------------------------------------------------- Key: ISPN-313 URL: https://jira.jboss.org/jira/browse/ISPN-313 Project: Infinispan Issue Type: Feature Request Components: RPC Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.1.0.BETA1 StandaloneJGroupsChannelLookup would target environments that are either standalone or within other app servers that are not JBoss. It would allow for different Infinispan configurations to use the same shared transport, reducing network configuration. Infinispan and StandaloneJGroupsChannelLookup, if you guys create such a class, have it use the ChannelFactory.createChannel(String stack_name) method, not the old legacy createMultiplexerChannel method used by JBC. ChannelFactory.createChannel(String stack_name) will be a stable API, createMultiplexerChannel(...) may go away in JGroups 3.0. ChannelFactory.createChannel(String stack_name) lets you get a shared transport channel if the stack's transport protocol config has the singleton_name element. Full thread can be found in forum reference link -- 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

13 years, 3 months

3
2
0 / 0

[JBoss JIRA] Created: (ISPN-344) Verify asynchronicity of replace() calls

by Galder Zamarreno (JIRA)

Verify asynchronicity of replace() calls ---------------------------------------- Key: ISPN-344 URL: https://jira.jboss.org/jira/browse/ISPN-344 Project: Infinispan Issue Type: Task Components: Loaders and Stores Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.0.0.GA Verify whether replace() calls are coalesced and executed in a separate thread for async store. -- 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

13 years, 3 months

4
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2010