November 2011 - infinispan-issues

[JBoss JIRA] (ISPN-1551) NPE when creating a DefaultCacheManager with the new Configuration

by Kevin Pollet (Created) (JIRA)

NPE when creating a DefaultCacheManager with the new Configuration ------------------------------------------------------------------ Key: ISPN-1551 URL: https://issues.jboss.org/browse/ISPN-1551 Project: Infinispan Issue Type: Bug Components: Configuration Affects Versions: 5.1.0.BETA5 Reporter: Kevin Pollet Assignee: Pete Muir Priority: Blocker Fix For: 5.1.0.CR1 The following code throws an NPE. {code} new DefaultCacheManager(new ConfigurationBuilder().build()) {code} The exception: {quote} Caused by: java.lang.NullPointerException at org.infinispan.configuration.global.LegacyGlobalConfigurationAdaptor.adapt(LegacyGlobalConfigurationAdaptor.java:12) at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:307) at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:176) {quote} -- 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

13 years, 10 months

2
1
0 / 0

[JBoss JIRA] (ISPN-1547) Infinispan requires protected access between api and core jars

by Brent Douglas (Created) (JIRA)

Infinispan requires protected access between api and core jars -------------------------------------------------------------- Key: ISPN-1547 URL: https://issues.jboss.org/browse/ISPN-1547 Project: Infinispan Issue Type: Bug Components: Core API Affects Versions: 5.1.0.BETA5 Environment: jboss-as-7.1.0.Alpha2-SNAPSHOT, Infinispan 5.1.0.BETA5 Reporter: Brent Douglas Assignee: Manik Surtani Infinispan requires protected access across the core and api jars requiring a common class loader for all jars. The current module setup for as7 will have all three loaded by different classloaders. Caused by: java.lang.IllegalAccessError: tried to access field org.infinispan.CacheSupport.defaultLifespan from class org.infinispan.DecoratedCache at org.infinispan.DecoratedCache.put(DecoratedCache.java:297) [infinispan-core-5.1.0.BETA5.jar:5.1.0.BETA5] at org.infinispan.tree.CacheAdapter.put(CacheAdapter.java:257) [infinispan-tree-5.1.0.BETA4.jar:7.1.0.Alpha2-SNAPSHOT] at org.infinispan.atomic.AtomicHashMapProxy.getDeltaMapForWrite(AtomicHashMapProxy.java:150) [infinispan-core-5.1.0.BETA5.jar:5.1.0.BETA5] at org.infinispan.atomic.AtomicHashMapProxy.put(AtomicHashMapProxy.java:206) [infinispan-core-5.1.0.BETA5.jar:5.1.0.BETA5] at org.infinispan.tree.TreeStructureSupport.createNodeInCache(TreeStructureSupport.java:70) [infinispan-tree-5.1.0.BETA4.jar:7.1.0.Alpha2-SNAPSHOT] at org.infinispan.tree.TreeStructureSupport.createNodeInCache(TreeStructureSupport.java:68) [infinispan-tree-5.1.0.BETA4.jar:7.1.0.Alpha2-SNAPSHOT] at org.infinispan.tree.TreeStructureSupport.createNodeInCache(TreeStructureSupport.java:68) [infinispan-tree-5.1.0.BETA4.jar:7.1.0.Alpha2-SNAPSHOT] at org.infinispan.tree.TreeStructureSupport.createNodeInCache(TreeStructureSupport.java:68) [infinispan-tree-5.1.0.BETA4.jar:7.1.0.Alpha2-SNAPSHOT] at org.infinispan.tree.TreeStructureSupport.createNodeInCache(TreeStructureSupport.java:68) [infinispan-tree-5.1.0.BETA4.jar:7.1.0.Alpha2-SNAPSHOT] at org.infinispan.tree.TreeStructureSupport.createNodeInCache(TreeStructureSupport.java:68) [infinispan-tree-5.1.0.BETA4.jar:7.1.0.Alpha2-SNAPSHOT] at org.infinispan.tree.TreeStructureSupport.createNodeInCache(TreeStructureSupport.java:68) [infinispan-tree-5.1.0.BETA4.jar:7.1.0.Alpha2-SNAPSHOT] at org.infinispan.tree.TreeStructureSupport.createNodeInCache(TreeStructureSupport.java:68) [infinispan-tree-5.1.0.BETA4.jar:7.1.0.Alpha2-SNAPSHOT] at org.infinispan.tree.TreeCacheImpl.put(TreeCacheImpl.java:430) [infinispan-tree-5.1.0.BETA4.jar:7.1.0.Alpha2-SNAPSHOT] at org.infinispan.tree.TreeCacheImpl.put(TreeCacheImpl.java:72) [infinispan-tree-5.1.0.BETA4.jar:7.1.0.Alpha2-SNAPSHOT] -- 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

13 years, 10 months

3
2
0 / 0

[JBoss JIRA] Created: (ISPN-1391) Use UNICAST2 instead of UNICAST

by Galder Zamarreño (JIRA)

Use UNICAST2 instead of UNICAST ------------------------------- Key: ISPN-1391 URL: https://issues.jboss.org/browse/ISPN-1391 Project: Infinispan Issue Type: Enhancement Components: RPC Reporter: Galder Zamarreño Assignee: Dan Berindei Fix For: 5.1.0.BETA2, 5.1.0.FINAL UNICAST2 already available in JGroups 2.12: http://www.jgroups.org/javadoc/org/jgroups/protocols/UNICAST2.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

6
8
0 / 0

[JBoss JIRA] (ISPN-1549) NPE when using the new ConfigurationBuilder

by Kevin Pollet (Created) (JIRA)

NPE when using the new ConfigurationBuilder ------------------------------------------- Key: ISPN-1549 URL: https://issues.jboss.org/browse/ISPN-1549 Project: Infinispan Issue Type: Bug Components: Configuration Affects Versions: 5.1.0.BETA5 Reporter: Kevin Pollet Assignee: Pete Muir Priority: Blocker Fix For: 5.1.0.CR1 For example the following codes throws an NPE: {code} Configuration configuration = new ConfigurationBuilder() .eviction().maxEntries(20) .build(); ---- Configuration configuration = new ConfigurationBuilder() .jmxStatistics() .build(); {code} The exception: {quote} java.lang.NullPointerException at org.infinispan.configuration.cache.LoadersConfigurationBuilder.create(LoadersConfigurationBuilder.java:48) at org.infinispan.configuration.cache.ConfigurationBuilder.build(ConfigurationBuilder.java:140) {quote} -- 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

13 years, 10 months

2
1
0 / 0

[JBoss JIRA] (ISPN-61) Dynamically switch between single and two phase commit based on cluster size

by Manik Surtani (Updated) (JIRA)

[ https://issues.jboss.org/browse/ISPN-61?page=com.atlassian.jira.plugin.sy... ] Manik Surtani updated ISPN-61: ------------------------------ Fix Version/s: 5.2.0.FINAL (was: 5.1.0.FINAL) (was: 5.1.0.CR1) Priority: Major (was: Critical) > Dynamically switch between single and two phase commit based on cluster size > ---------------------------------------------------------------------------- > > Key: ISPN-61 > URL: https://issues.jboss.org/browse/ISPN-61 > Project: Infinispan > Issue Type: Feature Request > Affects Versions: 4.0.0.ALPHA4 > Reporter: Mircea Markus > Assignee: Mircea Markus > Fix For: 5.2.0.FINAL > > > Following 2 optimizations might be implemented with respect to transactions. > 1) From an email on infinispan-dev (horizon-dev actually): > if there are only two members int the cluster always use an 1PC. If the 1st phase fails remotely, then also rollback locally. This would reduce one network roundtrip. > While this is an interesting thought, it does raise the potential for race conditions - since this decision will have to be taken in the TxInterceptor in the beforeCompletion phase of a transaction, and by the time the call gets to the interceptor for replication, the topology may have changed such that you need to replicate to 2 instead of 1 other peer. Which would mean a 2PC again. So it does need some thought. > 2) when asked to prepare, a participant might return a value indicating that no changes were made (read-only participant), so this one won't need an commit message, so less roundtrip. -- 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

13 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-61) Dynamically switch between single and two phase commit based on cluster size

by Manik Surtani (Updated) (JIRA)

[ https://issues.jboss.org/browse/ISPN-61?page=com.atlassian.jira.plugin.sy... ] Manik Surtani updated ISPN-61: ------------------------------ Summary: Dynamically switch between single and two phase commit based on cluster size (was: Transaction 2-phase protocol optimizations) > Dynamically switch between single and two phase commit based on cluster size > ---------------------------------------------------------------------------- > > Key: ISPN-61 > URL: https://issues.jboss.org/browse/ISPN-61 > Project: Infinispan > Issue Type: Feature Request > Affects Versions: 4.0.0.ALPHA4 > Reporter: Mircea Markus > Assignee: Mircea Markus > Priority: Critical > Fix For: 5.1.0.CR1, 5.1.0.FINAL > > > Following 2 optimizations might be implemented with respect to transactions. > 1) From an email on infinispan-dev (horizon-dev actually): > if there are only two members int the cluster always use an 1PC. If the 1st phase fails remotely, then also rollback locally. This would reduce one network roundtrip. > While this is an interesting thought, it does raise the potential for race conditions - since this decision will have to be taken in the TxInterceptor in the beforeCompletion phase of a transaction, and by the time the call gets to the interceptor for replication, the topology may have changed such that you need to replicate to 2 instead of 1 other peer. Which would mean a 2PC again. So it does need some thought. > 2) when asked to prepare, a participant might return a value indicating that no changes were made (read-only participant), so this one won't need an commit message, so less roundtrip. -- 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

13 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (ISPN-1130) Eager locks acquired multiple times

by Mircea Markus (JIRA)

Eager locks acquired multiple times ----------------------------------- Key: ISPN-1130 URL: https://issues.jboss.org/browse/ISPN-1130 Project: Infinispan Issue Type: Feature Request Components: Transactions Affects Versions: 4.2.1.FINAL Reporter: Mircea Markus Assignee: Manik Surtani If eager locking is enabled, a remote lock is acquired repeatedly. e.g. tx.begin() cache.put(k,v); //rpc acquiring lock on "k" ... cache.remove(k); // another rpc for acquiring lock on "k" tx.commit(); the second rpc for acquiring lock is un-necessary. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

6
13
0 / 0

[JBoss JIRA] (ISPN-1530) Represent byte arrays in hex format when logging

by Galder Zamarreño (Created) (JIRA)

Represent byte arrays in hex format when logging ------------------------------------------------ Key: ISPN-1530 URL: https://issues.jboss.org/browse/ISPN-1530 Project: Infinispan Issue Type: Enhancement Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.1.0.BETA5 Byte arrays are a pain to track in log files. We need a more compact and easier way of tracking them down, so I suggest from now on we show their HEX representation: https://gist.github.com/1370843 We can still limit the length, as we do now with byte[], and if you need the full length, you can carry on using the system property we defined. -- 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

13 years, 10 months

9
12
0 / 0

[JBoss JIRA] (ISPN-61) Transaction 2-phase protocol optimizations

by Galder Zamarreño (Updated) (JIRA)

[ https://issues.jboss.org/browse/ISPN-61?page=com.atlassian.jira.plugin.sy... ] Galder Zamarreño updated ISPN-61: --------------------------------- Fix Version/s: 5.1.0.CR1 (was: 5.1.0.BETA5) > Transaction 2-phase protocol optimizations > ------------------------------------------ > > Key: ISPN-61 > URL: https://issues.jboss.org/browse/ISPN-61 > Project: Infinispan > Issue Type: Feature Request > Affects Versions: 4.0.0.ALPHA4 > Reporter: Mircea Markus > Assignee: Mircea Markus > Priority: Critical > Fix For: 5.1.0.CR1, 5.1.0.FINAL > > > Following 2 optimizations might be implemented with respect to transactions. > 1) From an email on infinispan-dev (horizon-dev actually): > if there are only two members int the cluster always use an 1PC. If the 1st phase fails remotely, then also rollback locally. This would reduce one network roundtrip. > While this is an interesting thought, it does raise the potential for race conditions - since this decision will have to be taken in the TxInterceptor in the beforeCompletion phase of a transaction, and by the time the call gets to the interceptor for replication, the topology may have changed such that you need to replicate to 2 instead of 1 other peer. Which would mean a 2PC again. So it does need some thought. > 2) when asked to prepare, a participant might return a value indicating that no changes were made (read-only participant), so this one won't need an commit message, so less roundtrip. -- 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

13 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (ISPN-1397) Optimise thread local usage in Infinispan

by Manik Surtani (JIRA)

Optimise thread local usage in Infinispan ----------------------------------------- Key: ISPN-1397 URL: https://issues.jboss.org/browse/ISPN-1397 Project: Infinispan Issue Type: Feature Request Components: Core API Affects Versions: 5.0.0.FINAL Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.1.0.BETA1, 5.1.0.FINAL Three separate areas to consider: 1. Remove ThreadLocal usage in OwnableReentrantLock 2. Remove ThreadLocal usage in InvocationContextContainer 3. Remove ThreadLocal usage in Flags API Look for any other ThreadLocal usage with a critical eye. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

7
11
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2011