February 2013 - infinispan-issues

[JBoss JIRA] (ISPN-2823) TransactionManagerLookup is silently ignored with invocation batching

by Jeremy Stone (JIRA)

Jeremy Stone created ISPN-2823: ---------------------------------- Summary: TransactionManagerLookup is silently ignored with invocation batching Key: ISPN-2823 URL: https://issues.jboss.org/browse/ISPN-2823 Project: Infinispan Issue Type: Feature Request Components: Core API, Transactions Affects Versions: 5.2.1.Final, 5.2.0.Final Reporter: Jeremy Stone Assignee: Mircea Markus A configured TransactionManagerLookup is ignored when invocation batching is enabled. Attempts to put an entry into the cache are greeted with "java.lang.IllegalStateException: This is a tx cache!" despite the presence of an active transaction. This seems to make it impossible to use the Tree API, where invocation batch mode is mandatory, in a transactional environment. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2586) Asynchronous FileCacheStore uses a JBossMarshaller with a null ExternalizerTable

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2586?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2586: -------------------------------- Assignee: Tristan Tarrant (was: Galder Zamarreño) > Asynchronous FileCacheStore uses a JBossMarshaller with a null ExternalizerTable > -------------------------------------------------------------------------------- > > Key: ISPN-2586 > URL: https://issues.jboss.org/browse/ISPN-2586 > Project: Infinispan > Issue Type: Bug > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 5.2.2.Final, 5.3.0.Final > > -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2577) Silence SuspectExceptions

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2577?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2577: -------------------------------- Fix Version/s: (was: 5.2.2.Final) > Silence SuspectExceptions > ------------------------- > > Key: ISPN-2577 > URL: https://issues.jboss.org/browse/ISPN-2577 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.2.0.Beta4 > Reporter: Michal Linhard > Assignee: Dan Berindei > Fix For: 5.3.0.Final > > > There are lots of SuspectExceptions in resilience test run: > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EDG6/view/EDG-REPOR... > We managed to keep these under cover for 5.1.x branch. > This is of course a cosmetic problem, but it polutes the log with unnecessary ERRORs. > Parsed logs here: > http://www.qa.jboss.com/~mlinhard/test_results/run54-parsed/ -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2792) Allow logging at TRACE level for a single test in the test suite

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-2792?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-2792: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/1661 > Allow logging at TRACE level for a single test in the test suite > ---------------------------------------------------------------- > > Key: ISPN-2792 > URL: https://issues.jboss.org/browse/ISPN-2792 > Project: Infinispan > Issue Type: Enhancement > Components: Test Suite > Affects Versions: 5.2.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Minor > Fix For: 5.2.2, 5.3.0.Alpha1 > > > Log4J has support for [filters|http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/spi/...] that can allow or disallow log messages based on their properties, e.g. the thread name. > Since the names of most threads in the test suite include the test name, we should create a filter that only allows a log message if the thread name matches a regular expression. > There are some threads that don't follow this rule, e.g. the HotRod worker threads, but it should be useful in most cases. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2790) ReplCommandForwardingTest fails most of the time in CI

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-2790?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-2790: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/1661 > ReplCommandForwardingTest fails most of the time in CI > ------------------------------------------------------ > > Key: ISPN-2790 > URL: https://issues.jboss.org/browse/ISPN-2790 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Affects Versions: 5.2.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: testsuite_stability > Fix For: 5.2.2, 5.3.0.Alpha1 > > > ReplCommandForwardingTest seems to fail every single time in CloudBees. > As I have never seen it fail on my machine, I'm assuming this is a timing issue and I'm going to increase the timeouts in the test. -- 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, 1 month

1
0
0 / 0

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

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2803?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2803: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> made a comment on [bug 910768|https://bugzilla.redhat.com/show_bug.cgi?id=910768] Infinispan 5.2.0.Final had two severe memory leak issues which required a new release. We should verify that these leaks are gone in the product as well > 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, 1 month

1
0
0 / 0

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

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2803?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2803: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 910768|https://bugzilla.redhat.com/show_bug.cgi?id=910768] from NEW to ASSIGNED > 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, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2804) Memory Leak: TransactionTable never cleans up complete transactions

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2804?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2804: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 910768|https://bugzilla.redhat.com/show_bug.cgi?id=910768] from NEW to ASSIGNED > Memory Leak: TransactionTable never cleans up complete transactions > ------------------------------------------------------------------- > > Key: ISPN-2804 > URL: https://issues.jboss.org/browse/ISPN-2804 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 5.2.0.Final > Reporter: Erik Salter > Assignee: Erik Salter > Priority: Blocker > Fix For: 5.2.1, 5.3.0.Alpha1 > > > When a transaction commits, we mark it as completed in markCompletedTransaction(). The issue is this map is never cleaned up -- there is no call to cleanupCompletedTransactions(). > (Was this supposed to replace the StaleTransactionCleanupService?) > So the transaction (and address and UUID object) leak for every transaction, until the node OOMs. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2804) Memory Leak: TransactionTable never cleans up complete transactions

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2804?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-2804: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=910768 > Memory Leak: TransactionTable never cleans up complete transactions > ------------------------------------------------------------------- > > Key: ISPN-2804 > URL: https://issues.jboss.org/browse/ISPN-2804 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 5.2.0.Final > Reporter: Erik Salter > Assignee: Erik Salter > Priority: Blocker > Fix For: 5.2.1, 5.3.0.Alpha1 > > > When a transaction commits, we mark it as completed in markCompletedTransaction(). The issue is this map is never cleaned up -- there is no call to cleanupCompletedTransactions(). > (Was this supposed to replace the StaleTransactionCleanupService?) > So the transaction (and address and UUID object) leak for every transaction, until the node OOMs. -- 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, 1 month

1
0
0 / 0

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

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2803?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-2803: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=910768 > 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, 1 month

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