November 2016 - infinispan-issues

[JBoss JIRA] (ISPN-7176) (7.0.z) Move common parser methods to an unversioned class so they can be used by external modules

by Brad Maxwell (JIRA)

Brad Maxwell created ISPN-7176: ---------------------------------- Summary: (7.0.z) Move common parser methods to an unversioned class so they can be used by external modules Key: ISPN-7176 URL: https://issues.jboss.org/browse/ISPN-7176 Project: Infinispan Issue Type: Task Components: Configuration Affects Versions: 8.1.4.Final, 8.2.2.Final Reporter: Brad Maxwell Assignee: Tristan Tarrant Fix For: 8.1.5.Final, 8.2.3.Final Before Infinispan 9, parsers were versioned forcing external modules (such as cachestores) to depend on a specific version. We should move these methods to a "Parser" class to remove this limitation -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-19) JBoss logging should match Hot Rod client

by Gustavo Fernandes (JIRA)

Gustavo Fernandes created IPROTO-19: --------------------------------------- Summary: JBoss logging should match Hot Rod client Key: IPROTO-19 URL: https://issues.jboss.org/browse/IPROTO-19 Project: Infinispan ProtoStream Issue Type: Bug Affects Versions: 3.0.5.Final Reporter: Gustavo Fernandes Infinispan depends on protostream and jboss-logging, and protostream depends on jboss logging as well. It'd be better for the jboss-logging dependency to align between Infinispan and Protostream to avoid issues such as https://issues.jboss.org/browse/ISPRK-33: Infinispan 9.0.0.Alpha4 depends on logging 3.3.0.Final and Protostream 3.0.5, but Protostream 3.0.5 depends on jboss-logging-3.1.4.GA -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPRK-33) Wrong dependency of jboss-logging pulled

by Gustavo Fernandes (JIRA)

Gustavo Fernandes created ISPRK-33: -------------------------------------- Summary: Wrong dependency of jboss-logging pulled Key: ISPRK-33 URL: https://issues.jboss.org/browse/ISPRK-33 Project: Infinispan Spark Issue Type: Bug Affects Versions: 0.4 Reporter: Gustavo Fernandes Fix For: 0.5 Consider the pom snippet: {code:xml} <dependency> <groupId>org.infinispan</groupId> <artifactId>infinispan-spark_2.11</artifactId> <version>${version.spark-connector}</version> </dependency> <dependency> <groupId>org.apache.spark</groupId> <artifactId>spark-core_2.11</artifactId> <version>${version.spark}</version> <scope>provided</scope> </dependency> {code} It will pull org.jboss.logging:jboss-logging:jar:3.1.4.GA on classpath via org.infinispan.protostream:protostream. But org.jboss.logging:jboss-logging:jar:3.1.4.GA is not compatible with the Hot Rod client and causes errors such as {code} java.lang.NoSuchMethodError: org.infinispan.client.hotrod.logging.Log.tracef(Ljava/lang/Throwable;Ljava/lang/String;II)V {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7171) LIRS eviction strategy leaks without cache hits

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-7171?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-7171: ------------------------------------- Sorry I forgot to link it to the issue when I closed, it is https://issues.jboss.org/browse/ISPN-6998 > LIRS eviction strategy leaks without cache hits > ----------------------------------------------- > > Key: ISPN-7171 > URL: https://issues.jboss.org/browse/ISPN-7171 > Project: Infinispan > Issue Type: Bug > Affects Versions: 8.2.4.Final > Reporter: Ryan Gustafson > Attachments: BoundedInfinispanCacheTest.java > > > When using a size bounded cache with the LIRS eviction strategy and there are no cache hits, the cache will leak until OOM is triggered. This makes LIRS a risky choice for a bounded cache in which a large number of puts can occur before the arrival of a subsequent cache hit. At worst the application can go OOM, and at best it keeps working but suffers from randomly excessive heap usage. > See attached JUnit test class. There are 5 cases in the test: > # A size bounded cache using LRU with only puts does not leak. PASSES > # A size bounded cache using LIRS with only puts does leak. FAILS > # A size bounded cache using LIRS with intermittent cache hits does not leak. PASSES > # A size bounded cache using LIRS with intermittent cache misses does leak. FAILS > # A size bounded cache using LIRS with a single cache hit and subsequent intermittent cache misses does leak. FAILS > The test was written assuming Java 8 and Infinispan 8.2.4. It should be run using the -Xmx64m JVM argument to limit heap size. Each test method should be run separately. The FAILING tests will throw OOME or have very slow progress with excessive garbage collection. The PASSING tests will run quickly through 1,000,000 cache puts. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7175) Do not require a trust store for the HotRod server configuration builder

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-7175: ------------------------------------- Summary: Do not require a trust store for the HotRod server configuration builder Key: ISPN-7175 URL: https://issues.jboss.org/browse/ISPN-7175 Project: Infinispan Issue Type: Bug Components: Security, Server Affects Versions: 9.0.0.Alpha4 Reporter: Tristan Tarrant Assignee: Tristan Tarrant Fix For: 9.0.0.Final A trust store is not a requirement for the server SSL configurtion, but the validation currently expects it to be. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5021) Nodes that finish the rebalance later can see outdated values

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-5021?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-5021: ----------------------------------- I intend to work on this issue, moving from two-phase to four-phase topology change (after ISPN-6938 and ISPN-7029 get integrated). I want to guarantee these properties when the topology is changing: 1. T(x+1).writeCH contains all nodes from Tx.readCH (this is the requirement to prevent the outdated values) 2. Tx.readCH and T(x+1).readCH has non-empty subset of nodes (that will allow no blocking for read commands && reading only entries node owns according to readCH) Therefore, there will be these topologies: * T0: readCH=old, writeCH=old * T1: readCH=old, writeCH=old+new * T2: readCH=old+new, writeCH=old+new * T3: readCH=new, writeCH=old+new * T4: readCH=new, writeCH=new > Nodes that finish the rebalance later can see outdated values > ------------------------------------------------------------- > > Key: ISPN-5021 > URL: https://issues.jboss.org/browse/ISPN-5021 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 7.0.2.Final > Reporter: Dan Berindei > Assignee: Pedro Ruivo > Priority: Critical > Labels: testsuite_stability > > Copied from [ISPN-4444|https://issues.jboss.org/browse/ISPN-4444?focusedCommentId=1302...] > If the CH_UPDATE command is delayed on the old owner, the new owners might update the key without the old owner knowing, and a locality check on the old owner won't help. > I remember one thing that struck me when reading the Raft algorithm was that they install configuration changes symmetrically, in 3 phases. We might need to do the same for our rebalance: > 1. T0: read_ch=old, write_ch=old > 2. start a rebalance > 3. T1: read_ch=old, write_ch=old+new > 4. new owners have all the data > 5. T2: read_ch=new, write_ch=old+new > 6. remove old cache entries and ignore further writes > 7. T3: read_ch=new, write_ch=new -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7171) LIRS eviction strategy leaks without cache hits

by Ryan Gustafson (JIRA)

[ https://issues.jboss.org/browse/ISPN-7171?page=com.atlassian.jira.plugin.... ] Ryan Gustafson commented on ISPN-7171: -------------------------------------- Thank you for the detailed response. In researching the leak, I read this Caffeine issue thread https://github.com/ben-manes/caffeine/issues/23, and from there the TinyLFU paper you referenced. Whether TinyLFU was already, or would be, incorporated into Infinispan wasn't clear to me. Glad to hear it's slated for 9.0. I'll re-evaluate the eviction strategies in the future, sticking to LRU for now. Can you link this issue to the 9.0 issue with the new feature? I'd like to keep an eye on progress. > LIRS eviction strategy leaks without cache hits > ----------------------------------------------- > > Key: ISPN-7171 > URL: https://issues.jboss.org/browse/ISPN-7171 > Project: Infinispan > Issue Type: Bug > Affects Versions: 8.2.4.Final > Reporter: Ryan Gustafson > Attachments: BoundedInfinispanCacheTest.java > > > When using a size bounded cache with the LIRS eviction strategy and there are no cache hits, the cache will leak until OOM is triggered. This makes LIRS a risky choice for a bounded cache in which a large number of puts can occur before the arrival of a subsequent cache hit. At worst the application can go OOM, and at best it keeps working but suffers from randomly excessive heap usage. > See attached JUnit test class. There are 5 cases in the test: > # A size bounded cache using LRU with only puts does not leak. PASSES > # A size bounded cache using LIRS with only puts does leak. FAILS > # A size bounded cache using LIRS with intermittent cache hits does not leak. PASSES > # A size bounded cache using LIRS with intermittent cache misses does leak. FAILS > # A size bounded cache using LIRS with a single cache hit and subsequent intermittent cache misses does leak. FAILS > The test was written assuming Java 8 and Infinispan 8.2.4. It should be run using the -Xmx64m JVM argument to limit heap size. Each test method should be run separately. The FAILING tests will throw OOME or have very slow progress with excessive garbage collection. The PASSING tests will run quickly through 1,000,000 cache puts. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7174) (7.0.z) PutAll operation in the Hot Rod client only partially completed during topology changes

by Brad Maxwell (JIRA)

Brad Maxwell created ISPN-7174: ---------------------------------- Summary: (7.0.z) PutAll operation in the Hot Rod client only partially completed during topology changes Key: ISPN-7174 URL: https://issues.jboss.org/browse/ISPN-7174 Project: Infinispan Issue Type: Bug Components: Server Affects Versions: 8.2.1.Final, 9.0.0.Alpha1 Reporter: Brad Maxwell Assignee: Dan Berindei Fix For: 9.0.0.Alpha2, 8.2.2.Final, 9.0.0.Final -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7173) (7.0.z) TransactionAwareKeyCloseableIterator.remove uses previousValue which is never set

by Brad Maxwell (JIRA)

Brad Maxwell created ISPN-7173: ---------------------------------- Summary: (7.0.z) TransactionAwareKeyCloseableIterator.remove uses previousValue which is never set Key: ISPN-7173 URL: https://issues.jboss.org/browse/ISPN-7173 Project: Infinispan Issue Type: Bug Affects Versions: 8.1.0.Final Reporter: Brad Maxwell Assignee: William Burns Fix For: 9.0.0.Beta1, 8.2.5.Final, 8.1.6.Final TransactionAwareKeyCloseableIterator.remove is implemented as {code:java} cache.remove(previousValue); {code} But looking at the previousValue it never gets set. This results then in {code} java.lang.NullPointerException: Null keys are not supported! at org.infinispan.cache.impl.CacheImpl.assertKeyNotNull(CacheImpl.java:224) at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:547) at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:543) at org.infinispan.interceptors.TxInterceptor$TransactionAwareKeyCloseableIterator.remove(TxInterceptor.java:568) {code} I encountered this when trying to switch infinispan from 7.2 to 8.1 in conjunction with hibernate-infinispan 4.3 which does the following code to clear the cache: {code:java} public static void removeAll(AdvancedCache cache) { try { Iterator it = cache.keySet().iterator(); while (it.hasNext()) { it.next(); // Necessary to get next element it.remove(); } } catch (UnsupportedOperationException e) { // Fallback on using clear for older version cache.clear(); } } {code} from https://github.com/hibernate/hibernate-orm/blob/4.3/hibernate-infinispan/... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6952) JCacheTwoCachesBasicOpsTest.testRemovedListener fails

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6952?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-6952: ------------------------------------ Found another instance where the event is triplicated: {noformat} 17:10:43,985 ERROR (testng-JCacheTwoCachesBasicOpsTest:[]) [TestSuiteProgress] Test failed: org.infinispan.jcache.JCacheTwoCachesBasicOpsTest.testRemovedListener java.lang.AssertionError: expected [1] but found [3] at org.testng.Assert.fail(Assert.java:94) ~[testng-6.8.8.jar:?] at org.testng.Assert.failNotEquals(Assert.java:494) ~[testng-6.8.8.jar:?] at org.testng.Assert.assertEquals(Assert.java:123) ~[testng-6.8.8.jar:?] at org.testng.Assert.assertEquals(Assert.java:370) ~[testng-6.8.8.jar:?] at org.testng.Assert.assertEquals(Assert.java:380) ~[testng-6.8.8.jar:?] at org.infinispan.jcache.AbstractTwoCachesBasicOpsTest.testRemovedListener(AbstractTwoCachesBasicOpsTest.java:306) ~[infinispan-jcache-commons-tests.jar:?] {noformat} > JCacheTwoCachesBasicOpsTest.testRemovedListener fails > ----------------------------------------------------- > > Key: ISPN-6952 > URL: https://issues.jboss.org/browse/ISPN-6952 > Project: Infinispan > Issue Type: Bug > Components: JCache > Reporter: Sebastian Łaskawiec > Assignee: William Burns > Priority: Critical > Attachments: JCacheTwoCachesBasicOpsTest_20161106.log.gz > > > http://ci.infinispan.org/project.html?projectId=Infinispan&testNameId=804... > {noformat} > java.lang.AssertionError: expected [1] but found [2] > at org.testng.Assert.fail(Assert.java:94) > at org.testng.Assert.failNotEquals(Assert.java:494) > at org.testng.Assert.assertEquals(Assert.java:123) > at org.testng.Assert.assertEquals(Assert.java:370) > at org.testng.Assert.assertEquals(Assert.java:380) > at org.infinispan.jcache.AbstractTwoCachesBasicOpsTest.testRemovedListener(AbstractTwoCachesBasicOpsTest.java:302) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:714) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) > at org.testng.TestRunner.privateRun(TestRunner.java:767) > at org.testng.TestRunner.run(TestRunner.java:617) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:348) > at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:343) > at org.testng.SuiteRunner.privateRun(SuiteRunner.java:305) > at org.testng.SuiteRunner.run(SuiteRunner.java:254) > at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) > at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) > at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224) > at org.testng.TestNG.runSuitesLocally(TestNG.java:1149) > at org.testng.TestNG.run(TestNG.java:1057) > at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:115) > at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeMulti(TestNGDirectoryTestSuite.java:205) > at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:108) > at org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:111) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) > ------- Stdout: ------- > [TestSuiteProgress] Test starting: org.infinispan.jcache.JCacheTwoCachesBasicOpsTest.testRemovedListener > [TestSuiteProgress] Test failed: org.infinispan.jcache.JCacheTwoCachesBasicOpsTest.testRemovedListener > 12:50:19,634 ERROR (testng-JCacheTwoCachesBasicOpsTest) [TestSuiteProgress] Test failed: org.infinispan.jcache.JCacheTwoCachesBasicOpsTest.testRemovedListener > java.lang.AssertionError: expected [1] but found [2] > at org.testng.Assert.fail(Assert.java:94) > at org.testng.Assert.failNotEquals(Assert.java:494) > at org.testng.Assert.assertEquals(Assert.java:123) > at org.testng.Assert.assertEquals(Assert.java:370) > at org.testng.Assert.assertEquals(Assert.java:380) > at org.infinispan.jcache.AbstractTwoCachesBasicOpsTest.testRemovedListener(AbstractTwoCachesBasicOpsTest.java:302) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[TestSuiteProgress] Tests succeeded: 19, failed: 1, skipped: 0 > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 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 November 2016