[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
[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
[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
[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
[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
[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