March 2017 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-7641) Do not use the Triangle when in server mode

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7641?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7641: ---------------------------------- Fix Version/s: 9.0.0.CR4 > Do not use the Triangle when in server mode > ------------------------------------------- > > Key: ISPN-7641 > URL: https://issues.jboss.org/browse/ISPN-7641 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Affects Versions: 9.0.0.CR2 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Labels: performance > Fix For: 9.0.0.CR4, 9.0.0.Final > > > The triangle algorithm optimizes the scenario where the originator is not the primary owner of key, by sending ordered update from the primary to the backup. > Current implementation orders the updates by segments and if 2 or more keys in the same segment are updated concurrently, they must be updated in the backup sequential by the same order (safety condition, keeps the data consistent). > This approach has a negative impact in the scenario where the originator is the primary owner. However, in server mode (more precise in hot rod protocol), the clients connect directly to the primary owner of a key. This leads to a performance degradation with the triangle. > Using the old algorithm only in server mode brings the performance back to normal. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7641) Do not use the Triangle when in server mode

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7641?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7641: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Do not use the Triangle when in server mode > ------------------------------------------- > > Key: ISPN-7641 > URL: https://issues.jboss.org/browse/ISPN-7641 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Affects Versions: 9.0.0.CR2 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Labels: performance > Fix For: 9.0.0.CR4, 9.0.0.Final > > > The triangle algorithm optimizes the scenario where the originator is not the primary owner of key, by sending ordered update from the primary to the backup. > Current implementation orders the updates by segments and if 2 or more keys in the same segment are updated concurrently, they must be updated in the backup sequential by the same order (safety condition, keeps the data consistent). > This approach has a negative impact in the scenario where the originator is the primary owner. However, in server mode (more precise in hot rod protocol), the clients connect directly to the primary owner of a key. This leads to a performance degradation with the triangle. > Using the old algorithm only in server mode brings the performance back to normal. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

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 commented on ISPN-7656: ------------------------------------- Hrmm looking at the entrySet method on DefaultDataContainer it uses the AbstractSet spliterator default which only does DISTINCT, doesn't put SIZED. I will have to look at it closer. > 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 > > 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)

9 years

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 edited comment on ISPN-7656 at 3/22/17 11:35 AM: --------------------------------------------------------------- Actually the call to size should be sizeIncludingExpired as it is slower anyways (referencing CacheLoaderInterceptor sorry). But I agree any spliterator shouldn't be SIZED. was (Author: william.burns): Actually the call to size should be sizeIncludingExpired as it is slower anyways. But we should remove the SIZED as well. > 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 > > 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)

9 years

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 commented on ISPN-7656: ------------------------------------- Actually the call to size should be sizeIncludingExpired as it is slower anyways. But we should remove the SIZED as well. > 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 > > 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)

9 years

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: Open (was: New) > 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 > > 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)

9 years

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: ------------------------------- Component/s: Build process Fix Version/s: 9.0.0.CR4 Affects Version/s: 9.0.0.CR3 > 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 > Fix For: 9.0.0.CR4 > > > 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)

9 years

1
0
0 / 0

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

by Dan Berindei (JIRA)

Dan Berindei created ISPN-7659: ---------------------------------- Summary: 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 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)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7658) Cache loader missing from server xsd

by Ryan Emerson (JIRA)

Ryan Emerson created ISPN-7658: ---------------------------------- Summary: Cache loader missing from server xsd Key: ISPN-7658 URL: https://issues.jboss.org/browse/ISPN-7658 Project: Infinispan Issue Type: Bug Components: Configuration, Server Affects Versions: 9.0.0.CR3 Reporter: Ryan Emerson Assignee: Ryan Emerson -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7538) DefaultCacheManager.getCache() warns ISPN000434: Direct usage of the ___defaultcache name to retrieve the default cache is deprecated

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-7538?page=com.atlassian.jira.plugin.... ] Dan Berindei resolved ISPN-7538. -------------------------------- Assignee: Dan Berindei (was: Tristan Tarrant) Resolution: Done Fixed with ISPN-5654. The test suite still logs a lot of ISPN000434 warnings, but that's because {{TestingUtil.clearContent()}} explicitly calls `getCache(DEFAULT_CACHE_NAME, false)}}. > DefaultCacheManager.getCache() warns ISPN000434: Direct usage of the ___defaultcache name to retrieve the default cache is deprecated > ------------------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-7538 > URL: https://issues.jboss.org/browse/ISPN-7538 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.0.0.CR2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Minor > Fix For: 9.0.0.Final > > > {{DefaultCacheManager.getCache()}} internally uses {{___defaultcache}} when the there is no default cache defined, but it shouldn't trigger the warning because the user isn't using it directly. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 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 2017