November 2017 - infinispan-issues

[JBoss JIRA] (ISPN-8514) Add support for OpenShift 3.7

by Sebastian Łaskawiec (JIRA)

Sebastian Łaskawiec created ISPN-8514: ----------------------------------------- Summary: Add support for OpenShift 3.7 Key: ISPN-8514 URL: https://issues.jboss.org/browse/ISPN-8514 Project: Infinispan Issue Type: Bug Components: Cloud Integrations Reporter: Sebastian Łaskawiec Things to update: * [ ] {{oc}} binary on CI * [ ] {{make install-templates-in-openshift-namespace}} should refresh Service Catalog by default . We need to increase relist requests for {{ClusterServiceBroker}}s (see https://stackoverflow.com/questions/36920171/how-can-i-edit-a-deployment-...). * [ ] New annotations should be added to display text properly on Service Catalog -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8504) View change during cluster listener registration can throw SuspectException

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8504?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-8504: -------------------------------- Status: Open (was: New) > View change during cluster listener registration can throw SuspectException > --------------------------------------------------------------------------- > > Key: ISPN-8504 > URL: https://issues.jboss.org/browse/ISPN-8504 > Project: Infinispan > Issue Type: Bug > Reporter: Pedro Ruivo > Fix For: 9.2.0.Final, 9.1.3.Final > > > when registering a cluster listener, if a view change happens, it tries to register the listener in the joiner. However, if the joiner doesn't have the cache, a {{SuspectException}} is thrown. > I noticed also the cluster listener registration uses the view and not the cache members. > In the first iteration, the {{SuspectException}} is ignored: > Line 872: > {code:java} > for (int i = 0; i < members.size() - 1; ++i) { > try { > decs.take().get(); > } catch (InterruptedException e) { > throw new CacheListenerException(e); > } catch (ExecutionException e) { > Throwable cause = e.getCause(); > // If we got a SuspectException it means the remote node hasn't started this cache yet. > // Just ignore, when it joins it will retrieve the listener > if (!(cause instanceof SuspectException)) { > throw new CacheListenerException(cause); > } > } > } > {code} > However, when trying in the joiners, the exception isn't ignored: > Line 902 > {code:java} > for (int i = 0; i < extraCount; ++i) { > try { > decs.take().get(); > } catch (InterruptedException e) { > throw new CacheListenerException(e); > } catch (ExecutionException e) { > throw new CacheListenerException(e); > } > } > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8504) View change during cluster listener registration can throw SuspectException

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8504?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-8504: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/5574 > View change during cluster listener registration can throw SuspectException > --------------------------------------------------------------------------- > > Key: ISPN-8504 > URL: https://issues.jboss.org/browse/ISPN-8504 > Project: Infinispan > Issue Type: Bug > Reporter: Pedro Ruivo > Fix For: 9.2.0.Final, 9.1.3.Final > > > when registering a cluster listener, if a view change happens, it tries to register the listener in the joiner. However, if the joiner doesn't have the cache, a {{SuspectException}} is thrown. > I noticed also the cluster listener registration uses the view and not the cache members. > In the first iteration, the {{SuspectException}} is ignored: > Line 872: > {code:java} > for (int i = 0; i < members.size() - 1; ++i) { > try { > decs.take().get(); > } catch (InterruptedException e) { > throw new CacheListenerException(e); > } catch (ExecutionException e) { > Throwable cause = e.getCause(); > // If we got a SuspectException it means the remote node hasn't started this cache yet. > // Just ignore, when it joins it will retrieve the listener > if (!(cause instanceof SuspectException)) { > throw new CacheListenerException(cause); > } > } > } > {code} > However, when trying in the joiners, the exception isn't ignored: > Line 902 > {code:java} > for (int i = 0; i < extraCount; ++i) { > try { > decs.take().get(); > } catch (InterruptedException e) { > throw new CacheListenerException(e); > } catch (ExecutionException e) { > throw new CacheListenerException(e); > } > } > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8409) Change off heap eviction to store everything in same allocated memory block

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8409?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-8409: -------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/5523, https://github.com/infinispan/infinispan/pull/5569, https://github.com/infinispan/infinispan/pull/5573 (was: https://github.com/infinispan/infinispan/pull/5523, https://github.com/infinispan/infinispan/pull/5569) > Change off heap eviction to store everything in same allocated memory block > --------------------------------------------------------------------------- > > Key: ISPN-8409 > URL: https://issues.jboss.org/browse/ISPN-8409 > Project: Infinispan > Issue Type: Sub-task > Components: Off Heap > Affects Versions: 9.2.0.Alpha1 > Reporter: William Burns > Assignee: William Burns > Fix For: 9.2.0.Beta1, 9.1.3.Final > > > When eviction is enabled with off heap, we currently allocate an additional 28 byte lru node for every entry. We can instead include the lru information in the entry allocation, by changing slightly when memory is freed. This will allow for more entries to be inserted when eviction is enabled, and possibly additional performance. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8419) Off Heap peek doesn't do a peek and reorders lru nodes

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8419?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-8419: -------------------------------- Fix Version/s: 9.1.3.Final > Off Heap peek doesn't do a peek and reorders lru nodes > ------------------------------------------------------ > > Key: ISPN-8419 > URL: https://issues.jboss.org/browse/ISPN-8419 > Project: Infinispan > Issue Type: Sub-task > Components: Off Heap > Affects Versions: 9.2.0.Alpha1 > Reporter: William Burns > Assignee: William Burns > Fix For: 9.2.0.Beta1, 9.1.3.Final > > > Currently the peak operation has to reorder lru nodes, which causes extra locking that isn't needed. We need to implement peek that doesn't do this. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8419) Off Heap peek doesn't do a peek and reorders lru nodes

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8419?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-8419: -------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/5523, https://github.com/infinispan/infinispan/pull/5569 (was: https://github.com/infinispan/infinispan/pull/5523) > Off Heap peek doesn't do a peek and reorders lru nodes > ------------------------------------------------------ > > Key: ISPN-8419 > URL: https://issues.jboss.org/browse/ISPN-8419 > Project: Infinispan > Issue Type: Sub-task > Components: Off Heap > Affects Versions: 9.2.0.Alpha1 > Reporter: William Burns > Assignee: William Burns > Fix For: 9.2.0.Beta1, 9.1.3.Final > > > Currently the peak operation has to reorder lru nodes, which causes extra locking that isn't needed. We need to implement peek that doesn't do this. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8481) Lazily calculate hashCode for WrappedByteArray

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8481?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-8481: -------------------------------- Fix Version/s: 9.1.3.Final > Lazily calculate hashCode for WrappedByteArray > ---------------------------------------------- > > Key: ISPN-8481 > URL: https://issues.jboss.org/browse/ISPN-8481 > Project: Infinispan > Issue Type: Sub-task > Reporter: William Burns > Assignee: William Burns > Fix For: 9.2.0.Beta1, 9.1.3.Final > > > We don't always use the hashCode for a WrappedByteArray. By always calculating it this adds additional cost, we should see if we can change this safely. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8481) Lazily calculate hashCode for WrappedByteArray

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8481?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-8481: -------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/5563, https://github.com/infinispan/infinispan/pull/5569 (was: https://github.com/infinispan/infinispan/pull/5563) > Lazily calculate hashCode for WrappedByteArray > ---------------------------------------------- > > Key: ISPN-8481 > URL: https://issues.jboss.org/browse/ISPN-8481 > Project: Infinispan > Issue Type: Sub-task > Reporter: William Burns > Assignee: William Burns > Fix For: 9.2.0.Beta1, 9.1.3.Final > > > We don't always use the hashCode for a WrappedByteArray. By always calculating it this adds additional cost, we should see if we can change this safely. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8423) Remove metadata size integer in cases where we know the size

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8423?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-8423: -------------------------------- Fix Version/s: 9.1.3.Final > Remove metadata size integer in cases where we know the size > ------------------------------------------------------------ > > Key: ISPN-8423 > URL: https://issues.jboss.org/browse/ISPN-8423 > Project: Infinispan > Issue Type: Sub-task > Reporter: William Burns > Assignee: William Burns > Fix For: 9.2.0.Beta1, 9.1.3.Final > > > We store a type with the other metadata. This tells us whether the entry is IMMORTAL, MORTAL, TRANSIENT etc. In the case of known types we already know how large the metadata is. There is no reason to write an int stating this. This can remove 4 bytes in a lot of cases, especially now that rest uses a standard metadata. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8423) Remove metadata size integer in cases where we know the size

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8423?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-8423: -------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/5566, https://github.com/infinispan/infinispan/pull/5569 (was: https://github.com/infinispan/infinispan/pull/5566) > Remove metadata size integer in cases where we know the size > ------------------------------------------------------------ > > Key: ISPN-8423 > URL: https://issues.jboss.org/browse/ISPN-8423 > Project: Infinispan > Issue Type: Sub-task > Reporter: William Burns > Assignee: William Burns > Fix For: 9.2.0.Beta1, 9.1.3.Final > > > We store a type with the other metadata. This tells us whether the entry is IMMORTAL, MORTAL, TRANSIENT etc. In the case of known types we already know how large the metadata is. There is no reason to write an int stating this. This can remove 4 bytes in a lot of cases, especially now that rest uses a standard metadata. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2017