March 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2906) SyncCacheListenerTest.testSyncTxRepl failing randomly

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-2906: -------------------------------------- Summary: SyncCacheListenerTest.testSyncTxRepl failing randomly Key: ISPN-2906 URL: https://issues.jboss.org/browse/ISPN-2906 Project: Infinispan Issue Type: Bug Components: Listeners Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.3.0.Alpha1 {code}testSyncTxRepl(org.infinispan.replication.SyncCacheListenerTest) Time elapsed: 0.04 sec <<< FAILURE! java.lang.AssertionError: "age" obtained from cache2 must be non-null at org.testng.AssertJUnit.fail(AssertJUnit.java:59) at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:24) at org.testng.AssertJUnit.assertNotNull(AssertJUnit.java:267) at org.infinispan.replication.SyncCacheListenerTest.testSyncTxRepl(SyncCacheListenerTest.java:99) 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: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: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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2903) Manual eviction should not delete entry from cache store

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2903?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-2903: ---------------------------------------- I've got a fix now, testing... I'll send a pull req as soon as it's ready. p.s. Paul/Rado, you guys should add org.jboss.as.test.clustering.cluster.AtomicMapTestCase to your automates testsuite to avoid future surprises... > Manual eviction should not delete entry from cache store > -------------------------------------------------------- > > Key: ISPN-2903 > URL: https://issues.jboss.org/browse/ISPN-2903 > Project: Infinispan > Issue Type: Bug > Components: Eviction > Affects Versions: 5.2.3.Final > Reporter: Paul Ferraro > Assignee: Galder Zamarreño > Priority: Critical > Labels: jdg6 > Fix For: 5.2.5.Final, 5.3.0.Alpha1, 5.3.0.Final > > Attachments: AtomicMapServlet.java, AtomicMapTestCase.java, server.log, server.log > > > Here's the scenario: > Given 2 nodes with REPL_SYNC cache with passivating cache store (e.g. default web cache in AS7). > 1. Create cache entry containing atomic map with 2 map entries on node1. > 2. Passivate that cache entry on node2 via manual evict. > 3. Modify 1 of the atomic map entries within the cache entry on node1. > 4. Lookup atomic map on node2. It only contains 1 map entry - the map entry modified in step 3. The other map entry is lost. > It's a side effect of ISPN-2384, where some changes were made to tighten the passivation/activation scenarios, but it did not cover manual eviction calls. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2903) Manual eviction should not delete entry from cache store

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2903?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-2903: ----------------------------------- Summary: Manual eviction should not delete entry from cache store (was: CLONE - Eviction causes lost AtomicMap entries) Description: Here's the scenario: Given 2 nodes with REPL_SYNC cache with passivating cache store (e.g. default web cache in AS7). 1. Create cache entry containing atomic map with 2 map entries on node1. 2. Passivate that cache entry on node2 via manual evict. 3. Modify 1 of the atomic map entries within the cache entry on node1. 4. Lookup atomic map on node2. It only contains 1 map entry - the map entry modified in step 3. The other map entry is lost. It's a side effect of ISPN-2384, where some changes were made to tighten the passivation/activation scenarios, but it did not cover manual eviction calls. was: Here's the scenario: Given 2 nodes with REPL_SYNC cache with passivating cache store (e.g. default web cache in AS7). 1. Create cache entry containing atomic map with 2 map entries on node1. 2. Passivate that cache entry on node2 via manual evict. 3. Modify 1 of the atomic map entries within the cache entry on node1. 4. Lookup atomic map on node2. It only contains 1 map entry - the map entry modified in step 3. The other map entry is lost. > Manual eviction should not delete entry from cache store > -------------------------------------------------------- > > Key: ISPN-2903 > URL: https://issues.jboss.org/browse/ISPN-2903 > Project: Infinispan > Issue Type: Bug > Components: Eviction > Affects Versions: 5.2.3.Final > Reporter: Paul Ferraro > Assignee: Galder Zamarreño > Priority: Critical > Labels: jdg6 > Fix For: 5.2.5.Final, 5.3.0.Alpha1, 5.3.0.Final > > Attachments: AtomicMapServlet.java, AtomicMapTestCase.java, server.log, server.log > > > Here's the scenario: > Given 2 nodes with REPL_SYNC cache with passivating cache store (e.g. default web cache in AS7). > 1. Create cache entry containing atomic map with 2 map entries on node1. > 2. Passivate that cache entry on node2 via manual evict. > 3. Modify 1 of the atomic map entries within the cache entry on node1. > 4. Lookup atomic map on node2. It only contains 1 map entry - the map entry modified in step 3. The other map entry is lost. > It's a side effect of ISPN-2384, where some changes were made to tighten the passivation/activation scenarios, but it did not cover manual eviction calls. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2903) CLONE - Eviction causes lost AtomicMap entries

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2903?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-2903: ---------------------------------------- Paul/Rado, found the root cause. I was using an unbounded container in testing and the issue only happens with a bounded container, and indeed, it's a side effect of ISPN-2384. I'm working on a fix... > CLONE - Eviction causes lost AtomicMap entries > ---------------------------------------------- > > Key: ISPN-2903 > URL: https://issues.jboss.org/browse/ISPN-2903 > Project: Infinispan > Issue Type: Bug > Components: Eviction > Affects Versions: 5.2.3.Final > Reporter: Paul Ferraro > Assignee: Galder Zamarreño > Priority: Critical > Labels: jdg6 > Fix For: 5.2.5.Final, 5.3.0.Alpha1, 5.3.0.Final > > Attachments: AtomicMapServlet.java, AtomicMapTestCase.java, server.log, server.log > > > Here's the scenario: > Given 2 nodes with REPL_SYNC cache with passivating cache store (e.g. default web cache in AS7). > 1. Create cache entry containing atomic map with 2 map entries on node1. > 2. Passivate that cache entry on node2 via manual evict. > 3. Modify 1 of the atomic map entries within the cache entry on node1. > 4. Lookup atomic map on node2. It only contains 1 map entry - the map entry modified in step 3. The other map entry is lost. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2875) Intermittent test failure: org.infinispan.statetransfer.DistNonTxOperationsDuringStateTransferTest

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-2875?page=com.atlassian.jira.plugin.... ] Work on ISPN-2875 started by Adrian Nistor. > Intermittent test failure: org.infinispan.statetransfer.DistNonTxOperationsDuringStateTransferTest > -------------------------------------------------------------------------------------------------- > > Key: ISPN-2875 > URL: https://issues.jboss.org/browse/ISPN-2875 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Reporter: Mircea Markus > Assignee: Adrian Nistor > Labels: testsuite_stability > Fix For: 5.3.0.Alpha1 > > Attachments: dntodstt.log > > > {quote} > java.lang.AssertionError > at org.junit.Assert.fail(Assert.java:92) > at org.junit.Assert.assertTrue(Assert.java:43) > at org.junit.Assert.assertNull(Assert.java:551) > at org.junit.Assert.assertNull(Assert.java:562) > at org.infinispan.statetransfer.BaseOperationsDuringStateTransferTest.testReplace(BaseOperationsDuringStateTransferTest.java:333) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80) > 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: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:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:680) > {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, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2905) StateTransferLockImpl.waitForTransactionData should be able to time-out

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-2905?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-2905: ------------------------------ Description: During a topology change a lot of threads can get stuck in {{StateTransferLockImpl.waitForTransactionData}} indefinitely, due to ISPN-2808 fill up the OOB threadpool and block the topology change. These operations should timeout after a period. was: During a topology change a lot of threads can get stuck in {{StateTransferLockImpl.waitForTransactionData}} indefinitely, due to ISPN-2808 fill up the OOB threadpool and block the topology change to be finished. These operations should timeout after a period. > StateTransferLockImpl.waitForTransactionData should be able to time-out > ----------------------------------------------------------------------- > > Key: ISPN-2905 > URL: https://issues.jboss.org/browse/ISPN-2905 > Project: Infinispan > Issue Type: Feature Request > Affects Versions: 5.2.4.Final > Reporter: Radim Vansa > Assignee: Dan Berindei > > During a topology change a lot of threads can get stuck in {{StateTransferLockImpl.waitForTransactionData}} indefinitely, due to ISPN-2808 fill up the OOB threadpool and block the topology change. > These operations should timeout after a period. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2905) StateTransferLockImpl.waitForTransactionData should be able to time-out

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-2905?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-2905: ------------------------------ Assignee: Dan Berindei (was: Mircea Markus) > StateTransferLockImpl.waitForTransactionData should be able to time-out > ----------------------------------------------------------------------- > > Key: ISPN-2905 > URL: https://issues.jboss.org/browse/ISPN-2905 > Project: Infinispan > Issue Type: Feature Request > Affects Versions: 5.2.4.Final > Reporter: Radim Vansa > Assignee: Dan Berindei > > During a topology change a lot of threads can get stuck in {{StateTransferLockImpl.waitForTransactionData}} indefinitely, due to ISPN-2808 fill up the OOB threadpool and block the topology change to be finished. > These operations should timeout after a period. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2905) StateTransferLockImpl.waitForTransactionData should be able to time-out

by Radim Vansa (JIRA)

Radim Vansa created ISPN-2905: --------------------------------- Summary: StateTransferLockImpl.waitForTransactionData should be able to time-out Key: ISPN-2905 URL: https://issues.jboss.org/browse/ISPN-2905 Project: Infinispan Issue Type: Feature Request Reporter: Radim Vansa Assignee: Mircea Markus During a topology change a lot of threads can get stuck in {{StateTransferLockImpl.waitForTransactionData}} indefinitely, due to ISPN-2808 fill up the OOB threadpool and block the topology change to be finished. These operations should timeout after a period. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2905) StateTransferLockImpl.waitForTransactionData should be able to time-out

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-2905?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-2905: ------------------------------ Affects Version/s: 5.2.4.Final > StateTransferLockImpl.waitForTransactionData should be able to time-out > ----------------------------------------------------------------------- > > Key: ISPN-2905 > URL: https://issues.jboss.org/browse/ISPN-2905 > Project: Infinispan > Issue Type: Feature Request > Affects Versions: 5.2.4.Final > Reporter: Radim Vansa > Assignee: Mircea Markus > > During a topology change a lot of threads can get stuck in {{StateTransferLockImpl.waitForTransactionData}} indefinitely, due to ISPN-2808 fill up the OOB threadpool and block the topology change to be finished. > These operations should timeout after a period. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2850) CLI Synopsis[info, stats] need to be changed

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2850?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2850: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 915268|https://bugzilla.redhat.com/show_bug.cgi?id=915268] from MODIFIED to ON_QA > CLI Synopsis[info,stats] need to be changed > ------------------------------------------- > > Key: ISPN-2850 > URL: https://issues.jboss.org/browse/ISPN-2850 > Project: Infinispan > Issue Type: Bug > Components: CLI > Affects Versions: 5.2.2.Final > Reporter: Vitalii Chepeliuk > Assignee: Tristan Tarrant > Priority: Minor > Labels: testsuite_stability > Fix For: 5.2.3.Final, 5.3.0.Final > > > [disconnected//]> help info > SYNOPSIS > info [cachename] > > DESCRIPTION > Shows configuration information about the specified cache or about the active cache manager > > ARGUMENTS > cachename > (optional) the name of the cache for which the configuration will be printed. If omitted, the active cache manager's configuration will be shown > [disconnected//]> help s > site start stats > [disconnected//]> help stats > SYNOPSIS > info [cachename] > > DESCRIPTION > Shows information about the specified cache or about the active cache manager > > ARGUMENTS > cachename > (optional) the name of the cache for which information will be printed. If omitted, information about the active cache manager will be shown -- 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, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2013