March 2017 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-7669) Evaluated DataContainer size method invocations to make sure they make sense

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-7669?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-7669: -------------------------------- Status: Open (was: New) > Evaluated DataContainer size method invocations to make sure they make sense > ---------------------------------------------------------------------------- > > Key: ISPN-7669 > URL: https://issues.jboss.org/browse/ISPN-7669 > Project: Infinispan > Issue Type: Bug > Components: Core, Loaders and Stores > Reporter: William Burns > Assignee: William Burns > > In an attempt to improve spliterator performance we try to give it an estimate of the size. Currently this is calling DataContainer.size which in fact is anything but performant as it requires O(N) time to make sure to not count entries that are expired. We should instead call sizeIncludingExpired as this is O(1) and this is a best guess anyways, doesn't need to be exact. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7669) Evaluated DataContainer size method invocations to make sure they make sense

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-7669?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-7669: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/5019 > Evaluated DataContainer size method invocations to make sure they make sense > ---------------------------------------------------------------------------- > > Key: ISPN-7669 > URL: https://issues.jboss.org/browse/ISPN-7669 > Project: Infinispan > Issue Type: Bug > Components: Core, Loaders and Stores > Reporter: William Burns > Assignee: William Burns > > In an attempt to improve spliterator performance we try to give it an estimate of the size. Currently this is calling DataContainer.size which in fact is anything but performant as it requires O(N) time to make sure to not count entries that are expired. We should instead call sizeIncludingExpired as this is O(1) and this is a best guess anyways, doesn't need to be exact. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7659) Infinispan doesn't build with the latest OpenJDK 9 early access builds

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-7659?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-7659: ------------------------------- Status: Open (was: New) > Infinispan doesn't build with the latest OpenJDK 9 early access builds > ---------------------------------------------------------------------- > > Key: ISPN-7659 > URL: https://issues.jboss.org/browse/ISPN-7659 > Project: Infinispan > Issue Type: Bug > Components: Build process > Affects Versions: 9.0.0.CR3 > Reporter: Dan Berindei > Assignee: Dan Berindei > > Tried with builds 146 and 161, both fail to build even the commons module with a cryptic "Compilation failure" error. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7659) Infinispan doesn't build with the latest OpenJDK 9 early access builds

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-7659?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-7659: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/5018 > Infinispan doesn't build with the latest OpenJDK 9 early access builds > ---------------------------------------------------------------------- > > Key: ISPN-7659 > URL: https://issues.jboss.org/browse/ISPN-7659 > Project: Infinispan > Issue Type: Bug > Components: Build process > Affects Versions: 9.0.0.CR3 > Reporter: Dan Berindei > Assignee: Dan Berindei > > Tried with builds 146 and 161, both fail to build even the commons module with a cryptic "Compilation failure" error. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7668) Merge implementation is not correct on SimpleCache

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-7668?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-7668: ------------------------------ Status: Open (was: New) > Merge implementation is not correct on SimpleCache > -------------------------------------------------- > > Key: ISPN-7668 > URL: https://issues.jboss.org/browse/ISPN-7668 > Project: Infinispan > Issue Type: Bug > Components: Core > Reporter: Katia Aresti > Assignee: Radim Vansa > > Merge method is not correctly implemented in SimpleCache. > Merge should work this way : > * if the key is not present, add the value > * If the key is present, apply the function between the existing key's value and the given value and replace the key with the merged result > * If the merge function returns null, remove the key > The case that should work as "putIfAbsent" does't work. Merge function is applied to null and the given value. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7669) Evaluated DataContainer size method invocations to make sure they make sense

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-7669?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-7669: -------------------------------- Summary: Evaluated DataContainer size method invocations to make sure they make sense (was: CacheLoader bulk methods are using inefficient size from DataContainer) > Evaluated DataContainer size method invocations to make sure they make sense > ---------------------------------------------------------------------------- > > Key: ISPN-7669 > URL: https://issues.jboss.org/browse/ISPN-7669 > Project: Infinispan > Issue Type: Bug > Components: Core, Loaders and Stores > Reporter: William Burns > Assignee: William Burns > > In an attempt to improve spliterator performance we try to give it an estimate of the size. Currently this is calling DataContainer.size which in fact is anything but performant as it requires O(N) time to make sure to not count entries that are expired. We should instead call sizeIncludingExpired as this is O(1) and this is a best guess anyways, doesn't need to be exact. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7669) CacheLoader bulk methods are using inefficient size from DataContainer

by William Burns (JIRA)

William Burns created ISPN-7669: ----------------------------------- Summary: CacheLoader bulk methods are using inefficient size from DataContainer Key: ISPN-7669 URL: https://issues.jboss.org/browse/ISPN-7669 Project: Infinispan Issue Type: Bug Components: Core, Loaders and Stores Reporter: William Burns Assignee: William Burns In an attempt to improve spliterator performance we try to give it an estimate of the size. Currently this is calling DataContainer.size which in fact is anything but performant as it requires O(N) time to make sure to not count entries that are expired. We should instead call sizeIncludingExpired as this is O(1) and this is a best guess anyways, doesn't need to be exact. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7656) DefaultDataContainer.entrySet().stream().toArray(Object[]::new) may fail

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-7656?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-7656: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/5011 > DefaultDataContainer.entrySet().stream().toArray(Object[]::new) may fail > ------------------------------------------------------------------------ > > Key: ISPN-7656 > URL: https://issues.jboss.org/browse/ISPN-7656 > Project: Infinispan > Issue Type: Bug > Components: Core > Reporter: Radim Vansa > Assignee: William Burns > Fix For: 9.0.0.Final > > > When the default Spliterator estimates size of the array, it calls {{DefaultDataContainer.EntrySet#size()}} that returns directly the size of container (including expired entries). Then the container is iterated using {{ImmutableEntryIterator}} which excludes expired entries by default, and this may return less elements than the original size() provided. That causes failure like this: > {code} > java.lang.IllegalStateException: End size 1 is less than fixed size 2 > at java.util.stream.Nodes$FixedNodeBuilder.end(Nodes.java:1232) > at java.util.stream.Sink$ChainedReference.end(Sink.java:258) > at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482) > at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) > at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:545) > at java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260) > at java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:438) > {code} > Note that this can also happen without expiration upon concurrent modification. We have to adjust the characteristics (remove {{#SIZED}}) of provided spliterators. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7656) DefaultDataContainer.entrySet().stream().toArray(Object[]::new) may fail

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-7656?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-7656: -------------------------------- Fix Version/s: 9.0.0.Final > DefaultDataContainer.entrySet().stream().toArray(Object[]::new) may fail > ------------------------------------------------------------------------ > > Key: ISPN-7656 > URL: https://issues.jboss.org/browse/ISPN-7656 > Project: Infinispan > Issue Type: Bug > Components: Core > Reporter: Radim Vansa > Assignee: William Burns > Fix For: 9.0.0.Final > > > When the default Spliterator estimates size of the array, it calls {{DefaultDataContainer.EntrySet#size()}} that returns directly the size of container (including expired entries). Then the container is iterated using {{ImmutableEntryIterator}} which excludes expired entries by default, and this may return less elements than the original size() provided. That causes failure like this: > {code} > java.lang.IllegalStateException: End size 1 is less than fixed size 2 > at java.util.stream.Nodes$FixedNodeBuilder.end(Nodes.java:1232) > at java.util.stream.Sink$ChainedReference.end(Sink.java:258) > at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482) > at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) > at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:545) > at java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260) > at java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:438) > {code} > Note that this can also happen without expiration upon concurrent modification. We have to adjust the characteristics (remove {{#SIZED}}) of provided spliterators. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7461) Cache is not rebalanced on merge

by Petr Jurak (JIRA)

[ https://issues.jboss.org/browse/ISPN-7461?page=com.atlassian.jira.plugin.... ] Petr Jurak reassigned ISPN-7461: -------------------------------- Assignee: Petr Jurak > Cache is not rebalanced on merge > -------------------------------- > > Key: ISPN-7461 > URL: https://issues.jboss.org/browse/ISPN-7461 > Project: Infinispan > Issue Type: Bug > Components: State Transfer > Affects Versions: 5.2.7.Final > Reporter: Dennis Reed > Assignee: Petr Jurak > > After a cluster split and merge, the consistent hash is not balanced between the members. > For example in a 2-member cluster, after the merge one node will be primary owner of every segment. In In a larger cluster, some nodes will not own any data. > DefaultConsistentHash{numSegments=60, numOwners=2, members=[RehashAfterPartitionMergeTest-NodeB-49100, RehashAfterPartitionMergeTest-NodeA-11552]} -- 0: 0 1, 1: 0 1, 2: 0 1, 3: 0 1, 4: 0 1, 5: 0 1, 6: 0 1, 7: 0 1, 8: 0 1, 9: 0 1, 10: 0 1, 11: 0 1, 12: 0 1, 13: 0 1, 14: 0 1, 15: 0 1, 16: 0 1, 17: 0 1, 18: 0 1, 19: 0 1, 20: 0 1, 21: 0 1, 22: 0 1, 23: 0 1, 24: 0 1, 25: 0 1, 26: 0 1, 27: 0 1, 28: 0 1, 29: 0 1, 30: 0 1, 31: 0 1, 32: 0 1, 33: 0 1, 34: 0 1, 35: 0 1, 36: 0 1, 37: 0 1, 38: 0 1, 39: 0 1, 40: 0 1, 41: 0 1, 42: 0 1, 43: 0 1, 44: 0 1, 45: 0 1, 46: 0 1, 47: 0 1, 48: 0 1, 49: 0 1, 50: 0 1, 51: 0 1, 52: 0 1, 53: 0 1, 54: 0 1, 55: 0 1, 56: 0 1, 57: 0 1, 58: 0 1, 59: 0 1 > This is triggered consistently by the RehashAfterPartitionMergeTest test case, but is not caught because it does not sufficiently check the consistent hash. (it checks RebalancePolicy.isBalanced, which merely makes sure each segment has the correct number of owners, not that it's evenly distributed). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2017