November 2011 - infinispan-issues

[JBoss JIRA] (ISPN-1544) Use the new Configuration mechanism

by Kevin Pollet (Created) (JIRA)

Use the new Configuration mechanism ----------------------------------- Key: ISPN-1544 URL: https://issues.jboss.org/browse/ISPN-1544 Project: Infinispan Issue Type: Task Components: CDI integration Reporter: Kevin Pollet Assignee: Kevin Pollet Fix For: 5.1.0.CR1 -- 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, 9 months

4
3
0 / 0

[JBoss JIRA] Created: (ISPN-1065) Use a better mechanism to parse config files

by Manik Surtani (JIRA)

Use a better mechanism to parse config files -------------------------------------------- Key: ISPN-1065 URL: https://issues.jboss.org/browse/ISPN-1065 Project: Infinispan Issue Type: Enhancement Components: Configuration Affects Versions: 4.2.1.FINAL Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.1.0.BETA1, 5.1.0.Final The current codebase heavily relies on JAXB to: 1. Generate a XSD schema from a Configuration bean 2. Generate a parser to use with an XML configuration This is known to be slow, and can significantly add to start up time: {quote} We did some analysis of our AS6 descriptor code which was using JAXB (800ms), compared to straight stax (10ms) {quote} A possible solution could be to still use JAXB to generate the schema, but to also write a Maven plugin which would generate a STAX parser based on the XSD schema and Configuration bean at build time. Infinispan would then use this STAX parser rather than a JAXB generated parser, which would be a lot faster. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

8
24
0 / 0

[JBoss JIRA] (ISPN-1565) Hot Rod client connection timeout

by Michal Linhard (Created) (JIRA)

Hot Rod client connection timeout --------------------------------- Key: ISPN-1565 URL: https://issues.jboss.org/browse/ISPN-1565 Project: Infinispan Issue Type: Feature Request Affects Versions: 5.1.0.BETA5 Reporter: Michal Linhard Assignee: Manik Surtani Currently it's only possible to specify socket timeout that applies for reading from the socket. -- 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, 9 months

6
6
0 / 0

[JBoss JIRA] (ISPN-1519) Stale locks on adding a new node to a cluster

by Erik Salter (Created) (JIRA)

Stale locks on adding a new node to a cluster --------------------------------------------- Key: ISPN-1519 URL: https://issues.jboss.org/browse/ISPN-1519 Project: Infinispan Issue Type: Bug Components: Locking and Concurrency Affects Versions: 5.0.1.FINAL Reporter: Erik Salter Assignee: Manik Surtani There is an issue with stale locks when a new node joins a running cluster. There are three caches all using eagerLockSingleNode=true with the transaction running on the primary data owner. The local locks for the affected keys are acquired, and the prepare is sent to the backup owner. During this time, the new node is detected and joins the cluster. The transaction times out waiting for the transaction lock, and a rollback is attempted. Whereas the local keys are unlocked, the remotely-acquired locks never release. I have full trace log files at: http://dl.dropbox.com/u/10929737/5.0.1-stale-lock/data-grid-4/server.log.... http://dl.dropbox.com/u/10929737/5.0.1-stale-lock/data-grid-4/server.log.... http://dl.dropbox.com/u/10929737/5.0.1-stale-lock/data-grid-5/server.log.... The transaction in question is GlobalTransaction:<data-grid-4-61247>:169901, found on data-grid-4. I have verified that the primary owner of the keys in question are on data-grid-4. -- 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, 9 months

6
10
0 / 0

[JBoss JIRA] Created: (ISPN-1399) Jandex index file containing old removed classes

by Galder Zamarreño (JIRA)

Jandex index file containing old removed classes ------------------------------------------------ Key: ISPN-1399 URL: https://issues.jboss.org/browse/ISPN-1399 Project: Infinispan Issue Type: Bug Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.1.0.BETA1 With ISPN-1194 in, running TransportSenderExceptionHandlingTest shows the following in the logs. As a result of ISPN-1194, StateTransferManagerImpl has been removed but it's still being indexed. Looking at infinispan-core-jandex.idx, StateTransferManagerImpl is still present but this is a file in the src/main/resources. Shouldn't this be generated? We're not gonna remember to manually generate it when a component is removed :) {code}2011-09-20 16:21:19,781 FATAL [AnnotatedMethodCache] (main) Caught exception scanning annotations on void org.infinispan.statetransfer.StateTransferManagerImpl.injectDependencies(org.infinispan.remoting.rpc.RpcManager, org.infinispan.AdvancedCache, org.infinispan.config.Configuration, org.infinispan.container.DataContainer, org.infinispan.loaders.CacheLoaderManager, org.infinispan.marshall.StreamingMarshaller, org.infinispan.transaction.TransactionLog, org.infinispan.interceptors.InterceptorChain, org.infinispan.context.InvocationContextContainer, org.infinispan.commands.CommandsFactory, org.infinispan.transaction.TransactionTable) java.lang.ClassNotFoundException: org.infinispan.statetransfer.StateTransferManagerImpl at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at org.infinispan.util.reflect.CachedMethod.<init>(CachedMethod.java:52) at org.infinispan.util.reflect.AnnotatedMethodCache.collectAndCacheMethodAnnotations(AnnotatedMethodCache.java:121) at org.infinispan.util.reflect.AnnotatedMethodCache.<clinit>(AnnotatedMethodCache.java:86) at org.infinispan.factories.AbstractComponentRegistry.addComponentDependencies(AbstractComponentRegistry.java:208) at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:192) at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:154) at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:149) at org.infinispan.factories.AbstractComponentRegistry.registerDefaultClassLoader(AbstractComponentRegistry.java:439) at org.infinispan.factories.GlobalComponentRegistry.<init>(GlobalComponentRegistry.java:93) at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:223) at org.infinispan.test.fwk.TestCacheManagerFactory.newDefaultCacheManager(TestCacheManagerFactory.java:376) at org.infinispan.test.fwk.TestCacheManagerFactory.newDefaultCacheManager(TestCacheManagerFactory.java:73) at org.infinispan.test.fwk.TestCacheManagerFactory.createClusteredCacheManager(TestCacheManagerFactory.java:171) at org.infinispan.test.fwk.TestCacheManagerFactory.createClusteredCacheManager(TestCacheManagerFactory.java:151) at org.infinispan.test.MultipleCacheManagersTest.addClusterEnabledCacheManager(MultipleCacheManagersTest.java:168) at org.infinispan.test.MultipleCacheManagersTest.createClusteredCaches(MultipleCacheManagersTest.java:298) at org.infinispan.test.MultipleCacheManagersTest.createClusteredCaches(MultipleCacheManagersTest.java:291) at org.infinispan.remoting.TransportSenderExceptionHandlingTest.createCacheManagers(TransportSenderExceptionHandlingTest.java:52) at org.infinispan.test.MultipleCacheManagersTest.callCreateCacheManagers(MultipleCacheManagersTest.java:89) at org.infinispan.test.MultipleCacheManagersTest.createBeforeClass(MultipleCacheManagersTest.java:83) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:644) at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:443) at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:160) at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:90) at org.testng.internal.TestMethodWorker.invokeBeforeClassMethods(TestMethodWorker.java:183) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:115) at org.testng.TestRunner.runWorkers(TestRunner.java:909) at org.testng.TestRunner.privateRun(TestRunner.java:618) at org.testng.TestRunner.run(TestRunner.java:499) at org.testng.SuiteRunner.runTest(SuiteRunner.java:332) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:327) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:299) at org.testng.SuiteRunner.run(SuiteRunner.java:204) at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:915) at org.testng.TestNG.runSuitesLocally(TestNG.java:879) at org.testng.TestNG.run(TestNG.java:787) at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:73) at org.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.java:101){code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

7
10
0 / 0

[JBoss JIRA] (ISPN-1438) AnnotatedMethodCache.getCachedMethods() returns duplicates

by Dan Berindei (Created) (JIRA)

AnnotatedMethodCache.getCachedMethods() returns duplicates ---------------------------------------------------------- Key: ISPN-1438 URL: https://issues.jboss.org/browse/ISPN-1438 Project: Infinispan Issue Type: Bug Components: Core API Affects Versions: 5.1.0.BETA1 Reporter: Dan Berindei Assignee: Manik Surtani For some components (e.g. GlobalConfiguration) I see AnnotatedMethodCache.getCachedMethods() returning the same @Inject method twice. -- 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, 9 months

4
7
0 / 0

[JBoss JIRA] (ISPN-1556) Ablity to test and acquire lock if available, without aborting the txn if not available

by Gary Brown (Created) (JIRA)

Ablity to test and acquire lock if available, without aborting the txn if not available --------------------------------------------------------------------------------------- Key: ISPN-1556 URL: https://issues.jboss.org/browse/ISPN-1556 Project: Infinispan Issue Type: Feature Request Affects Versions: 5.1.0.BETA2 Environment: AS7.1.0.alpha2 Reporter: Gary Brown Assignee: Manik Surtani I have a system that performs a large number of tasks in a single transaction for efficiency. Some of those tasks access infinispan caches. I found that occasionally I have been getting lock timeouts for the default 15 second period. Lock contention is not a problem - but the impact of failing to obtain the lock results in the whole transaction being aborted, which aborts the work also carried out for potentially a large number of other tasks, resulting in all of the work being retried. I was wondering if it would be possible to provide an alternative lock implementation the AdvancedCache that allowed a client app to test whether the lock was available and acquire it - returning 'true', but if the lock was not available, simply returning false, allowing the client code to make a decision about how to proceed. In my case, I could then add the specific task to a retry queue, and move onto the next task, committing all of the work that had been successfully completed for the other tasks. -- 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, 9 months

10
22
0 / 0

[JBoss JIRA] Created: (ISPN-385) Add idle timeout to memcached and hot rod servers.

by Galder Zamarreno (JIRA)

Add idle timeout to memcached and hot rod servers. -------------------------------------------------- Key: ISPN-385 URL: https://jira.jboss.org/jira/browse/ISPN-385 Project: Infinispan Issue Type: Task Components: Cache Server Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.1.0.BETA1 Add an IdleStateHandler to memcached and hot rod servers so that idle connections can be closed automatically. This is necessary to handle error conditions such as cases where clients erroneously indicate the server that it needs to read 20 bytes but they only send 10 bytes. Without such handler, the server will carry on waiting for bytes forever. The handler will provide a defence mechanism for such cases. The timeout will be configurable via the command line. Besides, clients wanting to do some connection pooling will require to configure this accordingly in the server. In other words, there's hardly any point in having servers configured with idle timeout of 30 seconds and clients closing connections after 60 seconds of idle time. These two should be aligned accordingly. -- 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

13 years, 9 months

2
5
0 / 0

[JBoss JIRA] (ISPN-1503) NullPointerException in BatchingInterceptor when using nontransactional cache

by Aaron Douglas (Created) (JIRA)

NullPointerException in BatchingInterceptor when using nontransactional cache ----------------------------------------------------------------------------- Key: ISPN-1503 URL: https://issues.jboss.org/browse/ISPN-1503 Project: Infinispan Issue Type: Bug Components: Transactions Affects Versions: 5.1.0.BETA3 Reporter: Aaron Douglas Assignee: Mircea Markus When setting a cache to non-transactional with the following configuration statement: {code:xml} <transaction transactionMode="NON_TRANSACTIONAL" /> {code} I'm getting a NullPointerException in org.infinispan.interceptors.BatchingInterceptor.handleDefault(InvocationContext, VisitableCommand) because there is no transaction manager defined. This is occurring in the fifth line below: {code} protected Object handleDefault(InvocationContext ctx, VisitableCommand command) throws Throwable { Transaction tx; if (!ctx.isOriginLocal()) return invokeNextInterceptor(ctx, command); // if in a batch, attach tx if (transactionManager.getTransaction() == null && (tx = batchContainer.getBatchTransaction()) != null) { try { transactionManager.resume(tx); //If there's no ongoing tx then BatchingInterceptor creates one and then invokes next interceptor, // so that all interceptors in the stack will be executed in a transactional context. // This is where a new context (TxInvocationContext) is created, as the existing context is not transactional: NonTxInvocationContext. InvocationContext txContext = icc.createInvocationContext(true); txContext.setFlags(ctx.getFlags()); return invokeNextInterceptor(txContext, command); } finally { if (transactionManager.getTransaction() != null && batchContainer.isSuspendTxAfterInvocation()) transactionManager.suspend(); } } else { return invokeNextInterceptor(ctx, command); } } {code} And the stacktrace: {noformat} Caused by: java.lang.NullPointerException at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:63) [infinispan-core-5.1.0.BETA3.jar:] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:95) [infinispan-core-5.1.0.BETA3.jar:] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:61) [infinispan-core-5.1.0.BETA3.jar:] at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:318) [infinispan-core-5.1.0.BETA3.jar:] at org.infinispan.CacheImpl.get(CacheImpl.java:262) [infinispan-core-5.1.0.BETA3.jar:] at org.infinispan.DecoratedCache.get(DecoratedCache.java:292) [infinispan-core-5.1.0.BETA3.jar:] at org.infinispan.lucene.FileListOperations.getFileList(FileListOperations.java:55) [infinispan-lucene-directory-5.1.0.BETA3.jar:] at org.infinispan.lucene.InfinispanDirectory.list(InfinispanDirectory.java:183) [infinispan-lucene-directory-5.1.0.BETA3.jar:] at org.infinispan.lucene.InfinispanDirectory.listAll(InfinispanDirectory.java:338) [infinispan-lucene-directory-5.1.0.BETA3.jar:] at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:623) [lucene-core-3.1.0.jar:] at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:575) [lucene-core-3.1.0.jar:] at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:346) [lucene-core-3.1.0.jar:] at org.apache.lucene.index.IndexReader.indexExists(IndexReader.java:808) [lucene-core-3.1.0.jar:] at org.hibernate.search.store.DirectoryProviderHelper.initializeIndexIfNeeded(DirectoryProviderHelper.java:157) [hibernate-search-3.4.1.Final.jar:] at org.hibernate.search.infinispan.InfinispanDirectoryProvider.start(InfinispanDirectoryProvider.java:88) [hibernate-search-infinispan-3.4.1.Final.jar:] at org.hibernate.search.store.DirectoryProviderFactory.startDirectoryProviders(DirectoryProviderFactory.java:144) [hibernate-search-3.4.1.Final.jar:] at org.hibernate.search.spi.SearchFactoryBuilder.initDocumentBuilders(SearchFactoryBuilder.java:403) [hibernate-search-3.4.1.Final.jar:] at org.hibernate.search.spi.SearchFactoryBuilder.buildNewSearchFactory(SearchFactoryBuilder.java:262) [hibernate-search-3.4.1.Final.jar:] at org.hibernate.search.spi.SearchFactoryBuilder.buildSearchFactory(SearchFactoryBuilder.java:144) [hibernate-search-3.4.1.Final.jar:] at org.hibernate.search.event.FullTextIndexEventListener.initialize(FullTextIndexEventListener.java:151) [hibernate-search-3.4.1.Final.jar:] at org.hibernate.event.EventListeners$1.processListener(EventListeners.java:198) [hibernate-core-3.6.6.Final.jar:] at org.hibernate.event.EventListeners.processListeners(EventListeners.java:181) [hibernate-core-3.6.6.Final.jar:] at org.hibernate.event.EventListeners.initializeListeners(EventListeners.java:194) [hibernate-core-3.6.6.Final.jar:] ... 40 more {noformat} -- 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

5
8
0 / 0

[JBoss JIRA] (ISPN-1562) Alternative needed for Cache.getConfiguration()

by Galder Zamarreño (Created) (JIRA)

Alternative needed for Cache.getConfiguration() ----------------------------------------------- Key: ISPN-1562 URL: https://issues.jboss.org/browse/ISPN-1562 Project: Infinispan Issue Type: Bug Components: Configuration, Core API Affects Versions: 5.1.0.BETA5 Reporter: Galder Zamarreño Assignee: Pete Muir Fix For: 5.1.0.CR1 Provide an alternative way of retrieving a Cache's configuration instead of deprecated Cache.getConfiguration() -- 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

5
5
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2011