April 2018 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-9093) Samples from query docs should not be affected by branding

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-9093?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-9093: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/5932 > Samples from query docs should not be affected by branding > ---------------------------------------------------------- > > Key: ISPN-9093 > URL: https://issues.jboss.org/browse/ISPN-9093 > Project: Infinispan > Issue Type: Bug > Components: Documentation-Query > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 9.3.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9093) Samples from query docs should not be affected by branding

by Adrian Nistor (JIRA)

Adrian Nistor created ISPN-9093: ----------------------------------- Summary: Samples from query docs should not be affected by branding Key: ISPN-9093 URL: https://issues.jboss.org/browse/ISPN-9093 Project: Infinispan Issue Type: Bug Components: Documentation-Query Reporter: Adrian Nistor Fix For: 9.3.0.Alpha1 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9093) Samples from query docs should not be affected by branding

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-9093?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-9093: -------------------------------- Status: Open (was: New) > Samples from query docs should not be affected by branding > ---------------------------------------------------------- > > Key: ISPN-9093 > URL: https://issues.jboss.org/browse/ISPN-9093 > Project: Infinispan > Issue Type: Bug > Components: Documentation-Query > Reporter: Adrian Nistor > Fix For: 9.3.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9093) Samples from query docs should not be affected by branding

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-9093?page=com.atlassian.jira.plugin.... ] Adrian Nistor reassigned ISPN-9093: ----------------------------------- Assignee: Adrian Nistor > Samples from query docs should not be affected by branding > ---------------------------------------------------------- > > Key: ISPN-9093 > URL: https://issues.jboss.org/browse/ISPN-9093 > Project: Infinispan > Issue Type: Bug > Components: Documentation-Query > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 9.3.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

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 reopened ISPN-8962: -------------------------------- I changed the algorithm to prefer the topology with the higher topology id when 2 topologies are overlapping, and the topology with the most members when they are completely independent. I kept the overlapping topologies with a lower topology id and with at least {{numOwners}} extra members for conflict resolution, because it signals the partition with the highest topology id might have lost some values that still exist in the nodes with the lower topology id. The problem is that this older topology has the most members and ends up being the preferred topology. It's not a big issue when conflict resolution is enabled, but when conflict resolution is disabled it means different nodes will see different values. This is actually shown by test {{PreferAvailabilityStrategyTest#testMerge1Paused2StableAfterLosingAnotherNode}}, but at the time I wrote it I was only trying to prove that conflict resolution would happen (if enabled). 1. Start with cluster ABC 1. A was paused and keeps the stable topology 1. B and C finished rebalancing, then B was paused 1. Now A has resumed and merges with C 1. The preferred topology should be \[C\] (from C), but it's \[ABC\] (from A) > 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.2.2.Final, 9.3.0.Alpha1 > > > {{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)

6 years, 8 months

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 updated ISPN-8996: ------------------------------- Status: Open (was: New) > 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 > Assignee: Dan Berindei > 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)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9080) Distributed cache stream should wait for new topology when segments aren't complete

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-9080?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9080: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Distributed cache stream should wait for new topology when segments aren't complete > ----------------------------------------------------------------------------------- > > Key: ISPN-9080 > URL: https://issues.jboss.org/browse/ISPN-9080 > Project: Infinispan > Issue Type: Bug > Components: Streams > Affects Versions: 9.2.1.Final, 9.1.7.Final > Reporter: William Burns > Assignee: William Burns > Fix For: 9.2.2.Final, 9.3.0.Alpha1 > > > Distributed streams can get stuck in infinite loop, wasting CPU if a new toplogy is never installed. This affects all cache modes (scattered, dist and repl). > We should add a wait for the next topology when we complete a loop and not all segments are completed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9085) Add forEach taking IntConsumer to IntSet

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-9085?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9085: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Add forEach taking IntConsumer to IntSet > ---------------------------------------- > > Key: ISPN-9085 > URL: https://issues.jboss.org/browse/ISPN-9085 > Project: Infinispan > Issue Type: Task > Components: Core > Reporter: William Burns > Assignee: William Burns > Fix For: 9.3.0.Alpha1 > > > The IntSet class is still missing some methods that have primitive int variants, such as intSpliterator, forEach(IntConsumer), removeIf(IntPredicate). These should be simple to add and actually forEach can be used in a few places. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9092) Upgrade Protostream to 4.2.0.Final

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-9092?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9092: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Upgrade Protostream to 4.2.0.Final > ---------------------------------- > > Key: ISPN-9092 > URL: https://issues.jboss.org/browse/ISPN-9092 > Project: Infinispan > Issue Type: Component Upgrade > Components: Remote Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 9.2.2.Final, 9.3.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9092) Upgrade Protostream to 4.2.0.Final

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-9092?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9092: ---------------------------------- Sprint: Sprint 9.3.0.Alpha1 > Upgrade Protostream to 4.2.0.Final > ---------------------------------- > > Key: ISPN-9092 > URL: https://issues.jboss.org/browse/ISPN-9092 > Project: Infinispan > Issue Type: Component Upgrade > Components: Remote Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 9.2.2.Final, 9.3.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues April 2018