November 2017 - infinispan-issues

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

by William Burns (JIRA)

William Burns created ISPN-8481: ----------------------------------- Summary: 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 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)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8454) Off Heap can crash when using JMH test

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8454?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-8454: ------------------------------------- I was able to finally complete my JMH test run https://gist.github.com/wburns/d3fdc9bc707ba296374c31d99f6e7a05 > Off Heap can crash when using JMH test > -------------------------------------- > > Key: ISPN-8454 > URL: https://issues.jboss.org/browse/ISPN-8454 > Project: Infinispan > Issue Type: Bug > Components: Off Heap > Reporter: William Burns > Assignee: William Burns > Fix For: 9.2.0.Beta1 > > > I have a jmh branch from our benchmarks that always can crash off heap when not using tracing. For whatever reason I can't seem to reliably produce it with tracing. This JIRA is to handle this issue. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8454) Off Heap can crash when using JMH test

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8454?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-8454: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/5562 > Off Heap can crash when using JMH test > -------------------------------------- > > Key: ISPN-8454 > URL: https://issues.jboss.org/browse/ISPN-8454 > Project: Infinispan > Issue Type: Bug > Components: Off Heap > Reporter: William Burns > Assignee: William Burns > Fix For: 9.2.0.Beta1 > > > I have a jmh branch from our benchmarks that always can crash off heap when not using tracing. For whatever reason I can't seem to reliably produce it with tracing. This JIRA is to handle this issue. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8454) Off Heap can crash when using JMH test

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8454?page=com.atlassian.jira.plugin.... ] Work on ISPN-8454 started by William Burns. ------------------------------------------- > Off Heap can crash when using JMH test > -------------------------------------- > > Key: ISPN-8454 > URL: https://issues.jboss.org/browse/ISPN-8454 > Project: Infinispan > Issue Type: Bug > Components: Off Heap > Reporter: William Burns > Assignee: William Burns > Fix For: 9.2.0.Beta1 > > > I have a jmh branch from our benchmarks that always can crash off heap when not using tracing. For whatever reason I can't seem to reliably produce it with tracing. This JIRA is to handle this issue. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8403) Use partition handling for Shared Memory Service

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-8403?page=com.atlassian.jira.plugin.... ] Ryan Emerson resolved ISPN-8403. -------------------------------- Resolution: Done > Use partition handling for Shared Memory Service > ------------------------------------------------ > > Key: ISPN-8403 > URL: https://issues.jboss.org/browse/ISPN-8403 > Project: Infinispan > Issue Type: Feature Request > Components: Cloud Integrations, Core, State Transfer > Reporter: Sebastian Łaskawiec > Assignee: Ryan Emerson > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8405) Remove persistence from Shared Memory Service

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-8405?page=com.atlassian.jira.plugin.... ] Ryan Emerson resolved ISPN-8405. -------------------------------- Resolution: Done > Remove persistence from Shared Memory Service > --------------------------------------------- > > Key: ISPN-8405 > URL: https://issues.jboss.org/browse/ISPN-8405 > Project: Infinispan > Issue Type: Enhancement > Components: Cloud Integrations > Reporter: Sebastian Łaskawiec > Assignee: Ryan Emerson > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8406) Use number of owners provided by the user in Shared Memory Service

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-8406?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-8406: ------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/jboss-container-images/jboss-dataservices-image/pull/21 > Use number of owners provided by the user in Shared Memory Service > ------------------------------------------------------------------ > > Key: ISPN-8406 > URL: https://issues.jboss.org/browse/ISPN-8406 > Project: Infinispan > Issue Type: Enhancement > Components: Cloud Integrations > Reporter: Sebastian Łaskawiec > Assignee: Ryan Emerson > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8467) Memory Leak in the Rest server

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-8467?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-8467: ------------------------------------ Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/5561 > Memory Leak in the Rest server > ------------------------------ > > Key: ISPN-8467 > URL: https://issues.jboss.org/browse/ISPN-8467 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 9.2.0.Alpha2 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > > The Netty rest server upon each connection will install the {{Http20RequestHandler}} that in turn creates a new instance of {{CacheOperations}} and {{RestCacheManager}} objects. > The {{RestCacheManager}} on every connection, among other things, will create hashmaps to keep cache instances, and will try to register every time a new {{RestSourceMigrator}} which gets accumulated in the {{RollingUpgradeManager}}. > Those objects should be shared across all channels so that they can efficiently cache resources and avoid creating lots of garbage. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6879) Calculate (and expose) minimum number of nodes for data in Infinispan

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-6879?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-6879: ------------------------------------- True the more I thought about it max doesn't make that much sense. So a dynamic number based on current usage is what it should be. > Calculate (and expose) minimum number of nodes for data in Infinispan > --------------------------------------------------------------------- > > Key: ISPN-6879 > URL: https://issues.jboss.org/browse/ISPN-6879 > Project: Infinispan > Issue Type: Feature Request > Components: Cloud Integrations, Server > Reporter: Sebastian Łaskawiec > Assignee: William Burns > > With Kubernetes autoscaling we need to be able to tell what is the minimum amount of nodes necessary for hosting data (probably some sort of size + number of nodes estimation). -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8480) Data Inconsistency in case of Topology change in Infinispan Cluster

by Rohit Singh (JIRA)

[ https://issues.jboss.org/browse/ISPN-8480?page=com.atlassian.jira.plugin.... ] Rohit Singh updated ISPN-8480: ------------------------------ Description: {color:red}*Data Inconsistency in case of Topology change in Infinispan Cluster*{color} *Infinispan Version : 8.2.5* *Hibernate Version : 5.2.8* *JGROUPS Version : 3.6.7* *Clustering Mode : Replication* We have tested the same with invalidation mode too. Refer below config cache-config for hibernate L2 entity types: <replicated-cache-configuration name="entity" mode="SYNC" remote-timeout="20000" statistics="false" statistics-available="false"> <state-transfer enabled="false" timeout="20000000"/> <locking isolation="READ_COMMITTED" concurrency-level="1000" acquire-timeout="15000" striping="false"/> <transaction mode="NONE" auto-commit="false" locking="OPTIMISTIC"/> <eviction size="-1" strategy="NONE"/> <expiration max-idle="-1" interval="5000" lifespan="-1" /> </replicated-cache-configuration> When a disconnected node rejoins the cluster, data remains inconsistent on the reconnected node. *This is happening for both Hibernate L2 Cache and some custom cache (AdvancedCache).* The below 4 scenarios should explain the issue. *For Example:* *Scenario (Issue) 1:* -Initially the cluster comprises of 4 nodes, namely {A,B,C,D}. -Somehow, node D gets removed from the cluster view. -Then some updates/inserts in hibernate L2 cache is done on Node B. -These updates/inserts gets propagated to all the nodes in the current cluster view, i.e. {A,B,C}. -And these updates/inserts doesn't get propagated to the Node D. -Now D has stale state of the L2 cache. -We expect, Node D should get the updated state of L2 Cache from {A,B,C}. *Scenario (Issue) 2:* -Initially the cluster comprises of 4 nodes, namely {A,B,C,D}. -Somehow, node D gets removed from the cluster view. -Then some updates/inserts in hibernate L2 cache is done on Node B. -These updates/inserts gets propagated to all the nodes in the current cluster view, i.e. {A,B,C}. -And these updates/inserts doesn't get propagated to the Node D. -Now D has stale state of the L2 cache. -Now D rejoins the cluster {A,B,C}. -Now the updated cluster view is {A,B,C,D}. -Still D has stale state of the L2 cache. -We expect, Node D should get the updated state of L2 Cache from {A,B,C}. *Scenario (Issue) 3:* -Initially the cluster comprises of 4 nodes, namely {A,B,C,D}. -Somehow, node D gets removed from the cluster view. -Then some updates/inserts in hibernate L2 cache is done on Node B. -These updates/inserts gets propagated to all the nodes in the current cluster view, i.e. {A,B,C}. -And these updates/inserts doesn't get propagated to the Node D. -Subsequently, some updates/inserts in hibernate L2 cache is done on Node D too. These updates are done on some other keys, and not on the keys on which the updates were done by Node B. -Now {A,B,C} and Node D have different but updated state of the L2 cache, And are not in sync. -Now D rejoins the cluster {A,B,C}. -Now the updated cluster view is {A,B,C,D}. -Still {A,B,C} and Node D have different but updated state of the L2 cache, And are not in sync. -We expect, updates from {A,B,C} and Node D should get merged to all the nodes in cluster. *Scenario (Issue) 4:* -Initially the cluster comprises of 4 nodes, namely {A,B,C,D}. -Somehow, node D gets removed from the cluster view. -Then some updates/inserts in hibernate L2 cache is done on Node B. -These updates/inserts gets propagated to all the nodes in the current cluster view, i.e. {A,B,C}. -And these updates/inserts doesn't get propagated to the Node D. -Subsequently, some updates/inserts in hibernate L2 cache is done on Node D too. These updates might be on the same keys on which the updates were done by Node B. -Now D has more updated state of the L2 cache. -And {A,B,C} are having stale state of the L2 Cache. -Now D rejoins the cluster {A,B,C}. -Now the updated cluster view is {A,B,C,D}. -Still {A,B,C} have stale state of the L2 cache. -We expect, {A,B,C} should get the updated state of L2 Cache from Node D. was: {color:red}*Data Inconsistency in case of Topology change in Infinispan Cluster*{color} *Infinispan Version : 8.2.5* *Hibernate Version : 5.2.8* *JGROUPS Version : 3.6.7* *Clustering Mode : Replication* We have tested the same with invalidation mode too. Refer below config cache-config for hibernate L2 entity types: _<replicated-cache-configuration name="entity" mode="SYNC" remote-timeout="20000" statistics="false" statistics-available="false"> <state-transfer enabled="false" timeout="20000000"/> <locking isolation="READ_COMMITTED" concurrency-level="1000" acquire-timeout="15000" striping="false"/> <transaction mode="NONE" auto-commit="false" locking="OPTIMISTIC"/> <eviction size="-1" strategy="NONE"/> <expiration max-idle="-1" interval="5000" lifespan="-1" /> </replicated-cache-configuration> _ When a disconnected node rejoins the cluster, data remains inconsistent on the reconnected node. *This is happening for both Hibernate L2 Cache and some custom cache (AdvancedCache).* The below 4 scenarios should explain the issue. *For Example:* *Scenario (Issue) 1:* -Initially the cluster comprises of 4 nodes, namely {A,B,C,D}. -Somehow, node D gets removed from the cluster view. -Then some updates/inserts in hibernate L2 cache is done on Node B. -These updates/inserts gets propagated to all the nodes in the current cluster view, i.e. {A,B,C}. -And these updates/inserts doesn't get propagated to the Node D. -Now D has stale state of the L2 cache. -We expect, Node D should get the updated state of L2 Cache from {A,B,C}. *Scenario (Issue) 2:* -Initially the cluster comprises of 4 nodes, namely {A,B,C,D}. -Somehow, node D gets removed from the cluster view. -Then some updates/inserts in hibernate L2 cache is done on Node B. -These updates/inserts gets propagated to all the nodes in the current cluster view, i.e. {A,B,C}. -And these updates/inserts doesn't get propagated to the Node D. -Now D has stale state of the L2 cache. -Now D rejoins the cluster {A,B,C}. -Now the updated cluster view is {A,B,C,D}. -Still D has stale state of the L2 cache. -We expect, Node D should get the updated state of L2 Cache from {A,B,C}. *Scenario (Issue) 3:* -Initially the cluster comprises of 4 nodes, namely {A,B,C,D}. -Somehow, node D gets removed from the cluster view. -Then some updates/inserts in hibernate L2 cache is done on Node B. -These updates/inserts gets propagated to all the nodes in the current cluster view, i.e. {A,B,C}. -And these updates/inserts doesn't get propagated to the Node D. -Subsequently, some updates/inserts in hibernate L2 cache is done on Node D too. These updates are done on some other keys, and not on the keys on which the updates were done by Node B. -Now {A,B,C} and Node D have different but updated state of the L2 cache, And are not in sync. -Now D rejoins the cluster {A,B,C}. -Now the updated cluster view is {A,B,C,D}. -Still {A,B,C} and Node D have different but updated state of the L2 cache, And are not in sync. -We expect, updates from {A,B,C} and Node D should get merged to all the nodes in cluster. *Scenario (Issue) 4:* -Initially the cluster comprises of 4 nodes, namely {A,B,C,D}. -Somehow, node D gets removed from the cluster view. -Then some updates/inserts in hibernate L2 cache is done on Node B. -These updates/inserts gets propagated to all the nodes in the current cluster view, i.e. {A,B,C}. -And these updates/inserts doesn't get propagated to the Node D. -Subsequently, some updates/inserts in hibernate L2 cache is done on Node D too. These updates might be on the same keys on which the updates were done by Node B. -Now D has more updated state of the L2 cache. -And {A,B,C} are having stale state of the L2 Cache. -Now D rejoins the cluster {A,B,C}. -Now the updated cluster view is {A,B,C,D}. -Still {A,B,C} have stale state of the L2 cache. -We expect, {A,B,C} should get the updated state of L2 Cache from Node D. > Data Inconsistency in case of Topology change in Infinispan Cluster > ------------------------------------------------------------------- > > Key: ISPN-8480 > URL: https://issues.jboss.org/browse/ISPN-8480 > Project: Infinispan > Issue Type: Bug > Affects Versions: 8.2.5.Final > Reporter: Rohit Singh > Priority: Blocker > Labels: Infinispan, JGroups, hibernate_2nd_level_cache > > {color:red}*Data Inconsistency in case of Topology change in Infinispan Cluster*{color} > *Infinispan Version : 8.2.5* > *Hibernate Version : 5.2.8* > *JGROUPS Version : 3.6.7* > *Clustering Mode : Replication* > We have tested the same with invalidation mode too. > Refer below config cache-config for hibernate L2 entity types: > <replicated-cache-configuration name="entity" mode="SYNC" remote-timeout="20000" statistics="false" statistics-available="false"> > <state-transfer enabled="false" timeout="20000000"/> > <locking isolation="READ_COMMITTED" concurrency-level="1000" acquire-timeout="15000" striping="false"/> > <transaction mode="NONE" auto-commit="false" locking="OPTIMISTIC"/> > <eviction size="-1" strategy="NONE"/> > <expiration max-idle="-1" interval="5000" lifespan="-1" /> > </replicated-cache-configuration> > > When a disconnected node rejoins the cluster, data remains inconsistent on the reconnected node. > *This is happening for both Hibernate L2 Cache and some custom cache (AdvancedCache).* > The below 4 scenarios should explain the issue. > *For Example:* > *Scenario (Issue) 1:* > -Initially the cluster comprises of 4 nodes, namely {A,B,C,D}. > -Somehow, node D gets removed from the cluster view. > -Then some updates/inserts in hibernate L2 cache is done on Node B. > -These updates/inserts gets propagated to all the nodes in the current cluster view, i.e. {A,B,C}. > -And these updates/inserts doesn't get propagated to the Node D. > -Now D has stale state of the L2 cache. > -We expect, Node D should get the updated state of L2 Cache from {A,B,C}. > > *Scenario (Issue) 2:* > -Initially the cluster comprises of 4 nodes, namely {A,B,C,D}. > -Somehow, node D gets removed from the cluster view. > -Then some updates/inserts in hibernate L2 cache is done on Node B. > -These updates/inserts gets propagated to all the nodes in the current cluster view, i.e. {A,B,C}. > -And these updates/inserts doesn't get propagated to the Node D. > -Now D has stale state of the L2 cache. > -Now D rejoins the cluster {A,B,C}. > -Now the updated cluster view is {A,B,C,D}. > -Still D has stale state of the L2 cache. > -We expect, Node D should get the updated state of L2 Cache from {A,B,C}. > > *Scenario (Issue) 3:* > -Initially the cluster comprises of 4 nodes, namely {A,B,C,D}. > -Somehow, node D gets removed from the cluster view. > -Then some updates/inserts in hibernate L2 cache is done on Node B. > -These updates/inserts gets propagated to all the nodes in the current cluster view, i.e. {A,B,C}. > -And these updates/inserts doesn't get propagated to the Node D. > -Subsequently, some updates/inserts in hibernate L2 cache is done on Node D too. These updates are done on some other keys, and not on the keys on which the updates were done by Node B. > -Now {A,B,C} and Node D have different but updated state of the L2 cache, And are not in sync. > -Now D rejoins the cluster {A,B,C}. > -Now the updated cluster view is {A,B,C,D}. > -Still {A,B,C} and Node D have different but updated state of the L2 cache, And are not in sync. > -We expect, updates from {A,B,C} and Node D should get merged to all the nodes in cluster. > > *Scenario (Issue) 4:* > -Initially the cluster comprises of 4 nodes, namely {A,B,C,D}. > -Somehow, node D gets removed from the cluster view. > -Then some updates/inserts in hibernate L2 cache is done on Node B. > -These updates/inserts gets propagated to all the nodes in the current cluster view, i.e. {A,B,C}. > -And these updates/inserts doesn't get propagated to the Node D. > -Subsequently, some updates/inserts in hibernate L2 cache is done on Node D too. These updates might be on the same keys on which the updates were done by Node B. > -Now D has more updated state of the L2 cache. > -And {A,B,C} are having stale state of the L2 Cache. > -Now D rejoins the cluster {A,B,C}. > -Now the updated cluster view is {A,B,C,D}. > -Still {A,B,C} have stale state of the L2 cache. > -We expect, {A,B,C} should get the updated state of L2 Cache from Node D. > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2017