July 2016 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-6820) Documentation improvements

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-6820: ------------------------------------- Summary: Documentation improvements Key: ISPN-6820 URL: https://issues.jboss.org/browse/ISPN-6820 Project: Infinispan Issue Type: Task Components: Documentation-Core Reporter: Tristan Tarrant Assignee: Tristan Tarrant -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6819) SharedStoreInvalidationDuringRehashTest.testRehashWith[out]Preload random failures

by Dan Berindei (JIRA)

Dan Berindei created ISPN-6819: ---------------------------------- Summary: SharedStoreInvalidationDuringRehashTest.testRehashWith[out]Preload random failures Key: ISPN-6819 URL: https://issues.jboss.org/browse/ISPN-6819 Project: Infinispan Issue Type: Bug Components: Core, Test Suite - Core Affects Versions: 9.0.0.Alpha2 Reporter: Dan Berindei Priority: Critical Fix For: 9.0.0.Alpha3 {noformat} java.lang.AssertionError: expected:<0> but was:<3> at org.testng.AssertJUnit.fail(AssertJUnit.java:59) at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364) at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80) at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:245) at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:252) at org.infinispan.distribution.rehash.SharedStoreInvalidationDuringRehashTest.checkContentAndInvalidations(SharedStoreInvalidationDuringRehashTest.java:213) at org.infinispan.distribution.rehash.SharedStoreInvalidationDuringRehashTest.doTest(SharedStoreInvalidationDuringRehashTest.java:135) at org.infinispan.distribution.rehash.SharedStoreInvalidationDuringRehashTest.testRehashWithoutPreload(SharedStoreInvalidationDuringRehashTest.java:122) {noformat} http://ci.infinispan.org/project.html?tab=testDetails&testNameId=-7068250... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6818) Ensure that embedded mode compiles and runs with Java 9

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-6818: ------------------------------------- Summary: Ensure that embedded mode compiles and runs with Java 9 Key: ISPN-6818 URL: https://issues.jboss.org/browse/ISPN-6818 Project: Infinispan Issue Type: Task Components: Build process, Core Reporter: Tristan Tarrant Assignee: Tristan Tarrant Fix For: 9.0.0.Final In order for Infinispan (embedded) to compile and run with Java 9, we need to at least do the following: - Upgrade to JBoss Marshalling 1.4.11 - Remove usage of Javassist, including the maven-injection-plugin - Use special compiler flags to ensure that special modules are enabled (java.annotations.common) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6817) Re-enable MultiPojoVersionMarshallTest once Javassist works with JDK 1.9

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-6817: ------------------------------------- Summary: Re-enable MultiPojoVersionMarshallTest once Javassist works with JDK 1.9 Key: ISPN-6817 URL: https://issues.jboss.org/browse/ISPN-6817 Project: Infinispan Issue Type: Task Components: Test Suite - Core Reporter: Tristan Tarrant Assignee: Tristan Tarrant We need to disable MultiPojoVersionMarshallTest because Javassist (as of 3.20.0-GA) doesn't work with JDK 9. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6703) ClearCommand hanging in the test suite

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6703?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6703: ---------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.0.0.Alpha3 9.0.0.Final Resolution: Done > ClearCommand hanging in the test suite > -------------------------------------- > > Key: ISPN-6703 > URL: https://issues.jboss.org/browse/ISPN-6703 > Project: Infinispan > Issue Type: Bug > Affects Versions: 9.0.0.Alpha2, 8.2.2.Final > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 9.0.0.Alpha3, 9.0.0.Final > > > {noformat} > "testng-ClusteredCacheWithInfinispanDirectoryTest" #15 prio=5 os_prio=0 tid=0x00007fe220532000 nid=0x19a waiting on condition [0x00007fe1cc7dd000] > java.lang.Thread.State: TIMED_WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000007b8698d48> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) > at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) > at org.infinispan.statetransfer.StateTransferLockImpl.waitForTransactionData(StateTransferLockImpl.java:96) > at org.infinispan.interceptors.base.BaseStateTransferInterceptor.waitForTransactionData(BaseStateTransferInterceptor.java:97) > at org.infinispan.statetransfer.StateTransferInterceptor.handleNonTxWriteCommand(StateTransferInterceptor.java:366) > at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:281) > at org.infinispan.statetransfer.StateTransferInterceptor.visitClearCommand(StateTransferInterceptor.java:132) > at org.infinispan.commands.write.ClearCommand.acceptVisitor(ClearCommand.java:44) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99) > at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113) > at org.infinispan.commands.AbstractVisitor.visitClearCommand(AbstractVisitor.java:58) > at org.infinispan.commands.write.ClearCommand.acceptVisitor(ClearCommand.java:44) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99) > at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:114) > at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:83) > at org.infinispan.commands.AbstractVisitor.visitClearCommand(AbstractVisitor.java:58) > at org.infinispan.commands.write.ClearCommand.acceptVisitor(ClearCommand.java:44) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99) > at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113) > at org.infinispan.commands.AbstractVisitor.visitClearCommand(AbstractVisitor.java:58) > at org.infinispan.commands.write.ClearCommand.acceptVisitor(ClearCommand.java:44) > at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:335) > at org.infinispan.cache.impl.CacheImpl.clear(CacheImpl.java:588) > at org.infinispan.cache.impl.CacheImpl.clear(CacheImpl.java:579) > at org.infinispan.test.TestingUtil.killCaches(TestingUtil.java:769) > at org.infinispan.test.TestingUtil.killCacheManagers(TestingUtil.java:607) > at org.infinispan.test.MultipleCacheManagersTest.clearContent(MultipleCacheManagersTest.java:101) > at sun.reflect.GeneratedMethodAccessor214.invoke(Unknown Source) > 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.invokeConfigurationMethod(Invoker.java:564) > at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:213) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:786) > 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.access$000(SuiteRunner.java:38) > at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:382) > at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6805) CacheMgmtInterceptor: use a simpler variant of LongAdder

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6805?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6805: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/4442 > CacheMgmtInterceptor: use a simpler variant of LongAdder > -------------------------------------------------------- > > Key: ISPN-6805 > URL: https://issues.jboss.org/browse/ISPN-6805 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 9.0.0.Alpha2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.0.0.Alpha3 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6805) CacheMgmtInterceptor: use a simpler variant of LongAdder

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6805?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6805: ------------------------------- Status: Open (was: New) > CacheMgmtInterceptor: use a simpler variant of LongAdder > -------------------------------------------------------- > > Key: ISPN-6805 > URL: https://issues.jboss.org/browse/ISPN-6805 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 9.0.0.Alpha2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.0.0.Alpha3 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6799) OOB thread pool fills with threads trying to send remote get responses

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6799?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-6799: ------------------------------------ FYI, I fixed this for now by adding the {{NO_FC}} flag to sync RPC response messages. > OOB thread pool fills with threads trying to send remote get responses > ---------------------------------------------------------------------- > > Key: ISPN-6799 > URL: https://issues.jboss.org/browse/ISPN-6799 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.0.0.Alpha2, 8.2.2.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.0.0.Alpha3 > > > Note: This is a scenario that happens in the stress tests, with 4 nodes in dist mode, and 200+ threads per node doing only reads. I have not been able to reproduce it locally, even with a much lower OOB thread pool size and UFC.max_credits. > We don't use the {{NO_FC}} flag, so threads sending both requests and responses can block in UFC/MFC. Remote gets are executed directly on the OOB thread, so when we run out of credits for one node, the OOB pool can quickly become full with threads waiting to send a remote get response to that node. > While we can't send responses to that node, we won't send credits to it, either, as credits are only sent *after* the message has been processed by the application. That means OOB threads on all nodes will start blocking, trying to send remote get responses to us. > This is made a worse by our staggering of remote gets. As remote get responses block, the stagger timeout kicks in and we send even more remote gets, making it even harder for the system to recover. > UFC/MFC can send a {{CREDIT_REQUEST}} message to ask for more credits. The {{REPLENISH}} messages are handled on JGroups' internal thread pool, so they are not blocked. However, the CREDIT_REQUEST can be sent at most once every {{UFC.max_block_time}} ms, so they can't be relied on to provide enough credits. With the default settings, the throughput would be {{max_credits / max_block_time == 2mb / 0.5s == 4mb/s}}, which is really small compared to regular throughput. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6799) OOB thread pool fills with threads trying to send remote get responses

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6799?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6799: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/4441 > OOB thread pool fills with threads trying to send remote get responses > ---------------------------------------------------------------------- > > Key: ISPN-6799 > URL: https://issues.jboss.org/browse/ISPN-6799 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.0.0.Alpha2, 8.2.2.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.0.0.Alpha3 > > > Note: This is a scenario that happens in the stress tests, with 4 nodes in dist mode, and 200+ threads per node doing only reads. I have not been able to reproduce it locally, even with a much lower OOB thread pool size and UFC.max_credits. > We don't use the {{NO_FC}} flag, so threads sending both requests and responses can block in UFC/MFC. Remote gets are executed directly on the OOB thread, so when we run out of credits for one node, the OOB pool can quickly become full with threads waiting to send a remote get response to that node. > While we can't send responses to that node, we won't send credits to it, either, as credits are only sent *after* the message has been processed by the application. That means OOB threads on all nodes will start blocking, trying to send remote get responses to us. > This is made a worse by our staggering of remote gets. As remote get responses block, the stagger timeout kicks in and we send even more remote gets, making it even harder for the system to recover. > UFC/MFC can send a {{CREDIT_REQUEST}} message to ask for more credits. The {{REPLENISH}} messages are handled on JGroups' internal thread pool, so they are not blocked. However, the CREDIT_REQUEST can be sent at most once every {{UFC.max_block_time}} ms, so they can't be relied on to provide enough credits. With the default settings, the throughput would be {{max_credits / max_block_time == 2mb / 0.5s == 4mb/s}}, which is really small compared to regular throughput. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6799) OOB thread pool fills with threads trying to send remote get responses

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6799?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6799: ------------------------------- Status: Open (was: New) > OOB thread pool fills with threads trying to send remote get responses > ---------------------------------------------------------------------- > > Key: ISPN-6799 > URL: https://issues.jboss.org/browse/ISPN-6799 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.0.0.Alpha2, 8.2.2.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.0.0.Alpha3 > > > Note: This is a scenario that happens in the stress tests, with 4 nodes in dist mode, and 200+ threads per node doing only reads. I have not been able to reproduce it locally, even with a much lower OOB thread pool size and UFC.max_credits. > We don't use the {{NO_FC}} flag, so threads sending both requests and responses can block in UFC/MFC. Remote gets are executed directly on the OOB thread, so when we run out of credits for one node, the OOB pool can quickly become full with threads waiting to send a remote get response to that node. > While we can't send responses to that node, we won't send credits to it, either, as credits are only sent *after* the message has been processed by the application. That means OOB threads on all nodes will start blocking, trying to send remote get responses to us. > This is made a worse by our staggering of remote gets. As remote get responses block, the stagger timeout kicks in and we send even more remote gets, making it even harder for the system to recover. > UFC/MFC can send a {{CREDIT_REQUEST}} message to ask for more credits. The {{REPLENISH}} messages are handled on JGroups' internal thread pool, so they are not blocked. However, the CREDIT_REQUEST can be sent at most once every {{UFC.max_block_time}} ms, so they can't be relied on to provide enough credits. With the default settings, the throughput would be {{max_credits / max_block_time == 2mb / 0.5s == 4mb/s}}, which is really small compared to regular throughput. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

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