February 2013 - infinispan-issues

[JBoss JIRA] (ISPN-2658) org.infinispan.marshall.MarshalledValueTest.testModificationsOnSameCustomKey fails constantly on all environments

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-2658?page=com.atlassian.jira.plugin.... ] Adrian Nistor reopened ISPN-2658: --------------------------------- Re-occurred. Will add logs soon. > org.infinispan.marshall.MarshalledValueTest.testModificationsOnSameCustomKey fails constantly on all environments > ------------------------------------------------------------------------------------------------------------------ > > Key: ISPN-2658 > URL: https://issues.jboss.org/browse/ISPN-2658 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.2.0.Beta6 > Reporter: Anna Manukyan > Assignee: Galder Zamarreño > Labels: testsuite_stability > Fix For: 5.2.0.CR1 > > Attachments: testModificationsOnSameCustomKey-2.log > > > org.infinispan.marshall.MarshalledValueTest.testModificationsOnSameCustomKey test fails on all environments (RHEL, Windows, Solaris - JDK7, Open JDK7, IBM JDK7). > The error message is: > {code} > Error Message > Serialization count: expected 4 but was 5 > Stacktrace > java.lang.AssertionError: Serialization count: expected 4 but was 5 > at org.infinispan.marshall.MarshalledValueTest.assertSerializationCounts(MarshalledValueTest.java:135) > at org.infinispan.marshall.MarshalledValueTest.testModificationsOnSameCustomKey(MarshalledValueTest.java:452) > 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2803) Memory leak on every cache write.operation

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-2803?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-2803: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done Integrated. Thanks! > Memory leak on every cache write.operation > ------------------------------------------ > > Key: ISPN-2803 > URL: https://issues.jboss.org/browse/ISPN-2803 > Project: Infinispan > Issue Type: Bug > Components: Core API > Affects Versions: 5.2.0.Final > Reporter: Erik Salter > Assignee: Erik Salter > Priority: Blocker > Fix For: 5.2.1, 5.3.0.Alpha1 > > > Every cache write operation in a steady state (no state transfer) will write a copy of the key to StateConsumerImpl::updatedKey set. This set is intended to be null during steady state, but it is erroneously being created on a CH_UPDATE with a pendingCH of null. > These keys are not removed during a cache remove operation. > When enough keys are written to the cache, the container will OOM. -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2803) Memory leak on every cache write.operation

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-2803?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-2803: -------------------------------- Component/s: State transfer > Memory leak on every cache write.operation > ------------------------------------------ > > Key: ISPN-2803 > URL: https://issues.jboss.org/browse/ISPN-2803 > Project: Infinispan > Issue Type: Bug > Components: Core API, State transfer > Affects Versions: 5.2.0.Final > Reporter: Erik Salter > Assignee: Erik Salter > Priority: Blocker > Fix For: 5.2.1, 5.3.0.Alpha1 > > > Every cache write operation in a steady state (no state transfer) will write a copy of the key to StateConsumerImpl::updatedKey set. This set is intended to be null during steady state, but it is erroneously being created on a CH_UPDATE with a pendingCH of null. > These keys are not removed during a cache remove operation. > When enough keys are written to the cache, the container will OOM. -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2803) Memory leak on every cache write.operation

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-2803?page=com.atlassian.jira.plugin.... ] Adrian Nistor reassigned ISPN-2803: ----------------------------------- Assignee: Erik Salter (was: Mircea Markus) > Memory leak on every cache write.operation > ------------------------------------------ > > Key: ISPN-2803 > URL: https://issues.jboss.org/browse/ISPN-2803 > Project: Infinispan > Issue Type: Bug > Components: Core API > Affects Versions: 5.2.0.Final > Reporter: Erik Salter > Assignee: Erik Salter > Priority: Blocker > Fix For: 5.2.1, 5.3.0.Alpha1 > > > Every cache write operation in a steady state (no state transfer) will write a copy of the key to StateConsumerImpl::updatedKey set. This set is intended to be null during steady state, but it is erroneously being created on a CH_UPDATE with a pendingCH of null. > These keys are not removed during a cache remove operation. > When enough keys are written to the cache, the container will OOM. -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2803) Memory leak on every cache write.operation

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-2803?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-2803: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/1648, https://github.com/infinispan/infinispan/pull/1649 > Memory leak on every cache write.operation > ------------------------------------------ > > Key: ISPN-2803 > URL: https://issues.jboss.org/browse/ISPN-2803 > Project: Infinispan > Issue Type: Bug > Components: Core API > Affects Versions: 5.2.0.Final > Reporter: Erik Salter > Assignee: Erik Salter > Priority: Blocker > Fix For: 5.2.1, 5.3.0.Alpha1 > > > Every cache write operation in a steady state (no state transfer) will write a copy of the key to StateConsumerImpl::updatedKey set. This set is intended to be null during steady state, but it is erroneously being created on a CH_UPDATE with a pendingCH of null. > These keys are not removed during a cache remove operation. > When enough keys are written to the cache, the container will OOM. -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2803) Memory leak on every cache write.operation

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-2803?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-2803: -------------------------------- Priority: Blocker (was: Major) > Memory leak on every cache write.operation > ------------------------------------------ > > Key: ISPN-2803 > URL: https://issues.jboss.org/browse/ISPN-2803 > Project: Infinispan > Issue Type: Bug > Components: Core API > Affects Versions: 5.2.0.Final > Reporter: Erik Salter > Assignee: Mircea Markus > Priority: Blocker > Fix For: 5.2.1, 5.3.0.Alpha1 > > > Every cache write operation in a steady state (no state transfer) will write a copy of the key to StateConsumerImpl::updatedKey set. This set is intended to be null during steady state, but it is erroneously being created on a CH_UPDATE with a pendingCH of null. > These keys are not removed during a cache remove operation. > When enough keys are written to the cache, the container will OOM. -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2803) Memory leak on every cache write.operation

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-2803?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-2803: -------------------------------- Fix Version/s: 5.2.1 5.3.0.Alpha1 > Memory leak on every cache write.operation > ------------------------------------------ > > Key: ISPN-2803 > URL: https://issues.jboss.org/browse/ISPN-2803 > Project: Infinispan > Issue Type: Bug > Components: Core API > Affects Versions: 5.2.0.Final > Reporter: Erik Salter > Assignee: Mircea Markus > Fix For: 5.2.1, 5.3.0.Alpha1 > > > Every cache write operation in a steady state (no state transfer) will write a copy of the key to StateConsumerImpl::updatedKey set. This set is intended to be null during steady state, but it is erroneously being created on a CH_UPDATE with a pendingCH of null. > These keys are not removed during a cache remove operation. > When enough keys are written to the cache, the container will OOM. -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2803) Memory leak on every cache write.operation

by Erik Salter (JIRA)

Erik Salter created ISPN-2803: --------------------------------- Summary: Memory leak on every cache write.operation Key: ISPN-2803 URL: https://issues.jboss.org/browse/ISPN-2803 Project: Infinispan Issue Type: Bug Components: Core API Affects Versions: 5.2.0.Final Reporter: Erik Salter Assignee: Mircea Markus Every cache write operation in a steady state (no state transfer) will write a copy of the key to StateConsumerImpl::updatedKey set. This set is intended to be null during steady state, but it is erroneously being created on a CH_UPDATE with a pendingCH of null. These keys are not removed during a cache remove operation. When enough keys are written to the cache, the container will OOM. -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2802) Cache recovery fails due to missing responses

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-2802?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-2802: ----------------------------------- Honestly I don't know if it is anything in JGroups, or combination of configuration on the particular machines. I have similar test on less nodes (the above is on 32 nodes) which does not exhibit the issue. When everything gets stuck, I often find many threads waiting on the synchronized(c) in org.apache.log4j.Category.callAppenders(org.apache.log4j.spi.LoggingEvent) > Cache recovery fails due to missing responses > --------------------------------------------- > > Key: ISPN-2802 > URL: https://issues.jboss.org/browse/ISPN-2802 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.2.0.CR3 > Reporter: Radim Vansa > Assignee: Mircea Markus > > When the cache recovery is started, the new coordinator sends CacheTopologyControlCommand.GET_STATUS to all nodes and waits for responses. However, I have a reproducible test-case where it always times out waiting for the responses. > Here are the logs (TRACE is not doable here, but I added some byteman traces - see topology.btm in the archive): http://dl.dropbox.com/u/103079234/recovery.zip > The problematic spot is on node3 at 05:37:57 receiving cluster view 34. > All nodes (except the one which is killed, in this case node1) respond quickly to the GET_STATUS command (see BYTEMAN Receiving - Received pairs, these are bound to command execution in CommandAwareRpcDispatcher), but some responses are not received on node3 (look for Receiving rsp bound to GroupRequest). > JGroups tracing could be useful here but it is not available (intensive logging often blocks on internal log4j locks and the node becomes unresponsive). > As mentioned above, the case is reproducible, therefore if you can suggest any particular BYTEMAN hook, I can try it. -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2802) Cache recovery fails due to missing responses

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/ISPN-2802?page=com.atlassian.jira.plugin.... ] Bela Ban commented on ISPN-2802: -------------------------------- If you think this is a JGroups issue, can you create a reproducible test that shows the issue ? Re log4j: do you know where the blocking happens ? I'd like to take a look... > Cache recovery fails due to missing responses > --------------------------------------------- > > Key: ISPN-2802 > URL: https://issues.jboss.org/browse/ISPN-2802 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.2.0.CR3 > Reporter: Radim Vansa > Assignee: Mircea Markus > > When the cache recovery is started, the new coordinator sends CacheTopologyControlCommand.GET_STATUS to all nodes and waits for responses. However, I have a reproducible test-case where it always times out waiting for the responses. > Here are the logs (TRACE is not doable here, but I added some byteman traces - see topology.btm in the archive): http://dl.dropbox.com/u/103079234/recovery.zip > The problematic spot is on node3 at 05:37:57 receiving cluster view 34. > All nodes (except the one which is killed, in this case node1) respond quickly to the GET_STATUS command (see BYTEMAN Receiving - Received pairs, these are bound to command execution in CommandAwareRpcDispatcher), but some responses are not received on node3 (look for Receiving rsp bound to GroupRequest). > JGroups tracing could be useful here but it is not available (intensive logging often blocks on internal log4j locks and the node becomes unresponsive). > As mentioned above, the case is reproducible, therefore if you can suggest any particular BYTEMAN hook, I can try it. -- 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

13 years, 2 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 February 2013