[JBoss JIRA] (ISPN-2780) org.infinispan.lucene.cacheloader.IndexCacheLoaderTest.readExistingIndexTest fails randomly on all environments
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-2780?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-2780:
-------------------------------
Assignee: Sanne Grinovero (was: Pedro Ruivo)
> org.infinispan.lucene.cacheloader.IndexCacheLoaderTest.readExistingIndexTest fails randomly on all environments
> ---------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-2780
> URL: https://issues.jboss.org/browse/ISPN-2780
> Project: Infinispan
> Issue Type: Bug
> Components: Lucene Directory
> Affects Versions: 5.2.0.CR3
> Reporter: Anna Manukyan
> Assignee: Sanne Grinovero
> Priority: Critical
> Labels: retest, stable_embedded_query, testsuite_stability
>
> The test org.infinispan.lucene.cacheloader.IndexCacheLoaderTest.readExistingIndexTest fails almost always on all environments. The error message is:
> {code}
> Error Message
> String '0' should exist but was not found in index
> Stacktrace
> java.lang.AssertionError: String '0' should exist but was not found in index
> at org.infinispan.lucene.cacheloader.IndexCacheLoaderTest.verifyOnDirectory(IndexCacheLoaderTest.java:131)
> at org.infinispan.lucene.cacheloader.IndexCacheLoaderTest.verifyIndex(IndexCacheLoaderTest.java:83)
> at org.infinispan.lucene.cacheloader.IndexCacheLoaderTest.readExistingIndexTest(IndexCacheLoaderTest.java:71)
> 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:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> 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
12 years, 1 month
[JBoss JIRA] (ISPN-4018) Write skew should not be check in failed operations
by Pedro Ruivo (JIRA)
Pedro Ruivo created ISPN-4018:
---------------------------------
Summary: Write skew should not be check in failed operations
Key: ISPN-4018
URL: https://issues.jboss.org/browse/ISPN-4018
Project: Infinispan
Issue Type: Bug
Components: Core, Transactions
Affects Versions: 6.0.1.Final
Reporter: Pedro Ruivo
Assignee: Pedro Ruivo
Fix For: 7.0.0.Alpha1, 7.0.0.Final
Currently, if a conditional operation does no perform the update, we still perform the check. however, the write never happened. It simple makes no sense.
However, if a write succeeds after, the write skew check must be performed for the key.
--
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
12 years, 1 month
[JBoss JIRA] (ISPN-3671) Evaluate replacement of Mockito usage of spy with Forwarding mocks instead
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3671?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3671:
-------------------------------
Assignee: William Burns (was: Mircea Markus)
> Evaluate replacement of Mockito usage of spy with Forwarding mocks instead
> --------------------------------------------------------------------------
>
> Key: ISPN-3671
> URL: https://issues.jboss.org/browse/ISPN-3671
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 6.0.0.CR1
> Reporter: William Burns
> Assignee: William Burns
>
> Usage of Mockito spy actually creates a new instance (with current state) of the provided delegate. This can cause issues if there are already threads created that modify the provided delegate state as it won't affect the new object.
> It would be safer to first use a forwarding mock instead that doesn't create another instance as this has caused issues with some tests regarding state transfer.
> Here is an example of how the forwarding mock can be used.
> {code}
> StateConsumer sc = TestingUtil.extractComponent(cache, StateConsumer.class);
> final Answer<Object> forwardedAnswer = AdditionalAnswers.delegatesTo(sc);
> StateConsumer mockConsumer = mock(StateConsumer.class, withSettings().defaultAnswer(forwardedAnswer));
> TestingUtil.replaceComponent(cache, StateConsumer.class, mockConsumer, true);
> doAnswer(new Answer() {
> @Override
> public Object answer(InvocationOnMock invocation) throws Throwable {
> // Do something
> return forwardedAnswer.answer(invocation);
> }
> }).when(mockConsumer).applyState(any(Address.class), anyInt(), anyCollection());
> {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
12 years, 1 month
[JBoss JIRA] (ISPN-3554) Tests from org.infinispan.persistence package fail on different environments
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3554?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3554:
-------------------------------
Component/s: Loaders and Stores
> Tests from org.infinispan.persistence package fail on different environments
> ----------------------------------------------------------------------------
>
> Key: ISPN-3554
> URL: https://issues.jboss.org/browse/ISPN-3554
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Loaders and Stores
> Affects Versions: 6.0.0.Beta1
> Environment: Solaris{10,11}, Solaris Sparc{10, 11}, Windows{2008R2, 2012} && jdk6, RHEL{5, 6} && {x86_64, x64} && jdk6
> Reporter: Vitalii Chepeliuk
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Attachments: infinispan.log.zip, thread_dump_hunged_testsuite.log
>
>
> Following 4 tests fails
> org.infinispan.persistence.LocalModeNoPassivationTest.testEntrySetWithEvictedEntries
> org.infinispan.persistence.LocalModeNoPassivationTest.testValuesWithEvictedEntries
> org.infinispan.persistence.LocalModePassivationTest.testEntrySetWithEvictedEntries
> org.infinispan.persistence.LocalModePassivationTest.testValuesWithEvictedEntries
> You can see failing result from our jenkins
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
> Please note, that the following test is also failing very often org.infinispan.persistence.remote.RemoteStoreTest.testLoadAndStoreWithLifespanAndIdle. Here the failure is mostly on Windows machines with JDK6. You can find the logs here:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/edg-60-ispn-testsuite...
> Yet another thing about these tests. Very often the testsuite hangs on the tests for LocalModePassivationTest. The last test that is executed is: testSizeWithEvictedEntries(org.infinispan.persistence.LocalModePassivationTest) and the testsuite hangs on the execution of testSizeWithEvictedEntriesAndFlags(org.infinispan.persistence.LocalModePassivationTest). Unfortunatelly at the moment I cannot provide any logs, as the job abort doesn't do the thread dump of the java process. As soon as I'll succeed in the log retrieval, I'll attach also these logs.
--
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
12 years, 1 month
[JBoss JIRA] (ISPN-3628) Tests from Infinispan CDI module fail randomly
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3628?page=com.atlassian.jira.plugin.... ]
Dan Berindei reassigned ISPN-3628:
----------------------------------
Assignee: Dan Berindei (was: Mircea Markus)
> Tests from Infinispan CDI module fail randomly
> ----------------------------------------------
>
> Key: ISPN-3628
> URL: https://issues.jboss.org/browse/ISPN-3628
> Project: Infinispan
> Issue Type: Bug
> Components: CDI Integration
> Affects Versions: 6.0.0.Beta2, 6.0.0.CR1, 6.0.0.Final
> Environment: ORACLE JDK and RHEL5_x86, RHEL5_x86_64
> IBM JDK,RHEL5_x86
> OPEN JDK and RHEL5_x86, RHEL5_x86_64
> ORACLE JDK and RHEL6_x86, RHEL6_x86_64
> OPEN JDK and RHEL6_x86, RHEL6_x86_64
> Solaris 10 Sparc, Oracle JDK 7
> Reporter: Vitalii Chepeliuk
> Assignee: Dan Berindei
> Priority: Minor
> Labels: testsuite_stability
>
> Add some links from jenkins
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
--
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
12 years, 1 month
[JBoss JIRA] (ISPN-3554) Tests from org.infinispan.persistence package fail on different environments
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3554?page=com.atlassian.jira.plugin.... ]
Dan Berindei reassigned ISPN-3554:
----------------------------------
Assignee: Dan Berindei (was: Mircea Markus)
> Tests from org.infinispan.persistence package fail on different environments
> ----------------------------------------------------------------------------
>
> Key: ISPN-3554
> URL: https://issues.jboss.org/browse/ISPN-3554
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 6.0.0.Beta1
> Environment: Solaris{10,11}, Solaris Sparc{10, 11}, Windows{2008R2, 2012} && jdk6, RHEL{5, 6} && {x86_64, x64} && jdk6
> Reporter: Vitalii Chepeliuk
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Attachments: infinispan.log.zip, thread_dump_hunged_testsuite.log
>
>
> Following 4 tests fails
> org.infinispan.persistence.LocalModeNoPassivationTest.testEntrySetWithEvictedEntries
> org.infinispan.persistence.LocalModeNoPassivationTest.testValuesWithEvictedEntries
> org.infinispan.persistence.LocalModePassivationTest.testEntrySetWithEvictedEntries
> org.infinispan.persistence.LocalModePassivationTest.testValuesWithEvictedEntries
> You can see failing result from our jenkins
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
> Please note, that the following test is also failing very often org.infinispan.persistence.remote.RemoteStoreTest.testLoadAndStoreWithLifespanAndIdle. Here the failure is mostly on Windows machines with JDK6. You can find the logs here:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/edg-60-ispn-testsuite...
> Yet another thing about these tests. Very often the testsuite hangs on the tests for LocalModePassivationTest. The last test that is executed is: testSizeWithEvictedEntries(org.infinispan.persistence.LocalModePassivationTest) and the testsuite hangs on the execution of testSizeWithEvictedEntriesAndFlags(org.infinispan.persistence.LocalModePassivationTest). Unfortunatelly at the moment I cannot provide any logs, as the job abort doesn't do the thread dump of the java process. As soon as I'll succeed in the log retrieval, I'll attach also these logs.
--
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
12 years, 1 month