March 2017 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-7670) Upgrade to Hibernate Search 5.7.1.Final

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-7670: ------------------------------------- Summary: Upgrade to Hibernate Search 5.7.1.Final Key: ISPN-7670 URL: https://issues.jboss.org/browse/ISPN-7670 Project: Infinispan Issue Type: Component Upgrade Components: Embedded Querying Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Minor Fix For: 9.0.0.Final -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7628) Administration console - the cluster status doesn't reflect "reload-required" state of its nodes

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-7628?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-7628: ------------------------------- Git Pull Request: https://github.com/infinispan/infinispan-management-console/pull/199, https://github.com/infinispan/infinispan-management-console/pull/202 (was: https://github.com/infinispan/infinispan-management-console/pull/199) > Administration console - the cluster status doesn't reflect "reload-required" state of its nodes > ------------------------------------------------------------------------------------------------ > > Key: ISPN-7628 > URL: https://issues.jboss.org/browse/ISPN-7628 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 9.0.0.CR2 > Reporter: Roman Macor > Assignee: Vladimir Blagojevic > Fix For: 9.0.0.Final > > > The cluster has "Started" status even though all of its nodes have "reload-required" status. > Expected result: > The cluster status should also be "reload-required" > Another suggestion: > "Reload" action should be available from the cluster so that the user doesn't need to perform this action on individual nodes (there could be hundreds of them ) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

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: 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)

9 years

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)

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: ------------------------------- 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)

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: ------------------------------- 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)

9 years

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)

9 years

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)

9 years

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)

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: 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)

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