October 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-1952) Use RESTEasy's HTTP frontend for the REST server

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1952?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1952: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Use RESTEasy's HTTP frontend for the REST server > ------------------------------------------------ > > Key: ISPN-1952 > URL: https://issues.jboss.org/browse/ISPN-1952 > Project: Infinispan > Issue Type: Feature Request > Components: Remote protocols > Reporter: NadirX > Assignee: Tristan Tarrant > Original Estimate: 0 minutes > Remaining Estimate: 0 minutes > > Using RESTEasy's HTTP frontend would allow the following: > - allow starting of a containerless REST Server using the startServer.sh script in the distibution > - drop the need for JBossWeb in JDG > - Give us some noticeable performance improvements -- 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-2174) CommandAwareRpcDispatcher swallows thread interruptions

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2174?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2174: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > CommandAwareRpcDispatcher swallows thread interruptions > ------------------------------------------------------- > > Key: ISPN-2174 > URL: https://issues.jboss.org/browse/ISPN-2174 > Project: Infinispan > Issue Type: Bug > Components: RPC > Affects Versions: 5.1.5.FINAL > Reporter: Michal Linhard > Assignee: Galder Zamarreño > Labels: jdg, jdg6 > > When interruption happens in FutureCollator.getResponseList() method > see > https://github.com/infinispan/infinispan/blob/5.1.x/core/src/main/java/or... > it is ignored and later wrongly dealt with as TimeoutException > (The original exception is not even set as cause anywhere) > This disables possibility of interrupting some cache operations. -- 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 Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2103?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2103: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > 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 > > 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-2115) Relative path in rhq ant task cause build to fail

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2115?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2115: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > 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 > > 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-2090) Cache get from TransactionCompleted throws IllegalStateException

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2090?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2090: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > 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 > > 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-2278) Implicit transaction enabling during configuration fails

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2278?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2278: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > 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 > > 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

[JBoss JIRA] (ISPN-2177) Refactor AbstractCacheTransaction

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2177?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2177: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > 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 > > 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-2376) KeyAffinityServiceImpl.getKeyForAddress() can loop forever when DefaultConsistentHash has numSegments < numNodes

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2376?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2376: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > KeyAffinityServiceImpl.getKeyForAddress() can loop forever when DefaultConsistentHash has numSegments < numNodes > ---------------------------------------------------------------------------------------------------------------- > > Key: ISPN-2376 > URL: https://issues.jboss.org/browse/ISPN-2376 > Project: Infinispan > Issue Type: Bug > Components: Core API > Affects Versions: 5.2.0.Beta1 > Reporter: Scott Marlow > Assignee: Dan Berindei > Priority: Minor > > I instrumented KeyAffinityServiceImpl and DefaultConsistentHash to show why KeyAffinityServiceImpl is looping forever when running the AS7 clustered tests with some recent changes that aren't committed yet. We are hoping to get through this failure so we can get clustered tests running again more completely on our continuous test server (lightning). > We have two nodes running in the AS cluster, node-0/web and node-1/web. > In my recent test run, I stopped the test after it was stuck for a while. Below is some of the instrumented logging output. > {quote} > KeyAffinityServiceImpl interestedInAddress() check, for address: node-1/web, filter.contains(address) returns false, filter contents [node-0/web] > . > . > . > KeyAffinityServiceImpl.getKeyForAddress() loop # 1455775 will loop again since result is null, queue [], address node-0/web > {quote} > We are using address "node-1/web" because that is passed into the DefaultConsistentHash constructor segmentOwners parameter (element zero). > Later, address=node-1/web is the primary owner of the consistent hash (hash=DefaultConsistentHash{numSegments=1, numOwners=2, members=[node-1/web, node-0/web], segmentOwners={0: 0 1}). > I'm still collecting information and want to get a little more. > Let me know if there is anything that you would like to see. -- 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-2359) Query should not reindex cache entries on preload or activation

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2359?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2359: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Query should not reindex cache entries on preload or activation > --------------------------------------------------------------- > > Key: ISPN-2359 > URL: https://issues.jboss.org/browse/ISPN-2359 > Project: Infinispan > Issue Type: Enhancement > Components: Querying > Reporter: Sanne Grinovero > Assignee: Adrian Nistor > Labels: stable_embedded_query > > If a cache entry is returning to the Infinispan datacontainer after activation or preloading it should not be re-indexed. > Check also that passivation doesn't remove the entry from the index. -- 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 Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2302?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2302: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > 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 > > 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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2013