May 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3102) Analyse the performance of MassIndexingTest

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3102?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3102: -------------------------------- Priority: Critical (was: Major) > Analyse the performance of MassIndexingTest > ------------------------------------------- > > Key: ISPN-3102 > URL: https://issues.jboss.org/browse/ISPN-3102 > Project: Infinispan > Issue Type: Task > Reporter: Mircea Markus > Assignee: Mircea Markus > Priority: Critical > Fix For: 5.3.0.CR1, 5.3.0.Final > > > MassIndexingTest runs on CI in 10 mins with TRACE on and 3 mins with TRACE off. According to Sanne this shouldn't take that long: > {quote} > sannegrinovero > 11:50 mmarkus: the org.infinispan.query.distributed.MassIndexingTest test is adding 2000 entries to the cache. True that might be a bit excessive, still if it takes 10 minutes you have a problem in Infinispan core. > mmarkus > 11:52 sannegrinovero: each such write is indexed I take it? > sannegrinovero > 11:53 mmarkus: no: withFlags(Flag.SKIP_INDEXING) > 11:54 mmarkus: but it's a 4 node DIST test using Map/Reduce. > sannegrinovero > 11:54 then the Map/Reduce job does some indexing but the indexing engine didn't change overnight > {quote} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3102) Analyse the performance of MassIndexingTest

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3102?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-3102: ------------------------------------- Marking this as critical as we need to investigate if the performance regression was introduced in Infinispan 5.3 or it was present in 5.2 as well. If later, this shouldn't stop the 5.3 release. > Analyse the performance of MassIndexingTest > ------------------------------------------- > > Key: ISPN-3102 > URL: https://issues.jboss.org/browse/ISPN-3102 > Project: Infinispan > Issue Type: Task > Reporter: Mircea Markus > Assignee: Mircea Markus > Priority: Critical > Fix For: 5.3.0.CR1, 5.3.0.Final > > > MassIndexingTest runs on CI in 10 mins with TRACE on and 3 mins with TRACE off. According to Sanne this shouldn't take that long: > {quote} > sannegrinovero > 11:50 mmarkus: the org.infinispan.query.distributed.MassIndexingTest test is adding 2000 entries to the cache. True that might be a bit excessive, still if it takes 10 minutes you have a problem in Infinispan core. > mmarkus > 11:52 sannegrinovero: each such write is indexed I take it? > sannegrinovero > 11:53 mmarkus: no: withFlags(Flag.SKIP_INDEXING) > 11:54 mmarkus: but it's a 4 node DIST test using Map/Reduce. > sannegrinovero > 11:54 then the Map/Reduce job does some indexing but the indexing engine didn't change overnight > {quote} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3102) Analyse the performance of MassIndexingTest

by Mircea Markus (JIRA)

Mircea Markus created ISPN-3102: ----------------------------------- Summary: Analyse the performance of MassIndexingTest Key: ISPN-3102 URL: https://issues.jboss.org/browse/ISPN-3102 Project: Infinispan Issue Type: Task Reporter: Mircea Markus Assignee: Mircea Markus MassIndexingTest runs on CI in 10 mins with TRACE on and 3 mins with TRACE off. According to Sanne this shouldn't take that long: {quote} sannegrinovero 11:50 mmarkus: the org.infinispan.query.distributed.MassIndexingTest test is adding 2000 entries to the cache. True that might be a bit excessive, still if it takes 10 minutes you have a problem in Infinispan core. mmarkus 11:52 sannegrinovero: each such write is indexed I take it? sannegrinovero 11:53 mmarkus: no: withFlags(Flag.SKIP_INDEXING) 11:54 mmarkus: but it's a 4 node DIST test using Map/Reduce. sannegrinovero 11:54 then the Map/Reduce job does some indexing but the indexing engine didn't change overnight {quote} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3102) Analyse the performance of MassIndexingTest

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3102?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3102: -------------------------------- Fix Version/s: 5.3.0.CR1 5.3.0.Final > Analyse the performance of MassIndexingTest > ------------------------------------------- > > Key: ISPN-3102 > URL: https://issues.jboss.org/browse/ISPN-3102 > Project: Infinispan > Issue Type: Task > Reporter: Mircea Markus > Assignee: Mircea Markus > Fix For: 5.3.0.CR1, 5.3.0.Final > > > MassIndexingTest runs on CI in 10 mins with TRACE on and 3 mins with TRACE off. According to Sanne this shouldn't take that long: > {quote} > sannegrinovero > 11:50 mmarkus: the org.infinispan.query.distributed.MassIndexingTest test is adding 2000 entries to the cache. True that might be a bit excessive, still if it takes 10 minutes you have a problem in Infinispan core. > mmarkus > 11:52 sannegrinovero: each such write is indexed I take it? > sannegrinovero > 11:53 mmarkus: no: withFlags(Flag.SKIP_INDEXING) > 11:54 mmarkus: but it's a 4 node DIST test using Map/Reduce. > sannegrinovero > 11:54 then the Map/Reduce job does some indexing but the indexing engine didn't change overnight > {quote} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2895) org.infinispan.lucene.InfinispanDirectoryIOTest.testReadWholeFile fails randomly

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2895?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-2895: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=918448, https://bugzilla.redhat.com/show_bug.cgi?id=963166 (was: https://bugzilla.redhat.com/show_bug.cgi?id=918448) > org.infinispan.lucene.InfinispanDirectoryIOTest.testReadWholeFile fails randomly > -------------------------------------------------------------------------------- > > Key: ISPN-2895 > URL: https://issues.jboss.org/browse/ISPN-2895 > Project: Infinispan > Issue Type: Bug > Components: Lucene Directory > Affects Versions: 5.2.2.Final > Reporter: Anna Manukyan > Assignee: Sanne Grinovero > Labels: stable_embedded_query > Fix For: 5.3.0.CR1 > > > The test fails randomly and the error message is: > {code} > java.lang.NullPointerException > at org.infinispan.lucene.DirectoryIntegrityCheck.verifyDirectoryStructure(DirectoryIntegrityCheck.java:76) > at org.infinispan.lucene.DirectoryIntegrityCheck.verifyDirectoryStructure(DirectoryIntegrityCheck.java:56) > at org.infinispan.lucene.InfinispanDirectoryIOTest.verifyOnBuffer(InfinispanDirectoryIOTest.java:184) > at org.infinispan.lucene.InfinispanDirectoryIOTest.testReadWholeFile(InfinispanDirectoryIOTest.java:153) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:715) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237) > 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:334) > at org.testng.SuiteRunner.access$000(SuiteRunner.java:37) > at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368) > at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:722) > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3101) AbstractTxLockingInterceptor.lockKeyAndCheckOwnership miscalculates the time it should wait for Tx to complete

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3101?page=com.atlassian.jira.plugin.... ] Adrian Nistor deleted ISPN-3101: -------------------------------- > AbstractTxLockingInterceptor.lockKeyAndCheckOwnership miscalculates the time it should wait for Tx to complete > -------------------------------------------------------------------------------------------------------------- > > Key: ISPN-3101 > URL: https://issues.jboss.org/browse/ISPN-3101 > Project: Infinispan > Issue Type: Bug > Environment: Works on PC with Linux + Oracle jdk. Should fail on mac. > Reporter: Adrian Nistor > Assignee: Mircea Markus > > The wait time is computed based on System.nanoTime() which is not identical to wall clock time on all platforms. It happens to work on PCs with Linux + Oracle jdk but it is known to be different on mac. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3101) AbstractTxLockingInterceptor.lockKeyAndCheckOwnership miscalculates the time it should wait for Tx to complete

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3101?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-3101: -------------------------------- > AbstractTxLockingInterceptor.lockKeyAndCheckOwnership miscalculates the time it should wait for Tx to complete > -------------------------------------------------------------------------------------------------------------- > > Key: ISPN-3101 > URL: https://issues.jboss.org/browse/ISPN-3101 > Project: Infinispan > Issue Type: Bug > Components: Locking and Concurrency, Transactions > Affects Versions: 5.2.5.Final > Environment: Works on PC with Linux + Oracle jdk. Should fail on mac. > Reporter: Adrian Nistor > Assignee: Mircea Markus > Fix For: 5.3.0.Final > > > The wait time is computed based on System.nanoTime() which is not identical to wall clock time on all platforms. It happens to work on PCs with Linux + Oracle jdk but it is known to be different on mac. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2895) org.infinispan.lucene.InfinispanDirectoryIOTest.testReadWholeFile fails randomly

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2895?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2895: ----------------------------------------------- Richard Janík <rjanik(a)redhat.com> made a comment on [bug 963166|https://bugzilla.redhat.com/show_bug.cgi?id=963166] +++ This bug was initially created as a clone of Bug #918448 +++ The error message is: java.lang.NullPointerException at org.infinispan.lucene.DirectoryIntegrityCheck.verifyDirectoryStructure(DirectoryIntegrityCheck.java:76) at org.infinispan.lucene.DirectoryIntegrityCheck.verifyDirectoryStructure(DirectoryIntegrityCheck.java:56) at org.infinispan.lucene.InfinispanDirectoryIOTest.verifyOnBuffer(InfinispanDirectoryIOTest.java:184) at org.infinispan.lucene.InfinispanDirectoryIOTest.testReadWholeFile(InfinispanDirectoryIOTest.java:153) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80) at org.testng.internal.Invoker.invokeMethod(Invoker.java:715) at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237) 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:334) at org.testng.SuiteRunner.access$000(SuiteRunner.java:37) at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368) at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:722) > org.infinispan.lucene.InfinispanDirectoryIOTest.testReadWholeFile fails randomly > -------------------------------------------------------------------------------- > > Key: ISPN-2895 > URL: https://issues.jboss.org/browse/ISPN-2895 > Project: Infinispan > Issue Type: Bug > Components: Lucene Directory > Affects Versions: 5.2.2.Final > Reporter: Anna Manukyan > Assignee: Sanne Grinovero > Labels: stable_embedded_query > Fix For: 5.3.0.CR1 > > > The test fails randomly and the error message is: > {code} > java.lang.NullPointerException > at org.infinispan.lucene.DirectoryIntegrityCheck.verifyDirectoryStructure(DirectoryIntegrityCheck.java:76) > at org.infinispan.lucene.DirectoryIntegrityCheck.verifyDirectoryStructure(DirectoryIntegrityCheck.java:56) > at org.infinispan.lucene.InfinispanDirectoryIOTest.verifyOnBuffer(InfinispanDirectoryIOTest.java:184) > at org.infinispan.lucene.InfinispanDirectoryIOTest.testReadWholeFile(InfinispanDirectoryIOTest.java:153) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:715) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237) > 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:334) > at org.testng.SuiteRunner.access$000(SuiteRunner.java:37) > at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368) > at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:722) > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3101) AbstractTxLockingInterceptor.lockKeyAndCheckOwnership miscalculates the time it should wait for Tx to complete

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3101?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-3101: -------------------------------- Description: The wait time is computed based on System.nanoTime() which is not identical to wall clock time on all platforms. It happens to work on PCs with Linux + Oracle jdk but it is known to be different on mac. (was: The wait time is computed based on System.nanoTime() which is not identical to wall clock time on all platforms. It happens to work on Linux + Oracle jdk but it is known to be different on mac.) > AbstractTxLockingInterceptor.lockKeyAndCheckOwnership miscalculates the time it should wait for Tx to complete > -------------------------------------------------------------------------------------------------------------- > > Key: ISPN-3101 > URL: https://issues.jboss.org/browse/ISPN-3101 > Project: Infinispan > Issue Type: Bug > Components: Locking and Concurrency, Transactions > Affects Versions: 5.2.5.Final > Environment: Works on Linux + Oracle jdk. Should fail on mac. > Reporter: Adrian Nistor > Assignee: Mircea Markus > Fix For: 5.3.0.Final > > > The wait time is computed based on System.nanoTime() which is not identical to wall clock time on all platforms. It happens to work on PCs with Linux + Oracle jdk but it is known to be different on mac. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3101) AbstractTxLockingInterceptor.lockKeyAndCheckOwnership miscalculates the time it should wait for Tx to complete

by Adrian Nistor (JIRA)

Adrian Nistor created ISPN-3101: ----------------------------------- Summary: AbstractTxLockingInterceptor.lockKeyAndCheckOwnership miscalculates the time it should wait for Tx to complete Key: ISPN-3101 URL: https://issues.jboss.org/browse/ISPN-3101 Project: Infinispan Issue Type: Bug Components: Locking and Concurrency, Transactions Affects Versions: 5.2.5.Final Environment: Works on Linux + Oracle jdk. Should fail on mac. Reporter: Adrian Nistor Assignee: Mircea Markus Fix For: 5.3.0.Final The wait time is computed based on System.nanoTime() which is not identical to wall clock time on all platforms. It happens to work on Linux + Oracle jdk but it is known to be different on mac. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2013