January 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3944) DistSyncL1RepeatableReadFuncTest.testNoEntryInL1GetWithConcurrentReplace random failures

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3944?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3944: ------------------------------- Fix Version/s: 7.0.0.Alpha1 > DistSyncL1RepeatableReadFuncTest.testNoEntryInL1GetWithConcurrentReplace random failures > ---------------------------------------------------------------------------------------- > > Key: ISPN-3944 > URL: https://issues.jboss.org/browse/ISPN-3944 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 6.0.1.Final > Reporter: Dan Berindei > Assignee: William Burns > Labels: testsuite_stability > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > Attachments: dsl1rrft.log.gz > > > Random failure in DistSyncL1RepeatableReadFuncTest>DistSyncL1FuncTest.testNoEntryInL1GetWithConcurrentReplace: > {noformat} > 00:23:34,658 ERROR (testng-DistSyncL1RepeatableReadFuncTest:) [UnitTestTestNGListener] Test testNoEntryInL1GetWithConcurrentReplace(org.infinispan.distribution.DistSyncL1RepeatableReadFuncTest) failed. > java.lang.AssertionError: Entry for key [key-to-the-cache] should be in L1 on cache at [NodeA-57647]! > at org.infinispan.distribution.DistributionTestHelper.assertIsInL1(DistributionTestHelper.java:31) > at org.infinispan.distribution.BaseDistFunctionalTest.assertIsInL1(BaseDistFunctionalTest.java:183) > at org.infinispan.distribution.DistSyncL1FuncTest.testNoEntryInL1GetWithConcurrentReplace(DistSyncL1FuncTest.java:193) > {noformat} -- 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

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3736) Backport to 5.2.x for EAP 6.3

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3736?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3736: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done Integrated :) > Backport to 5.2.x for EAP 6.3 > ----------------------------- > > Key: ISPN-3736 > URL: https://issues.jboss.org/browse/ISPN-3736 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 5.2.7.Final > Reporter: Paul Ferraro > Assignee: Dan Berindei > Fix For: 5.2.8.Final > > > This JIRA will track the issues that need to be backported to the 5.2.x branch for EAP 6.3. -- 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

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3903) Transaction Code Optimizations

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-3903?page=com.atlassian.jira.plugin.... ] Sanne Grinovero commented on ISPN-3903: --------------------------------------- Nice! :-) > Transaction Code Optimizations > ------------------------------ > > Key: ISPN-3903 > URL: https://issues.jboss.org/browse/ISPN-3903 > Project: Infinispan > Issue Type: Enhancement > Components: Transactions > Affects Versions: 6.0.1.Final > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 7.0.0.Alpha1 > > > Currently, I found the following problems (so far, last update 18/01, 17h30, fix in progress): > * the LocalTxInvocationContext is creating an empty map every time a new instance is created. It originates >10GB of data in 5min. It can use the Collections.emptyMap() > * TransactionCoordinator is creating LocalTxInvocationContext twice when commit. First, prepare() method creates LocalTxInvocationContext and if it is read only, it invokes commitInternal (that will create a new LocalTxInvocationContext). The same for commit() method when the transaction is one phase. commitInternal() can reuse the LocalTxInvocationContext since they are stateless (and they already have a reference for the LocalTransaction). > * Refactor LocalTxInvocationContext and RemoteTxInvocationContext > Results (for 5 min profiling): > * HashMap allocation reduced from 20.80GB to 3.76GB > * LocalTxInvocationContext allocation reduced from 13.80GB to 7.44GB -- 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

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3948) Missing logic to add the store for custom stores

by Kurt Lehrke (JIRA)

Kurt Lehrke created ISPN-3948: --------------------------------- Summary: Missing logic to add the store for custom stores Key: ISPN-3948 URL: https://issues.jboss.org/browse/ISPN-3948 Project: Infinispan Issue Type: Bug Components: Configuration, Loaders and Stores Affects Versions: 6.0.0.Final Reporter: Kurt Lehrke Assignee: Dan Berindei Looking at the Parser60 class, if you specify a custom store that isn't a singleFileStore or a clusterLoader, the store doesn't get added to the configuration. I found this when I specified my own CacheLoader and it wasn't instantiated like expected. -- 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

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3948) Missing logic to add the store to the configuration for custom stores

by Kurt Lehrke (JIRA)

[ https://issues.jboss.org/browse/ISPN-3948?page=com.atlassian.jira.plugin.... ] Kurt Lehrke updated ISPN-3948: ------------------------------ Summary: Missing logic to add the store to the configuration for custom stores (was: Missing logic to add the store for custom stores) > Missing logic to add the store to the configuration for custom stores > --------------------------------------------------------------------- > > Key: ISPN-3948 > URL: https://issues.jboss.org/browse/ISPN-3948 > Project: Infinispan > Issue Type: Bug > Components: Configuration, Loaders and Stores > Affects Versions: 6.0.0.Final > Reporter: Kurt Lehrke > Assignee: Dan Berindei > > Looking at the Parser60 class, if you specify a custom store that isn't a singleFileStore or a clusterLoader, the store doesn't get added to the configuration. I found this when I specified my own CacheLoader and it wasn't instantiated like expected. -- 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

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3944) DistSyncL1RepeatableReadFuncTest.testNoEntryInL1GetWithConcurrentReplace random failures

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3944?page=com.atlassian.jira.plugin.... ] Work on ISPN-3944 started by William Burns. > DistSyncL1RepeatableReadFuncTest.testNoEntryInL1GetWithConcurrentReplace random failures > ---------------------------------------------------------------------------------------- > > Key: ISPN-3944 > URL: https://issues.jboss.org/browse/ISPN-3944 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 6.0.1.Final > Reporter: Dan Berindei > Assignee: William Burns > Labels: testsuite_stability > Fix For: 7.0.0.Final > > Attachments: dsl1rrft.log.gz > > > Random failure in DistSyncL1RepeatableReadFuncTest>DistSyncL1FuncTest.testNoEntryInL1GetWithConcurrentReplace: > {noformat} > 00:23:34,658 ERROR (testng-DistSyncL1RepeatableReadFuncTest:) [UnitTestTestNGListener] Test testNoEntryInL1GetWithConcurrentReplace(org.infinispan.distribution.DistSyncL1RepeatableReadFuncTest) failed. > java.lang.AssertionError: Entry for key [key-to-the-cache] should be in L1 on cache at [NodeA-57647]! > at org.infinispan.distribution.DistributionTestHelper.assertIsInL1(DistributionTestHelper.java:31) > at org.infinispan.distribution.BaseDistFunctionalTest.assertIsInL1(BaseDistFunctionalTest.java:183) > at org.infinispan.distribution.DistSyncL1FuncTest.testNoEntryInL1GetWithConcurrentReplace(DistSyncL1FuncTest.java:193) > {noformat} -- 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

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3944) DistSyncL1RepeatableReadFuncTest.testNoEntryInL1GetWithConcurrentReplace random failures

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3944?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3944: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/2356 > DistSyncL1RepeatableReadFuncTest.testNoEntryInL1GetWithConcurrentReplace random failures > ---------------------------------------------------------------------------------------- > > Key: ISPN-3944 > URL: https://issues.jboss.org/browse/ISPN-3944 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 6.0.1.Final > Reporter: Dan Berindei > Assignee: William Burns > Labels: testsuite_stability > Fix For: 7.0.0.Final > > Attachments: dsl1rrft.log.gz > > > Random failure in DistSyncL1RepeatableReadFuncTest>DistSyncL1FuncTest.testNoEntryInL1GetWithConcurrentReplace: > {noformat} > 00:23:34,658 ERROR (testng-DistSyncL1RepeatableReadFuncTest:) [UnitTestTestNGListener] Test testNoEntryInL1GetWithConcurrentReplace(org.infinispan.distribution.DistSyncL1RepeatableReadFuncTest) failed. > java.lang.AssertionError: Entry for key [key-to-the-cache] should be in L1 on cache at [NodeA-57647]! > at org.infinispan.distribution.DistributionTestHelper.assertIsInL1(DistributionTestHelper.java:31) > at org.infinispan.distribution.BaseDistFunctionalTest.assertIsInL1(BaseDistFunctionalTest.java:183) > at org.infinispan.distribution.DistSyncL1FuncTest.testNoEntryInL1GetWithConcurrentReplace(DistSyncL1FuncTest.java:193) > {noformat} -- 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

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3947) HotRod client keep trying recover connections to a failed cluster

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3947?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-3947: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1058887 > HotRod client keep trying recover connections to a failed cluster > ----------------------------------------------------------------- > > Key: ISPN-3947 > URL: https://issues.jboss.org/browse/ISPN-3947 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Affects Versions: 6.0.1.Final, 7.0.0.Alpha1 > Reporter: Wolf-Dieter Fink > Assignee: Galder Zamarreño > Labels: hotrod, hotrod-java-client > > If an infinispan-server cluster is not longer reachable for some reason, i.e. network disconnect, the hot-rod client try to re-establish the lost connections. > The client library will retry this by a fixed calculation based on the max numbers of connections from the pool or 10 multiplied with the number of available servers. > This can lead in a very long time until the application can continue and react as it will wait for the read- or connect-timeout for each try. > To improve this behaviour there should be a configurable limit of retries per server and/or a timeout in total. > This will give the application the chance to handle a remote-cache failure and reply to the user instead of hanging for minutes (with the default settings) -- 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

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3944) DistSyncL1RepeatableReadFuncTest.testNoEntryInL1GetWithConcurrentReplace random failures

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3944?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-3944: ------------------------------------- This is caused due to the following: * Previous test performs a get which sends 2 ClusteredGetCommands. * Backup owner responds with value and test completes (primary hasn't received yet) * New test starts with cleared data * Test does a put of the key into the cache (put sends no L1 invalidations since no requestors) * ClusteredGet arrives at primary owner and registers requestor * Put gets to L1LastChanceInterceptor and sends L1 Invalidation asynchronously * Test performs get to retrieve value from owners * L1 invalidation arrives at node and causes the L1 to not persist. Technically this is a test failure and the production code is fine. However to make tests easier we decided to change L1LastChanceInterceptor to be synchronous for non tx caches as well. L1LastChanceInterceptor should not fire often and as such this shouldn't cause barely any noticeable impact if any. > DistSyncL1RepeatableReadFuncTest.testNoEntryInL1GetWithConcurrentReplace random failures > ---------------------------------------------------------------------------------------- > > Key: ISPN-3944 > URL: https://issues.jboss.org/browse/ISPN-3944 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 6.0.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: testsuite_stability > Fix For: 7.0.0.Final > > Attachments: dsl1rrft.log.gz > > > Random failure in DistSyncL1RepeatableReadFuncTest>DistSyncL1FuncTest.testNoEntryInL1GetWithConcurrentReplace: > {noformat} > 00:23:34,658 ERROR (testng-DistSyncL1RepeatableReadFuncTest:) [UnitTestTestNGListener] Test testNoEntryInL1GetWithConcurrentReplace(org.infinispan.distribution.DistSyncL1RepeatableReadFuncTest) failed. > java.lang.AssertionError: Entry for key [key-to-the-cache] should be in L1 on cache at [NodeA-57647]! > at org.infinispan.distribution.DistributionTestHelper.assertIsInL1(DistributionTestHelper.java:31) > at org.infinispan.distribution.BaseDistFunctionalTest.assertIsInL1(BaseDistFunctionalTest.java:183) > at org.infinispan.distribution.DistSyncL1FuncTest.testNoEntryInL1GetWithConcurrentReplace(DistSyncL1FuncTest.java:193) > {noformat} -- 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

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3944) DistSyncL1RepeatableReadFuncTest.testNoEntryInL1GetWithConcurrentReplace random failures

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3944?page=com.atlassian.jira.plugin.... ] William Burns reassigned ISPN-3944: ----------------------------------- Assignee: William Burns (was: Dan Berindei) > DistSyncL1RepeatableReadFuncTest.testNoEntryInL1GetWithConcurrentReplace random failures > ---------------------------------------------------------------------------------------- > > Key: ISPN-3944 > URL: https://issues.jboss.org/browse/ISPN-3944 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 6.0.1.Final > Reporter: Dan Berindei > Assignee: William Burns > Labels: testsuite_stability > Fix For: 7.0.0.Final > > Attachments: dsl1rrft.log.gz > > > Random failure in DistSyncL1RepeatableReadFuncTest>DistSyncL1FuncTest.testNoEntryInL1GetWithConcurrentReplace: > {noformat} > 00:23:34,658 ERROR (testng-DistSyncL1RepeatableReadFuncTest:) [UnitTestTestNGListener] Test testNoEntryInL1GetWithConcurrentReplace(org.infinispan.distribution.DistSyncL1RepeatableReadFuncTest) failed. > java.lang.AssertionError: Entry for key [key-to-the-cache] should be in L1 on cache at [NodeA-57647]! > at org.infinispan.distribution.DistributionTestHelper.assertIsInL1(DistributionTestHelper.java:31) > at org.infinispan.distribution.BaseDistFunctionalTest.assertIsInL1(BaseDistFunctionalTest.java:183) > at org.infinispan.distribution.DistSyncL1FuncTest.testNoEntryInL1GetWithConcurrentReplace(DistSyncL1FuncTest.java:193) > {noformat} -- 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

10 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2014