March 2018 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-8494) Clear is leaking transaction with Batching

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-8494?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-8494: ------------------------------ Status: Open (was: New) > Clear is leaking transaction with Batching > ------------------------------------------ > > Key: ISPN-8494 > URL: https://issues.jboss.org/browse/ISPN-8494 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 9.3.0.Final > > > When batching is enabled, the clear() tries to suspend the running transaction but it ends leaking the internal transaction used in the batch. > {code:java} > public void testClearInBatch() { > Cache<String, String> cache = createCache("testClearInBatch"); > cache.put("k2", "value2"); > cache.startBatch(); > cache.clear(); > cache.put("k1", "value1"); > cache.endBatch(true); > // the tx is leaked and it tries to execute the get() against a committed transaction. > AssertJUnit.assertEquals(null, cache.get("k2")); > AssertJUnit.assertEquals("value1", cache.get("k1")); > } > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-8994) ClusterHealth.getHealthStatus() should take in account the internal caches.

by Katia Aresti (JIRA)

[ https://issues.jboss.org/browse/ISPN-8994?page=com.atlassian.jira.plugin.... ] Work on ISPN-8994 started by Katia Aresti. ------------------------------------------ > ClusterHealth.getHealthStatus() should take in account the internal caches. > --------------------------------------------------------------------------- > > Key: ISPN-8994 > URL: https://issues.jboss.org/browse/ISPN-8994 > Project: Infinispan > Issue Type: Bug > Components: Core > Reporter: Pedro Ruivo > Assignee: Katia Aresti > > Current implementation of {{ClusterHealth.getHealthStatus()}} only checks the user caches. Internal caches created should have be part of the cluster health and we can check them via {{InternalCacheRegistry.getInternalCaches()}}. > Also, it should use {{CacheManager.getCache(cacheName, false)}} to avoid starting the cache if it is defined but not started yet (example, the counter's internal cache is defined but it is only started when a counter is created) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-8994) ClusterHealth.getHealthStatus() should take in account the internal caches.

by Katia Aresti (JIRA)

[ https://issues.jboss.org/browse/ISPN-8994?page=com.atlassian.jira.plugin.... ] Katia Aresti reassigned ISPN-8994: ---------------------------------- Assignee: Katia Aresti > ClusterHealth.getHealthStatus() should take in account the internal caches. > --------------------------------------------------------------------------- > > Key: ISPN-8994 > URL: https://issues.jboss.org/browse/ISPN-8994 > Project: Infinispan > Issue Type: Bug > Components: Core > Reporter: Pedro Ruivo > Assignee: Katia Aresti > > Current implementation of {{ClusterHealth.getHealthStatus()}} only checks the user caches. Internal caches created should have be part of the cluster health and we can check them via {{InternalCacheRegistry.getInternalCaches()}}. > Also, it should use {{CacheManager.getCache(cacheName, false)}} to avoid starting the cache if it is defined but not started yet (example, the counter's internal cache is defined but it is only started when a counter is created) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-8994) ClusterHealth.getHealthStatus() should take in account the internal caches.

by Katia Aresti (JIRA)

[ https://issues.jboss.org/browse/ISPN-8994?page=com.atlassian.jira.plugin.... ] Katia Aresti updated ISPN-8994: ------------------------------- Status: Open (was: New) > ClusterHealth.getHealthStatus() should take in account the internal caches. > --------------------------------------------------------------------------- > > Key: ISPN-8994 > URL: https://issues.jboss.org/browse/ISPN-8994 > Project: Infinispan > Issue Type: Bug > Components: Core > Reporter: Pedro Ruivo > Assignee: Katia Aresti > > Current implementation of {{ClusterHealth.getHealthStatus()}} only checks the user caches. Internal caches created should have be part of the cluster health and we can check them via {{InternalCacheRegistry.getInternalCaches()}}. > Also, it should use {{CacheManager.getCache(cacheName, false)}} to avoid starting the cache if it is defined but not started yet (example, the counter's internal cache is defined but it is only started when a counter is created) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-8995) Don't depend on mockito-all, just mockito-core

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8995?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-8995: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Don't depend on mockito-all, just mockito-core > ---------------------------------------------- > > Key: ISPN-8995 > URL: https://issues.jboss.org/browse/ISPN-8995 > Project: Infinispan > Issue Type: Enhancement > Components: Test Suite - Core > Affects Versions: 9.2.0.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 9.2.1.Final > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-9001) Configuration file not well loaded when using JCachemanager with spring boot 2 and jcache

by Florian BERNARD (JIRA)

Florian BERNARD created ISPN-9001: ------------------------------------- Summary: Configuration file not well loaded when using JCachemanager with spring boot 2 and jcache Key: ISPN-9001 URL: https://issues.jboss.org/browse/ISPN-9001 Project: Infinispan Issue Type: Bug Affects Versions: 9.2.0.Final Reporter: Florian BERNARD I create a spring boot project on github to show the error : https://github.com/fb64/sb2-infinispan-bug -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-8996) Multi-pipeline Jenkins build

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-8996?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-8996: ------------------------------------ We may be able to do everything with a single pipeline and only multiple stages that only run on a particular branch, as Sebastian suggested. We just need to check how the duplicate test reports are handled by Jenkins. > Multi-pipeline Jenkins build > ---------------------------- > > Key: ISPN-8996 > URL: https://issues.jboss.org/browse/ISPN-8996 > Project: Infinispan > Issue Type: Bug > Components: Build, CI > Reporter: Tristan Tarrant > Fix For: 9.3.0.Alpha1 > > > We should have multiple pipelines so that we can build with different setups: > * different JDKs (JDK 8, JDK 10, JDK 11, OpenJ9) > * Different profiles (e.g. with code coverage reports, unstable) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-8962) PreferAvailabilityStrategy: Rely less on the stable topology

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-8962?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-8962: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/5866 > PreferAvailabilityStrategy: Rely less on the stable topology > ------------------------------------------------------------ > > Key: ISPN-8962 > URL: https://issues.jboss.org/browse/ISPN-8962 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.2.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.3.0.Final, 9.2.1.Final > > > {{PreferAvailabilityStrategy}} checks the size of the stable topology, and only considers cache topologies that are derived from the biggest topology (in size) when picking a post-merge topology. > Unfortunately, in some situations this algorithm fails pretty badly. If a node has a very long GC pause, when it comes back it will report the old topology *and* the old stable topology. If the rest of the cluster rebalanced, it now has both a smaller current topology and a smaller stable topology. > Furthermore, the stable topology is updated asynchronously, independent from the current topology. So even if there's a split and the minority partition installs a current topology with fewer members, it may take some time for its stable topology to be updated with fewer members. In fact, it appears that when a rebalance is not needed (e.g. because the partition has a single node), the stable topology is never updated! -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-8993) LocalTopologyManager should not install a reset topology before conflict resolution

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-8993?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-8993: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/5866 > LocalTopologyManager should not install a reset topology before conflict resolution > ----------------------------------------------------------------------------------- > > Key: ISPN-8993 > URL: https://issues.jboss.org/browse/ISPN-8993 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.2.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.2.1.Final > > > When the coordinator changes, either because the old one left or because there was a merge, the new coordinator first resets any ongoing rebalance, and then starts a rebalance with the new members. But some nodes could see the post-merge rebalance before the post-merge reset, and they need to reset any old data or inbound transfers first. > [LocalTopologyManagerImpl|https://github.com/infinispan/infinispan/blob/22...] is responsible for faking that reset topology update, in order to keep StateConsumerImpl simpler. The problem is that LocalTopologyManagerImpl also creates a reset topology update if the new coordinator started conflict resolution, and that topology update clears all the segments not owned by the local node in the preferred topology. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-1450) Improve performance of tree cache writes in nodes with a lot of data

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-1450?page=com.atlassian.jira.plugin.... ] Tristan Tarrant closed ISPN-1450. --------------------------------- Resolution: Out of Date > Improve performance of tree cache writes in nodes with a lot of data > -------------------------------------------------------------------- > > Key: ISPN-1450 > URL: https://issues.jboss.org/browse/ISPN-1450 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > > Look into speeding up tree cache performance when it comes to storing large amount of key/value pairs in a single node. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2018