July 2012 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-1862) fire TransactionCompletedEvent not as part of the transaction

by Thomas Fromm (JIRA)

Thomas Fromm created ISPN-1862: ---------------------------------- Summary: fire TransactionCompletedEvent not as part of the transaction Key: ISPN-1862 URL: https://issues.jboss.org/browse/ISPN-1862 Project: Infinispan Issue Type: Enhancement Components: Core API Affects Versions: 5.1.1.FINAL Reporter: Thomas Fromm Assignee: Manik Surtani When catching TransactionCompletedEvent I would expect, the transaction is committed, especially when isTransactionSuccessful() == true. I need to perform some operations after a transaction was completed. My workaround is ATM to suspend the transaction, perform my (async) stuff, and resume it afterwards. But in case of errors after resume, I get another TransactionCompletedEvent for this transaction with isTransactionSuccessful() == false. You see, I need something like a TransactionReallyCompletedEvent :-) My change request is, that the TransactionCompletedEvents should be fired, after the transaction was committed. -- 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

12 years, 3 months

4
5
0 / 0

[JBoss JIRA] Created: (ISPN-1424) Implement non-blocking state transfer again on top of push-based state transfer

by Dan Berindei (JIRA)

Implement non-blocking state transfer again on top of push-based state transfer ------------------------------------------------------------------------------- Key: ISPN-1424 URL: https://issues.jboss.org/browse/ISPN-1424 Project: Infinispan Issue Type: Feature Request Components: State transfer Affects Versions: 5.0.1.FINAL Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 5.2.0.FINAL Once we have the asymmetric caches support in we should be able to re-implement non-blocking state transfer. See the design document at http://community.jboss.org/wiki/AsymmetricCachesAndManualRehashingDesign#... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

3
2
0 / 0

[JBoss JIRA] (ISPN-2094) New Configuration Changes do not work properly for multi file overrides

by William Burns (JIRA)

William Burns created ISPN-2094: ----------------------------------- Summary: New Configuration Changes do not work properly for multi file overrides Key: ISPN-2094 URL: https://issues.jboss.org/browse/ISPN-2094 Project: Infinispan Issue Type: Bug Components: Configuration Affects Versions: 5.2.0.ALPHA1 Reporter: William Burns Assignee: Manik Surtani In 5.1.3 I had helped provide a way for a user to pass in multiple infinispan.xml files at once to the parser. This was added with ISPN-1837. The configuration was now changed again with ISPN-1977, which moves it over to using the staxmapper. This works fine for cache overrides with named caches. However the problem is that the overrides do not function properly for default caches. The problem is that each named cache is made after every single file. At the point of creation the named cache picks up the sofar configured default cache. This means that the named cache will not have the default values of subsequent files. Unfortunately, I do not know if this can be fixed while still using the staxmapper. -- 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

12 years, 3 months

5
23
0 / 0

[JBoss JIRA] (ISPN-2087) Listen for state transfer events to keep indexes in sync with datacontainers

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-2087: ------------------------------------- Summary: Listen for state transfer events to keep indexes in sync with datacontainers Key: ISPN-2087 URL: https://issues.jboss.org/browse/ISPN-2087 Project: Infinispan Issue Type: Feature Request Components: Querying Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 5.2.0.ALPHA1 When the index is not shared across nodes but is supposed to contain only the data being owned by the node, we need to keep this data in sync when the view changes. See also https://community.jboss.org/docs/DOC-18370 -- 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

12 years, 3 months

2
7
0 / 0

[JBoss JIRA] Created: (ISPN-686) JdbcStringBasedCacheStore loads previous data from store before an insert

by Sanne Grinovero (JIRA)

JdbcStringBasedCacheStore loads previous data from store before an insert ------------------------------------------------------------------------- Key: ISPN-686 URL: https://jira.jboss.org/browse/ISPN-686 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 4.2.0.ALPHA2, 4.1.0.Final, 4.0.0.Final Reporter: Sanne Grinovero Assignee: Manik Surtani Fix For: 4.2.0.Final, 5.0.0.Final The JdbcStringBasedCacheStore implementation loads the previous data on an insert to find out if it should generate an UPDATE or INSERT statement, while it would perform much better to just verify if the primary key exists. On top of this, some databases provide ways to avoid the need to check at all, like MySQL's " INSERT ... ON DUPLICATE KEY UPDATE" [http://dev.mysql.com/doc/refman/5.0/en/insert-on-duplicate.html] -- 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, 3 months

7
29
0 / 0

[JBoss JIRA] (ISPN-2066) Simplify configuration of an Infinispan backend in the Hibernate Search engine of Infinispan Query

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-2066: ------------------------------------- Summary: Simplify configuration of an Infinispan backend in the Hibernate Search engine of Infinispan Query Key: ISPN-2066 URL: https://issues.jboss.org/browse/ISPN-2066 Project: Infinispan Issue Type: Enhancement Components: Querying Reporter: Sanne Grinovero Assignee: Manik Surtani Fix For: 5.2.0.ALPHA1 Make sure we can inject the needed caches in the Hibernate Search engine being started by Query, and also that the custom commands being sent from the engine are "routed to" the same engine again for processing on the listener side related to https://community.jboss.org/docs/DOC-18370 -- 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

12 years, 3 months

2
9
0 / 0

[JBoss JIRA] (ISPN-2164) Return value of Cache.remove(key) not consistent in transactional context

by Carsten Lohmann (JIRA)

Carsten Lohmann created ISPN-2164: ------------------------------------- Summary: Return value of Cache.remove(key) not consistent in transactional context Key: ISPN-2164 URL: https://issues.jboss.org/browse/ISPN-2164 Project: Infinispan Issue Type: Bug Components: Core API, Transactions Affects Versions: 5.1.5.FINAL Reporter: Carsten Lohmann Assignee: Mircea Markus I have a scenario where multiple threads attempt to remove the same key concurrently via "cache.remove(key)" (each thread having explicitly started a transaction). I expect only one thread to succeed, ie. only one invocation of "cache.remove(key)" to return a non-null value. But that is not the case, the return value of "cache.remove(key)" is non-null for more than one thread. In that sense, "cache.remove(key)" seems to behave differently from "cache.remove(key, value)". The bug can be reproduced by using a test analogous to the one in "DummyTxTest" (ISPN-2077), but using "cache.remove(key)" instead of "cache.remove(key, value)". -- 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

12 years, 3 months

4
14
0 / 0

[JBoss JIRA] (ISPN-1785) BatchingInterceptor is trying to resume a transaction that is in prepared state

by Luciano Leggieri (JIRA)

Luciano Leggieri created ISPN-1785: -------------------------------------- Summary: BatchingInterceptor is trying to resume a transaction that is in prepared state Key: ISPN-1785 URL: https://issues.jboss.org/browse/ISPN-1785 Project: Infinispan Issue Type: Bug Components: Core API Affects Versions: 5.1.0.FINAL Environment: Happens on Mac and Windows, with Java 6 and Java 7. The project uses Spring 3.1, Hibernate 4.0.1 through JPA 2, Apache Derby 10.8 as XADatasource, ActiveMQ JMS 5.1 as XA, Atomikos JTA version 3.7, Hibernate Search 4.0.0, Infinispan 5.1 Final is also enlisted as XA, it's used for Hibernate's second level cache, and as Lucene Directory for Hibernate Search. Reporter: Luciano Leggieri Assignee: Manik Surtani Priority: Minor When the Spring AppContext starts, the EntityManager bean initializes, which inits Hibernate Search, and this one inits Infinispan's Lucene Directory. The Directory initializes Lucene Index and closes it. In this moment, org.infinispan.batch.BatchContainer ends the batch, which was running a micro transactions, so it commits the transaction. The JTA sends a Prepare message to Infinispan XA. org.infinispan.interceptors.BatchingInterceptor receives the Prepare command and checks if there is an ongoing transaction. The transactionManager returns null because the transaction is not active but in prepare phase, so the BatchingInterceptor believes that the transaction is suspended and tries to resume it. Exception does not seem to happen if Infinispan uses JTA synchronization instead of XAresource, although in that case there is no recovery. Here is the stack trace: 10:01:51,964 ERROR TransactionCoordinator:154 - Error while processing prepare java.lang.IllegalStateException: Transaction no longer active at com.atomikos.icatch.imp.TxTerminatedStateHandler.addSubTxAwareParticipant(TxTerminatedStateHandler.java:95) at com.atomikos.icatch.imp.CompositeTransactionImp.addSubTxAwareParticipant(CompositeTransactionImp.java:260) at com.atomikos.icatch.imp.BaseTransactionManager.restoreThreadMappings(BaseTransactionManager.java:168) at com.atomikos.icatch.imp.BaseTransactionManager.resume(BaseTransactionManager.java:393) at com.atomikos.icatch.jta.TransactionManagerImp.resume(TransactionManagerImp.java:399) at com.atomikos.icatch.jta.UserTransactionManager.resume(UserTransactionManager.java:204) at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:54) at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:113) at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:131) at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:345) at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:140) at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:122) at org.infinispan.transaction.xa.TransactionXaAdapter.commit(TransactionXaAdapter.java:122) at com.atomikos.datasource.xa.XAResourceTransaction.commit(XAResourceTransaction.java:784) at com.atomikos.icatch.imp.CommitMessage.send(CommitMessage.java:73) at com.atomikos.icatch.imp.PropagationMessage.submit(PropagationMessage.java:111) at com.atomikos.icatch.imp.Propagator$PropagatorThread.run(Propagator.java:87) at com.atomikos.icatch.imp.Propagator.submitPropagationMessage(Propagator.java:66) at com.atomikos.icatch.imp.CoordinatorStateHandler.commit(CoordinatorStateHandler.java:614) at com.atomikos.icatch.imp.ActiveStateHandler.commit(ActiveStateHandler.java:289) at com.atomikos.icatch.imp.CoordinatorImp.commit(CoordinatorImp.java:863) at com.atomikos.icatch.imp.CoordinatorImp.terminate(CoordinatorImp.java:1157) at com.atomikos.icatch.imp.CompositeTerminatorImp.commit(CompositeTerminatorImp.java:92) at com.atomikos.icatch.jta.TransactionImp.commit(TransactionImp.java:236) at com.atomikos.icatch.jta.TransactionManagerImp.commit(TransactionManagerImp.java:464) at com.atomikos.icatch.jta.UserTransactionManager.commit(UserTransactionManager.java:175) at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:123) at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:105) at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:86) at org.infinispan.CacheImpl.endBatch(CacheImpl.java:577) at org.infinispan.lucene.InfinispanIndexOutput.close(InfinispanIndexOutput.java:211) at org.apache.lucene.store.ChecksumIndexOutput.close(ChecksumIndexOutput.java:61) at org.apache.lucene.index.SegmentInfos.finishCommit(SegmentInfos.java:901) at org.apache.lucene.index.IndexWriter.finishCommit(IndexWriter.java:3516) at org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:3506) at org.apache.lucene.index.IndexWriter.closeInternal(IndexWriter.java:1882) at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1825) at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1789) at org.hibernate.search.store.impl.DirectoryProviderHelper.initializeIndexIfNeeded(DirectoryProviderHelper.java:160) at org.hibernate.search.infinispan.impl.InfinispanDirectoryProvider.start(InfinispanDirectoryProvider.java:88) at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.initialize(DirectoryBasedIndexManager.java:93) at org.hibernate.search.indexes.impl.IndexManagerHolder.createDirectoryManager(IndexManagerHolder.java:193) at org.hibernate.search.indexes.impl.IndexManagerHolder.buildEntityIndexBinding(IndexManagerHolder.java:113) at org.hibernate.search.spi.SearchFactoryBuilder.initDocumentBuilders(SearchFactoryBuilder.java:373) at org.hibernate.search.spi.SearchFactoryBuilder.buildNewSearchFactory(SearchFactoryBuilder.java:224) at org.hibernate.search.spi.SearchFactoryBuilder.buildSearchFactory(SearchFactoryBuilder.java:142) at org.hibernate.search.event.impl.FullTextIndexEventListener.initialize(FullTextIndexEventListener.java:129) at org.hibernate.search.hcore.impl.HibernateSearchIntegrator.integrate(HibernateSearchIntegrator.java:82) at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:294) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1737) at org.hibernate.ejb.EntityManagerFactoryImpl.<init>(EntityManagerFactoryImpl.java:84) at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:904) at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:889) at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:73) at org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:257) at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:310) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1514) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1452) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:294) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:225) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:291) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193) at org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor.findDefaultEntityManagerFactory(PersistenceAnnotationBeanPostProcessor.java:530) at org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor.findEntityManagerFactory(PersistenceAnnotationBeanPostProcessor.java:496) at org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor$PersistenceElement.resolveEntityManager(PersistenceAnnotationBeanPostProcessor.java:657) at org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor$PersistenceElement.getResourceToInject(PersistenceAnnotationBeanPostProcessor.java:630) at org.springframework.beans.factory.annotation.InjectionMetadata$InjectedElement.inject(InjectionMetadata.java:150) at org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:87) at org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor.postProcessPropertyValues(PersistenceAnnotationBeanPostProcessor.java:339) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1106) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:517) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:294) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:225) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:291) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:585) at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:913) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:464) at org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:384) at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:283) at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:111) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4521) at org.apache.catalina.core.StandardContext$1.call(StandardContext.java:5004) at org.apache.catalina.core.StandardContext$1.call(StandardContext.java:4999) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:680) -- 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

12 years, 3 months

6
11
0 / 0

[JBoss JIRA] (ISPN-2086) Allow for event listeners to track entries moving in/out nodes during state transfer

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-2086: ------------------------------------- Summary: Allow for event listeners to track entries moving in/out nodes during state transfer Key: ISPN-2086 URL: https://issues.jboss.org/browse/ISPN-2086 Project: Infinispan Issue Type: Feature Request Components: Listeners, Querying, State transfer Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 5.2.0.ALPHA1 We need to be able to listen to such events both for REPL and DIST to allow for Infinispan Query to keep indexes in sync with the datacontainer. See also https://community.jboss.org/docs/DOC-18370 -- 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

12 years, 4 months

2
4
0 / 0

[JBoss JIRA] (ISPN-2175) Test methods in org.infinispan.loaders.jdbc.binary.JdbcBinaryCacheStoreVamTest fail randomly: assertNoLocksHeld

by Martin Gencur (JIRA)

Martin Gencur created ISPN-2175: ----------------------------------- Summary: Test methods in org.infinispan.loaders.jdbc.binary.JdbcBinaryCacheStoreVamTest fail randomly: assertNoLocksHeld Key: ISPN-2175 URL: https://issues.jboss.org/browse/ISPN-2175 Project: Infinispan Issue Type: Task Affects Versions: 5.1.6.FINAL (JDG) Reporter: Martin Gencur Assignee: Tristan Tarrant Priority: Minor Examples of these failures can be found at: https://hudson.qa.jboss.com/hudson/view/EDG6/view/EDG-REPORTS-FUNC/job/ed... https://hudson.qa.jboss.com/hudson/view/EDG6/view/EDG-REPORTS-FUNC/job/ed... https://hudson.qa.jboss.com/hudson/view/EDG6/view/EDG-REPORTS-FUNC/job/ed... Each of the stack traces belongs to a different test method. -- 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

12 years, 4 months

5
12
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2012