August 2011 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-1262) Validate that the JCache interceptors are declared in the beans.xml

by Kevin Pollet (JIRA)

Validate that the JCache interceptors are declared in the beans.xml ------------------------------------------------------------------- Key: ISPN-1262 URL: https://issues.jboss.org/browse/ISPN-1262 Project: Infinispan Issue Type: Feature Request Components: CDI integration Reporter: Kevin Pollet Assignee: Kevin Pollet Priority: Minor We could validate that the JCache interceptors are enabled in the {{beans.xml}} at deployment. This check can be done at {{AfterBeanDiscovery}} phase with {{BeanManager#resolverInterceptors()}} for each JCache annotations. The deployment could fail only when JCache annotations are used in the application. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

2
5
0 / 0

[JBoss JIRA] Created: (ISPN-1261) Complete the work on the event bridge between Infinispan and CDI

by Kevin Pollet (JIRA)

Complete the work on the event bridge between Infinispan and CDI ---------------------------------------------------------------- Key: ISPN-1261 URL: https://issues.jboss.org/browse/ISPN-1261 Project: Infinispan Issue Type: Task Components: CDI integration Reporter: Kevin Pollet Assignee: Kevin Pollet The event bridge (for cache and cache manager) is already implemented in the code but some events are not supported and a deprecated one is used. The following work has to be done on the event bridge: * Remove deprecated event * Support all events * Verify how cache and cache manager observers are registered * Tests * Doc -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

4
12
0 / 0

[JBoss JIRA] Created: (ISPN-1146) Improve documentation around transaction and locking

by Mircea Markus (JIRA)

Improve documentation around transaction and locking ---------------------------------------------------- Key: ISPN-1146 URL: https://issues.jboss.org/browse/ISPN-1146 Project: Infinispan Issue Type: Task Components: Transactions Reporter: Mircea Markus Assignee: Mircea Markus Fix For: 5.1.0.Final As suggested by Jonathan Halliday: - preserving some subset of the existing transactional guarantees is all well and good BUT if the user is relying on additional 'guarantees' that are not preserved in all cases then they'll be in trouble. Therefore, it's essential to document not just what the minimum expected guarantees for a given config are, but also that no additional properties that may coincidently be observed are actually guaranteed. Some vendors go further and explicitly document the bad things that may happen with given settings, since in some cases these are not easy to reproduce in testing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

2
6
0 / 0

[JBoss JIRA] Created: (ISPN-825) Consider staggering remote get requests when using DIST

by Manik Surtani (JIRA)

Consider staggering remote get requests when using DIST ------------------------------------------------------- Key: ISPN-825 URL: https://jira.jboss.org/browse/ISPN-825 Project: Infinispan Issue Type: Feature Request Components: RPC Affects Versions: 4.1.0.Final Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.0.0.BETA1, 5.0.0.Final In DIST mode, when a request is made on a key that is not mapped locally, a remote get is sent to all data owners of that key and the first response is used. This can add unnecessary load on the network as all nodes still eventually respond, and if values are large this can cause a lot of unnecessary network traffic. The purpose of broadcasting to all data owners is so that (1) if one is down, another could still respond (2) if one is overloaded, others may respond faster. A solution around this could be based on either (or both) of: * Provide a configurable stagger timeout, e.g. 100ms. E.g., RPC to (random) Owner1. Wait for timeout t. If no response, RPC to Owner2. etc. * Always broadcast to a (configurable) subset of owners, e.g., always 2 even if numOwners is 5. Needs careful thought and design. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

4
10
0 / 0

[JBoss JIRA] Created: (ISPN-647) Remote InboundInvocationHandler should differentiate between various cache inavailabilities

by Manik Surtani (JIRA)

Remote InboundInvocationHandler should differentiate between various cache inavailabilities ------------------------------------------------------------------------------------------- Key: ISPN-647 URL: https://jira.jboss.org/browse/ISPN-647 Project: Infinispan Issue Type: Feature Request Components: RPC Affects Versions: 4.2.0.ALPHA1, 4.1.0.Final Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 4.2.0.BETA1, 4.2.0.CR1 Currently a RequestIgnoredResponse is returned to any caller if either of these happen: * The cache is not yet started, is in the process of starting, and times out. * The cache doesn't exist. * The cache has been stopped. The latter two should use a different response type - CacheUnavailableResponse ? - that would not trigger a retry or any abort of transactions. -- 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

5
11
0 / 0

[JBoss JIRA] Created: (ISPN-317) when unsafeReturnValues is false, combine put, remove, replace, putIfAbsent, to pull back responses in 1 command

by Mircea Markus (JIRA)

when unsafeReturnValues is false, combine put, remove, replace, putIfAbsent, to pull back responses in 1 command ---------------------------------------------------------------------------------------------------------------- Key: ISPN-317 URL: https://jira.jboss.org/jira/browse/ISPN-317 Project: Infinispan Issue Type: Feature Request Reporter: Mircea Markus Assignee: Manik Surtani Fix For: 4.1.0.CR1 at the moment this is split in two operations: a remote get followed by an put. Optimize this to only reside in one operation. -- 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, 1 month

7
25
0 / 0

[JBoss JIRA] Created: (ISPN-1345) Dirty reads may occurs on mutable objects

by Christophe Labouisse (JIRA)

Dirty reads may occurs on mutable objects ----------------------------------------- Key: ISPN-1345 URL: https://issues.jboss.org/browse/ISPN-1345 Project: Infinispan Issue Type: Bug Components: Transactions Affects Versions: 5.0.0.FINAL Environment: Windows Java 1.6.0_26 Reporter: Christophe Labouisse Assignee: Manik Surtani In local mode, I create a cache like this: {code} cacheManager = new DefaultCacheManager(); cacheManager.getDefaultConfiguration().fluent().storeAsBinary().transaction().cacheStopTimeout(5000); final Configuration config = new Configuration().fluent().transactionManagerLookup(this.tmLookup).locking() .isolationLevel(IsolationLevel.READ_COMMITED).build(); this.cacheManager.defineConfiguration("Gruik", config); this.cache = this.cacheManager.getCache("Gruik"); {code} When retrieving data using {{cache.get(_key_)}} I find out that Infinispan returns the object instance actually stored in the cache datastore. This is OK when the inserted objects are immutable but fails to achieve isolation when using mutable objects. For instance on a simple Pojo with a {{get/setValue}}. ||Step||Reader||Writer|| |1|Starts transaction| | |2|{{value = cache.get(KEY);}}| | |3|{{System.out.println(value.getValue());}} Prints 42| | |4| |Starts transaction| |5| |{{value = cache.get(KEY);}} Same instance than step 2| |6| |{{value.setValue(666); // Prepare update}}| |7|{{System.out.println(value.getValue());}} Prints 666 !| | |8|{{value = cache.get(KEY);}} Same instance than step 2| | |9| |{{cache.put(KEY,value);}}| |10| |Commits transaction| |11|{{value = cache.get(KEY);}} Same instance than step 2| | |12|{{System.out.println(value.getValue());}} Prints 666| | |13|Commits transaction| | According to the READ_COMMITTED specification, the value returned printed on step 7 should be 42, as the setting to 666 is not committed yes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

8
18
0 / 0

[JBoss JIRA] Created: (ISPN-1272) Move away from javadoc's aggregate goal

by Galder Zamarreño (JIRA)

Move away from javadoc's aggregate goal --------------------------------------- Key: ISPN-1272 URL: https://issues.jboss.org/browse/ISPN-1272 Project: Infinispan Issue Type: Enhancement Components: Build process Reporter: Galder Zamarreño Assignee: Manik Surtani Priority: Minor Fix For: 5.2.0.FINAL We should move away from maven javadoc's aggregate goal because it creates a lot of pains. For starters, it often spawns a separate process, -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

2
1
0 / 0

[JBoss JIRA] Created: (ISPN-1213) TreeCache expires parents that have children

by Todd Ciezadlo (JIRA)

TreeCache expires parents that have children -------------------------------------------- Key: ISPN-1213 URL: https://issues.jboss.org/browse/ISPN-1213 Project: Infinispan Issue Type: Bug Components: Eviction Affects Versions: 4.2.1.FINAL Reporter: Todd Ciezadlo Assignee: Manik Surtani TreeCache parents expire according to the max-idle value even if they contain children. This puts the tree cache in an inconsistent state since the "dangling" children can be retrieved through TreeCache.get(FQN, String) calls, but cannot be traversed to through TreeCache.getRoot() and Node.getChildren() calls. Copied a unit test to Steps to Reproduce. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

6
16
0 / 0

[JBoss JIRA] Created: (ISPN-959) Refactor documentation on wiki

by Manik Surtani (JIRA)

Refactor documentation on wiki ------------------------------ Key: ISPN-959 URL: https://issues.jboss.org/browse/ISPN-959 Project: Infinispan Issue Type: Task Affects Versions: 5.0.0.Final Reporter: Manik Surtani Assignee: Manik Surtani This would take into account the new Confluence setup on docs.jboss.org, as well as docbook exporters and the ability to organise documentation as well as wiki pages based on versions of Infinispan. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

2
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues August 2011