August 2017 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4038) CustomFailurePolicyTxTest.testPrepareFailure random failures

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4038?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4038: ------------------------------ Status: Pull Request Sent (was: Reopened) Git Pull Request: https://github.com/infinispan/infinispan/pull/5344 > CustomFailurePolicyTxTest.testPrepareFailure random failures > ------------------------------------------------------------- > > Key: ISPN-4038 > URL: https://issues.jboss.org/browse/ISPN-4038 > Project: Infinispan > Issue Type: Bug > Components: Cross-Site Replication, Test Suite - Core > Affects Versions: 6.0.1.Final > Reporter: Dan Berindei > Assignee: Pedro Ruivo > Labels: testsuite_stability > > http://ci.infinispan.org/viewLog.html?buildId=5935&tab=buildResultsDiv&bu... > {noformat} > java.lang.AssertionError: expected:<0> but was:<1> > 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.xsite.backupfailure.tx.BaseBackupTxFailureTest.testPrepareFailure(BaseBackupTxFailureTest.java:45) > at org.infinispan.xsite.backupfailure.tx.CustomFailurePolicyTxTest.testPrepareFailure(CustomFailurePolicyTxTest.java:37) > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4038) CustomFailurePolicyTxTest.testPrepareFailure random failures

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4038?page=com.atlassian.jira.plugin.... ] Pedro Ruivo reopened ISPN-4038: ------------------------------- Assignee: Pedro Ruivo > CustomFailurePolicyTxTest.testPrepareFailure random failures > ------------------------------------------------------------- > > Key: ISPN-4038 > URL: https://issues.jboss.org/browse/ISPN-4038 > Project: Infinispan > Issue Type: Bug > Components: Cross-Site Replication, Test Suite - Core > Affects Versions: 6.0.1.Final > Reporter: Dan Berindei > Assignee: Pedro Ruivo > Labels: testsuite_stability > > http://ci.infinispan.org/viewLog.html?buildId=5935&tab=buildResultsDiv&bu... > {noformat} > java.lang.AssertionError: expected:<0> but was:<1> > 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.xsite.backupfailure.tx.BaseBackupTxFailureTest.testPrepareFailure(BaseBackupTxFailureTest.java:45) > at org.infinispan.xsite.backupfailure.tx.CustomFailurePolicyTxTest.testPrepareFailure(CustomFailurePolicyTxTest.java:37) > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5947) Infinispan directory provider is a lot slower when lucene caches are distributed compared to replicated

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-5947?page=com.atlassian.jira.plugin.... ] Sanne Grinovero closed ISPN-5947. --------------------------------- Assignee: (was: Gustavo Fernandes) > Infinispan directory provider is a lot slower when lucene caches are distributed compared to replicated > ------------------------------------------------------------------------------------------------------- > > Key: ISPN-5947 > URL: https://issues.jboss.org/browse/ISPN-5947 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Reporter: Jakub Markos > > I noticed that the difference in performance when using Infinispan Directory Provider with lucene data cache in distributed mode compared to replicated mode is quite big. In numbers, on my computer, running a 4 node cluster with a distributed cache with indexing enabled: > {code} > <distributed-cache name="dist_lucene" owners="2" statistics="true"> > <indexing index="LOCAL"> > <property name="default.indexmanager">org.infinispan.query.indexmanager.InfinispanIndexManager</property> > <property name="default.exclusive_index_use">true</property> > <property name="default.metadata_cachename">lucene_metadata</property> > <property name="default.data_cachename">lucene_data</property> > <property name="default.locking_cachename">lucene_locking</property> > </indexing> > </distributed-cache> > <replicated-cache name="lucene_metadata" mode="SYNC" remote-timeout="25000"> > <indexing index="NONE"/> > </replicated-cache> > <replicated-cache name="lucene_data" mode="SYNC" remote-timeout="25000"> > <indexing index="NONE"/> > </replicated-cache> > <replicated-cache name="lucene_locking" mode="SYNC" remote-timeout="25000"> > <indexing index="NONE"/> > </replicated-cache> > {code} > Using 10 threads on each node, loading 100 000 entries takes ~2.5 minutes, and using 100 threads takes ~1 minute. Changing the configuration to use a distributed cache for the index data: > {code} > <distributed-cache name="lucene_data" mode="SYNC" remote-timeout="25000"> > <indexing index="NONE"/> > </distributed-cache> > {code} > leads to loading times 3+ hours (10 threads, I stopped it at around 80000 entries) and 22 minutes (100 threads), which is around 20x slowdown. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5947) Infinispan directory provider is a lot slower when lucene caches are distributed compared to replicated

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-5947?page=com.atlassian.jira.plugin.... ] Sanne Grinovero resolved ISPN-5947. ----------------------------------- Resolution: Rejected Not a bug, this is a direct consequence of the current design. We recommend using replicated caches for index storage for this reason. > Infinispan directory provider is a lot slower when lucene caches are distributed compared to replicated > ------------------------------------------------------------------------------------------------------- > > Key: ISPN-5947 > URL: https://issues.jboss.org/browse/ISPN-5947 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Reporter: Jakub Markos > Assignee: Gustavo Fernandes > > I noticed that the difference in performance when using Infinispan Directory Provider with lucene data cache in distributed mode compared to replicated mode is quite big. In numbers, on my computer, running a 4 node cluster with a distributed cache with indexing enabled: > {code} > <distributed-cache name="dist_lucene" owners="2" statistics="true"> > <indexing index="LOCAL"> > <property name="default.indexmanager">org.infinispan.query.indexmanager.InfinispanIndexManager</property> > <property name="default.exclusive_index_use">true</property> > <property name="default.metadata_cachename">lucene_metadata</property> > <property name="default.data_cachename">lucene_data</property> > <property name="default.locking_cachename">lucene_locking</property> > </indexing> > </distributed-cache> > <replicated-cache name="lucene_metadata" mode="SYNC" remote-timeout="25000"> > <indexing index="NONE"/> > </replicated-cache> > <replicated-cache name="lucene_data" mode="SYNC" remote-timeout="25000"> > <indexing index="NONE"/> > </replicated-cache> > <replicated-cache name="lucene_locking" mode="SYNC" remote-timeout="25000"> > <indexing index="NONE"/> > </replicated-cache> > {code} > Using 10 threads on each node, loading 100 000 entries takes ~2.5 minutes, and using 100 threads takes ~1 minute. Changing the configuration to use a distributed cache for the index data: > {code} > <distributed-cache name="lucene_data" mode="SYNC" remote-timeout="25000"> > <indexing index="NONE"/> > </distributed-cache> > {code} > leads to loading times 3+ hours (10 threads, I stopped it at around 80000 entries) and 22 minutes (100 threads), which is around 20x slowdown. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8137) Ignore random failing computeIfPresent test

by Katia Aresti (JIRA)

[ https://issues.jboss.org/browse/ISPN-8137?page=com.atlassian.jira.plugin.... ] Katia Aresti closed ISPN-8137. ------------------------------ Thanks to [~danberindei] the problem has been reproduced and can be resolved now > Ignore random failing computeIfPresent test > ------------------------------------------- > > Key: ISPN-8137 > URL: https://issues.jboss.org/browse/ISPN-8137 > Project: Infinispan > Issue Type: Task > Reporter: Katia Aresti > Assignee: Katia Aresti > > Ignore the random failing test until we understand what's going and and it's fixed by le linked issue -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8137) Ignore random failing computeIfPresent test

by Katia Aresti (JIRA)

[ https://issues.jboss.org/browse/ISPN-8137?page=com.atlassian.jira.plugin.... ] Katia Aresti updated ISPN-8137: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Won't Do > Ignore random failing computeIfPresent test > ------------------------------------------- > > Key: ISPN-8137 > URL: https://issues.jboss.org/browse/ISPN-8137 > Project: Infinispan > Issue Type: Task > Reporter: Katia Aresti > Assignee: Katia Aresti > > Ignore the random failing test until we understand what's going and and it's fixed by le linked issue -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5083) Hot Rod decoder should use async Cache operations

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-5083?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes resolved ISPN-5083. ------------------------------------- Resolution: Out of Date With the recent big refactorings in the server, most operations are now run outside the server IO loop > Hot Rod decoder should use async Cache operations > ------------------------------------------------- > > Key: ISPN-5083 > URL: https://issues.jboss.org/browse/ISPN-5083 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Protocols > Reporter: Galder Zamarreño > Assignee: Gustavo Fernandes > Fix For: 9.2.0.Final > > > Hot Rod decoder is currently tying up Netty threads as a result of calling up to Infinispan sync operations. Instead, Hot Rod decoder should call up async operations, convert the Notifying Futures to Scala Futures, and write up the reply when it's received. This should increase performance specially under heavy load. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6456) OptimisticTxPartitionAndMergeDuringPrepareTest.testOriginatorIsolatedPartition fails randomly

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-6456?page=com.atlassian.jira.plugin.... ] Ryan Emerson reassigned ISPN-6456: ---------------------------------- Assignee: Ryan Emerson (was: Galder Zamarreño) > OptimisticTxPartitionAndMergeDuringPrepareTest.testOriginatorIsolatedPartition fails randomly > --------------------------------------------------------------------------------------------- > > Key: ISPN-6456 > URL: https://issues.jboss.org/browse/ISPN-6456 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 8.1.2.Final > Reporter: Ivan Straka > Assignee: Ryan Emerson > > Test in Infinispan testsuite org.infinispan.partitionhandling.OptimisticTxPartitionAndMergeDuringPrepareTest.testOriginatorIsolatedPartition fails randomly > {code:java} > java.lang.RuntimeException: Timed out waiting for rebalancing to complete on node OptimisticTxPartitionAndMergeDuringPrepareTest-NodeI-7304, expected member list is [OptimisticTxPartitionAndMergeDuringPrepareTest-NodeI-7304, OptimisticTxPartitionAndMergeDuringPrepareTest-NodeJ-31794, OptimisticTxPartitionAndMergeDuringPrepareTest-NodeK-33671, OptimisticTxPartitionAndMergeDuringPrepareTest-NodeL-56275], current member list is [OptimisticTxPartitionAndMergeDuringPrepareTest-NodeJ-31794, OptimisticTxPartitionAndMergeDuringPrepareTest-NodeK-33671, OptimisticTxPartitionAndMergeDuringPrepareTest-NodeL-56275]! > at org.infinispan.test.TestingUtil.waitForRehashToComplete(TestingUtil.java:239) > at org.infinispan.test.TestingUtil.waitForRehashToComplete(TestingUtil.java:249) > at org.infinispan.partitionhandling.BaseTxPartitionAndMergeTest.mergeCluster(BaseTxPartitionAndMergeTest.java:87) > at org.infinispan.partitionhandling.BaseOptimisticTxPartitionAndMergeTest.doTest(BaseOptimisticTxPartitionAndMergeTest.java:75) > at org.infinispan.partitionhandling.OptimisticTxPartitionAndMergeDuringPrepareTest.testOriginatorIsolatedPartition(OptimisticTxPartitionAndMergeDuringPrepareTest.java:33) > 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.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) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8139) OptimisticPrimaryOwnerCrashDuringPrepareTest.testPrimaryOwnerCrash random failures

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-8139?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-8139: ------------------------------------ Fix Version/s: 9.1.1.Final > OptimisticPrimaryOwnerCrashDuringPrepareTest.testPrimaryOwnerCrash random failures > ---------------------------------------------------------------------------------- > > Key: ISPN-8139 > URL: https://issues.jboss.org/browse/ISPN-8139 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Reporter: Tristan Tarrant > Assignee: Dan Berindei > Labels: testsuite_stability > Fix For: 9.1.1.Final > > > Stacktrace > java.util.concurrent.TimeoutException > at java.util.concurrent.FutureTask.get(FutureTask.java:205) > at org.infinispan.distribution.rehash.OptimisticPrimaryOwnerCrashDuringPrepareTest.testPrimaryOwnerCrash(OptimisticPrimaryOwnerCrashDuringPrepareTest.java:58) > 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:748) > ... Removed 16 stack frames > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8139) OptimisticPrimaryOwnerCrashDuringPrepareTest.testPrimaryOwnerCrash random failures

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-8139?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-8139: ------------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > OptimisticPrimaryOwnerCrashDuringPrepareTest.testPrimaryOwnerCrash random failures > ---------------------------------------------------------------------------------- > > Key: ISPN-8139 > URL: https://issues.jboss.org/browse/ISPN-8139 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Reporter: Tristan Tarrant > Assignee: Dan Berindei > Labels: testsuite_stability > Fix For: 9.1.1.Final > > > Stacktrace > java.util.concurrent.TimeoutException > at java.util.concurrent.FutureTask.get(FutureTask.java:205) > at org.infinispan.distribution.rehash.OptimisticPrimaryOwnerCrashDuringPrepareTest.testPrimaryOwnerCrash(OptimisticPrimaryOwnerCrashDuringPrepareTest.java:58) > 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:748) > ... Removed 16 stack frames > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 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 August 2017