September 2011 - infinispan-issues

[JBoss JIRA] Created: (ISPN-1389) Add ability to specify custom ExecutorFactory impls to RemoteCacheManager and via RemoteCacheStoreConfig

by Paul Ferraro (JIRA)

Add ability to specify custom ExecutorFactory impls to RemoteCacheManager and via RemoteCacheStoreConfig -------------------------------------------------------------------------------------------------------- Key: ISPN-1389 URL: https://issues.jboss.org/browse/ISPN-1389 Project: Infinispan Issue Type: Feature Request Components: Loaders and Stores Affects Versions: 5.1.0.ALPHA1 Reporter: Paul Ferraro Assignee: Manik Surtani The RemoteCacheManager/RemoteCache use 2 separate thread pools. In order to fully manage these threads in AS7, both when used directly, and via a remote cache store, we need a mechanism to supply custom ExecutorFactory implementations, similar to the mechanisms in GlobalConfiguration. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

3
5
0 / 0

[JBoss JIRA] Created: (ISPN-1398) Review Rsp.getValue usage

by Galder Zamarreño (JIRA)

Review Rsp.getValue usage ------------------------- Key: ISPN-1398 URL: https://issues.jboss.org/browse/ISPN-1398 Project: Infinispan Issue Type: Task Components: RPC Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.1.0.BETA1 With JGroups 3.0, Rsp.getValue() can return null if an exception was received. Rsp comes with two methods, hasException() and getException() to get the actual exception. Usage of Rsp.getValue() in Infinispan needs to be investigated to make sure the exception is propagated back. At first glance, TransportSenderExceptionHandlingTest is working fine... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

2
3
0 / 0

[JBoss JIRA] Created: (ISPN-1412) TEST_PING should be protected against paralel cache manager startups

by Galder Zamarreño (JIRA)

TEST_PING should be protected against paralel cache manager startups -------------------------------------------------------------------- Key: ISPN-1412 URL: https://issues.jboss.org/browse/ISPN-1412 Project: Infinispan Issue Type: Bug Components: Test Suite Affects Versions: 5.1.0.ALPHA2 , 5.0.1.FINAL Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.1.0.BETA1, 5.1.0.FINAL Attachments: stfclft.log When a test creates two cache managers in paralell (i.e. - StateTransferFileCacheLoaderFunctionalTest.testConcurrentStateTransfer) TEST_PING can break with: {code}Caused by: java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(HashMap.java:810) at java.util.HashMap$ValueIterator.next(HashMap.java:839) at org.infinispan.test.fwk.TEST_PING.findMembers(TEST_PING.java:74) at org.jgroups.protocols.Discovery.findInitialMembers(Discovery.java:185) at org.jgroups.protocols.Discovery.down(Discovery.java:467) at org.jgroups.protocols.pbcast.NAKACK.down(NAKACK.java:593) at org.jgroups.protocols.UNICAST.down(UNICAST.java:432) at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:329) at org.jgroups.protocols.pbcast.ClientGmsImpl.findInitialMembers(ClientGmsImpl.java:207) at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:73) at org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:38) at org.jgroups.protocols.pbcast.GMS.down(GMS.java:912) at org.jgroups.protocols.FC.down(FC.java:435) at org.jgroups.protocols.FRAG2.down(FRAG2.java:147) at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1033) at org.jgroups.JChannel.down(JChannel.java:734) at org.jgroups.JChannel.connect(JChannel.java:296) ... 21 more{code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

2
4
0 / 0

[JBoss JIRA] Created: (ISPN-1204) Allow to be DB schema independent

by Nicolas Filotto (JIRA)

Allow to be DB schema independent --------------------------------- Key: ISPN-1204 URL: https://issues.jboss.org/browse/ISPN-1204 Project: Infinispan Issue Type: Enhancement Components: Loaders and Stores Reporter: Nicolas Filotto Assignee: Manik Surtani The current code checks if a table exists thanks to con.getMetaData().getTables(...) which is totally DB schema dependent, your code allow us to specify the schema by prefixing the table name with the name of the schema in the config which is not really convenient in practice especially if we have a lot of config files. You could easily make your code fully DB schema independent by replacing the method org.infinispan.loaders.jdbc.TableManipulation.tableExists(Connection connection, String tableName) with this content: {code} public boolean tableExists(Connection connection, String tableName) { assertNotNull(getTableName(), "table name is mandatory"); Statement stmt = null; ResultSet trs = null; try { stmt = connection.createStatement(); trs = stmt.executeQuery("SELECT count(*) FROM " + tableName); return trs.next(); } catch (SQLException e) { if (log.isTraceEnabled()) { log.trace("SQLException occurs while checking the table " + tableName, e); } return false; } finally { JdbcUtil.safeClose(trs); JdbcUtil.safeClose(stmt); } } {code} I know that it is a much less elegant and standard approach but it allows to simplify so much the config that I think that it makes sense to at least think about at it more than one second. Be free to resolve it as won't fix if you don't find it relevant. FYI: We use the same approach in our product (EXOJCR-1374) with JBC and we successfully tested it on Oracle, MySQL, MS SQL, PostgreSQL, DB2 and Sybase -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

3
12
0 / 0

[JBoss JIRA] Created: (ISPN-1416) Refactor CacheStore SPI to take in an InvocationContext with each method

by Manik Surtani (JIRA)

Refactor CacheStore SPI to take in an InvocationContext with each method ------------------------------------------------------------------------ Key: ISPN-1416 URL: https://issues.jboss.org/browse/ISPN-1416 Project: Infinispan Issue Type: Feature Request Components: Loaders and Stores Affects Versions: 5.0.0.FINAL Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 6.0.0.FINAL The current CacheLoader and CacheStore SPI doesn't propagate the InvocationContext to the implementation. This means implementations that need information from the InvocationContext can only get a handle on the context via a ThreadLocal, and this leads to performance issues. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

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

by Galder Zamarreño (JIRA)

Use UNICAST2 instead of UNICAST ------------------------------- Key: ISPN-1392 URL: https://issues.jboss.org/browse/ISPN-1392 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, 3 months

2
1
0 / 0

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

by Galder Zamarreño (JIRA)

Jandex index file containing old removed classes ------------------------------------------------ Key: ISPN-1400 URL: https://issues.jboss.org/browse/ISPN-1400 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, 3 months

2
2
0 / 0

[JBoss JIRA] Created: (ISPN-1413) CacheManager per application to provide "Session style" construct

by Pete Muir (JIRA)

CacheManager per application to provide "Session style" construct ----------------------------------------------------------------- Key: ISPN-1413 URL: https://issues.jboss.org/browse/ISPN-1413 Project: Infinispan Issue Type: Feature Request Reporter: Pete Muir Assignee: Manik Surtani Fix For: 6.0.0.FINAL This solves a problem with classloading, as Infinispan will know exactly what classloader to use for a cache manager and any deserialized cached objects, events etc. However, it does require support for asymmetric clusters. Open issues are: * how do we handle EARs * how do we handle shared 2nd level caches * needs support for asymmetric clusters * needs to mux JGroups channels * needs consideration of how to handle shared thread pools -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
1
0 / 0

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

by Manik Surtani (JIRA)

[ https://issues.jboss.org/browse/ISPN-61?page=com.atlassian.jira.plugin.sy... ] Manik Surtani updated ISPN-61: ------------------------------ Fix Version/s: 5.1.0.BETA1 (was: 5.1.0.ALPHA2 ) > 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.BETA1, 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. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (ISPN-448) Consider all topology cache updates to be done by coordinator in Hot Rod

by Galder Zamarreno (JIRA)

Consider all topology cache updates to be done by coordinator in Hot Rod ------------------------------------------------------------------------ Key: ISPN-448 URL: https://jira.jboss.org/browse/ISPN-448 Project: Infinispan Issue Type: Task Components: Cache Server Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 5.0.0.BETA1 Based on the discussion below, consider all topology cache updates to be done by coordinator to avoid concurrency issues when updating it. > Looks good. > What is causing this unsuccessful add? If it is caused by timeouts due > to multiple caches operating on the same key an alternative would be > to only perform the operation on the coordinator and rest of the > members to have node added listeners ... Currently, each node when it starts, it's responsible of adding itself to the view and when it stops, it's responsible from removing itself. Apart from this, there's a crashed member listener running only in coordinator that detects whether any member left without updating the topology view. Your suggestion to have the coordinator control it all seems like could work and get around potential timeouts. I'll create a JIRA to investigate this but won't do it for CR1 since I'm expect this to be a major issue. Metadata size is small and it's not constantly uddated. -- 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

13 years, 3 months

4
7
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2011