October 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-1856) Allow independent configuration of buffer allocation size vs segment chunks maximum size

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-1856?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-1856: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > Allow independent configuration of buffer allocation size vs segment chunks maximum size > ---------------------------------------------------------------------------------------- > > Key: ISPN-1856 > URL: https://issues.jboss.org/browse/ISPN-1856 > Project: Infinispan > Issue Type: Enhancement > Components: Lucene Directory > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 6.0.0.Final > > > Especially make sure that we can allocate buffers efficiently when having chunk_size=MAX_INTEGER or other very high values. > Maybe reuse them as well? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2143) Improve how different indexed caches sync up on new indexed types

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2143?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-2143: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > Improve how different indexed caches sync up on new indexed types > ----------------------------------------------------------------- > > Key: ISPN-2143 > URL: https://issues.jboss.org/browse/ISPN-2143 > Project: Infinispan > Issue Type: Enhancement > Components: Querying > Reporter: Sanne Grinovero > Assignee: Adrian Nistor > Priority: Blocker > Labels: stable_embedded_query > Fix For: 6.0.0.Final > > > Currently when a node receives an unknown type, it doesn't inform all other nodes, which might fail to get metadata and index boot information from it. > Also, the list of known types should be stored somewhere. > When a shared index is used, we might be able to load some type names from the index itself, but unfortunately usually we need the type name to initialize the index. Rely on an index storage convention? > See also comments in {{org.infinispan.query.indexmanager.IndexUpdateCommand}} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2141) Better configuration options for Infinispan Query

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2141?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-2141: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > Better configuration options for Infinispan Query > ------------------------------------------------- > > Key: ISPN-2141 > URL: https://issues.jboss.org/browse/ISPN-2141 > Project: Infinispan > Issue Type: Feature Request > Components: Querying > Reporter: Sanne Grinovero > Assignee: Tristan Tarrant > Fix For: 6.0.0.Final > > > Rethink the configuration options for Query. > See also https://community.jboss.org/wiki/InfinispanQuery-DesignAndPlanning -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2115) Relative path in rhq ant task cause build to fail

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2115?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-2115: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > Relative path in rhq ant task cause build to fail > ------------------------------------------------- > > Key: ISPN-2115 > URL: https://issues.jboss.org/browse/ISPN-2115 > Project: Infinispan > Issue Type: Bug > Components: Build process > Reporter: Thomas Fromm > Assignee: Tristan Tarrant > Priority: Minor > Fix For: 6.0.0.Final > > > When the directory ../../ above the infinispan source dir is not writable, > than build fails: > [ERROR] Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.7:run (deploy) on project infinispan-rhq-plugin: An Ant BuildException has occured: Directory /usr/local/inubit/jon/dev-container/jbossas/server/default/deploy/${rhq.earName}/rhq-downloads/rhq-plugins creation was not successful for an unknown reason > [ERROR] around Ant part ...<mkdir dir="../../..//jon/dev-container/jbossas/server/default/deploy/${rhq.earName}/rhq-downloads/rhq-plugins"/>... @ 4:116 in /usr/local/inubit/tf/infinispan/rhq-plugin/target/antrun/build-main.xml > [ERROR] -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.7:run (deploy) on project infinispan-rhq-plugin: An Ant BuildException has occured: Directory /usr/local/inubit/jon/dev-container/jbossas/server/default/deploy/${rhq.earName}/rhq-downloads/rhq-plugins creation was not successful for an unknown reason > In current case the /usr/local/inubit/ is not writable for the user. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2103) Concurrent access after removal of an AtomicMap should NOT result in an IllegalStateException when accessed by other threads

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2103?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-2103: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > Concurrent access after removal of an AtomicMap should NOT result in an IllegalStateException when accessed by other threads > ---------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-2103 > URL: https://issues.jboss.org/browse/ISPN-2103 > Project: Infinispan > Issue Type: Bug > Components: Core API > Affects Versions: 5.1.5.FINAL > Reporter: Adrian Nistor > Assignee: Galder Zamarreño > Fix For: 6.0.0.Final > > > ISPN-1121 introduces an IllegalStateException that is being thrown from AtomicMap methods once the map handle has become stale (ie. removed from cache). In case of concurrent access, the exception is thrown to all threads not just to the thread that performed the removal. This was fine-ish in older versions of Infinispan before introduction of optimistic and pessimistic locking but it should be reconsidered now because: > 1. It interferes/overlaps with transaction isolation. We should rely on the selected locking scheme (OL/PL) to detect conflicts between transactions and report the problem accordingly. Especially if the stale map is used just for reading - this should be allowed to work rather than stop it. > 2. This exception is pretty disruptive and awkward to handle. All methods of an AtomicMap can result in this exception and the current thread has to be prepared for handling it if other threads remove the map. Not much transaction isolation. > 3. Since the TreeCache is backed by AtomicMap nearly all Tree API can throw this. > The proposed fix consists of: > 1. removing AtomicHashMap.removed flag and AtomicHashMap.markRemoved() method. > 2. revising AtomicHashMapProxy.assertValid() method to check only if the map is null (ie. removed) but no longer use the removed flag. > 3. revising ReadCommittedEntry.commit() method to no longer call markRemoved() method. > The consequences of these changes are: > 1. Any further access to a stale map results in IllegalStateException ONLY in the thread that performed the removal. This thread 'knows' the map is stale so it is fine to punish it. Other threads remain unaffected until lock acquisition or commit is performed (depending on locking model). > 2. Other threads can continue to use the previously obtained map handle for reads without danger of getting an exception. > 3. If a write operation is done on the map, the results depend on the locking model: > 3.1 optimistic locking + write skew check: a WriteSkewException will stop the commit during prepare > 3.2 optimistic locking, no write skew check: the write is committed and the work of the transaction that removed the map is overwritten. The map is effectively revived. > 3.3 pessimistic locking: same as 3.2 > Please note 3.2 and 3.3 work the same as for normal values (not atomic maps). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2090) Cache get from TransactionCompleted throws IllegalStateException

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2090?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-2090: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > Cache get from TransactionCompleted throws IllegalStateException > ---------------------------------------------------------------- > > Key: ISPN-2090 > URL: https://issues.jboss.org/browse/ISPN-2090 > Project: Infinispan > Issue Type: Bug > Components: Listeners, Transactions > Reporter: Galder Zamarreño > Assignee: Pedro Ruivo > Priority: Minor > Fix For: 6.0.0.Final > > > When implementing @TransactionCompleted in a sync listener, calling cache.get() even when event.isPre=false throws: > {code}IllegalStateException - ActionStatus.COMMITTED is not in a valid state to be invoking cache operations on{code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2302) New JdbcCacheStoreConfigurationBuilder should support existing ConnectionFactoryConfig

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2302?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-2302: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > New JdbcCacheStoreConfigurationBuilder should support existing ConnectionFactoryConfig > -------------------------------------------------------------------------------------- > > Key: ISPN-2302 > URL: https://issues.jboss.org/browse/ISPN-2302 > Project: Infinispan > Issue Type: Feature Request > Components: Configuration > Affects Versions: 5.2.0.Alpha3 > Reporter: Thomas Fromm > Assignee: Tristan Tarrant > Fix For: 6.0.0.Final > > > I've the situation the I need to reuse existing ConnectionFactoryConfigs. > Maybe implement ConnectionFactoryConfigurationBuilder with method read(ConnectionFactoryConfig template). Then extend JdbcCacheStoreConfigurationBuilder and add connectionFactory()? > I need it at least for the deprecated config migration of the ISPN test cases... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2177) Refactor AbstractCacheTransaction

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2177?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-2177: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > Refactor AbstractCacheTransaction > ----------------------------------- > > Key: ISPN-2177 > URL: https://issues.jboss.org/browse/ISPN-2177 > Project: Infinispan > Issue Type: Feature Request > Components: Transactions > Affects Versions: 5.1.2.FINAL > Reporter: Mircea Markus > Assignee: William Burns > Labels: refactoring, transaction > Fix For: 6.0.0.Final > > > There are several collections holding transaction related information in the AbstractCacheTransaction: > - lockedKeys: this holds all the keys that were actually locked on the local node > - affectedKeys: this holds all the keys that were acquired by the transaction allover the cluster > - backupKeyLocks: this holds all the locks for which the local node is a secondary data owner. > To do: > - affectedKeys belongs to LocalCacheTransaction(subclass) and no point in having it in the AbstractCacheTransaction > - a better name for affectedKeys might be "clusterLockedKey" and for lockedKeys --> localLokedKeys > - also add a Javadoc explaining the correlation between these key groups -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2324) Add user documentation for NSBT

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2324?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-2324: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > Add user documentation for NSBT > -------------------------------- > > Key: ISPN-2324 > URL: https://issues.jboss.org/browse/ISPN-2324 > Project: Infinispan > Issue Type: Feature Request > Affects Versions: 5.2.0.Alpha3 > Reporter: Mircea Markus > Assignee: Dan Berindei > Labels: documentation > Fix For: 6.0.0.Final > > > To be linked from the user guide page:https://docs.jboss.org/author/display/ISPN/User+Guide -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2278) Implicit transaction enabling during configuration fails

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2278?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-2278: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > Implicit transaction enabling during configuration fails > -------------------------------------------------------- > > Key: ISPN-2278 > URL: https://issues.jboss.org/browse/ISPN-2278 > Project: Infinispan > Issue Type: Bug > Components: Configuration > Affects Versions: 5.1.6.FINAL > Reporter: Thomas Fromm > Assignee: Tristan Tarrant > Fix For: 6.0.0.Final > > > The implicit enabling of transaction support does not work in all cases described in TransactionMode Javadoc inside the current configuration API. > - transactionManagerLookup is explicit configured > This works not in programmatic. > - enabled batching > When using XML configuration, this will not work, when only <invocationBatching> element and no <transaction> element is used. > At ConfigurationBuilderHolder.newConfigurationBuilder(...) the default cache config is used as base for the new named cache. Since build() is called, the TransactionConfiguration is set to NON_TRANSACTIONAL in the Configuration template used for the new ConfigurationBuilder. Later then any if(transactionMode == null)-related conditions in TransactionConfigurationBuilder will fail. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2013