November 2017 - infinispan-issues

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

by Gustavo Fernandes (JIRA)

Gustavo Fernandes created ISPN-8467: --------------------------------------- Summary: 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 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 a {{RestSourceMigrator}} which gets accumulated over time in the {{RestSourceMigrator}}. 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)

7 years, 2 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 reassigned ISPN-8467: --------------------------------------- Assignee: Gustavo Fernandes > 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 a {{RestSourceMigrator}} which gets accumulated over time in the {{RestSourceMigrator}}. > 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)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8465) Create Online Service Configuration Templates

by Ryan Emerson (JIRA)

Ryan Emerson created ISPN-8465: ---------------------------------- Summary: Create Online Service Configuration Templates Key: ISPN-8465 URL: https://issues.jboss.org/browse/ISPN-8465 Project: Infinispan Issue Type: Bug Reporter: Ryan Emerson Assignee: Ryan Emerson Fix For: 9.2.0.Alpha2 We should create a standalone configuration file that only contains the templates that will be used for the shared-memory and caching services. This will reduce the amount of cli operations required for our dataservices images and will also allow non-openshift users to utilise the same configurations. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8411) Add support for efficient removeAll

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-8411?page=com.atlassian.jira.plugin.... ] Galder Zamarreño reassigned ISPN-8411: -------------------------------------- Assignee: Radim Vansa (was: Galder Zamarreño) > Add support for efficient removeAll > ----------------------------------- > > Key: ISPN-8411 > URL: https://issues.jboss.org/browse/ISPN-8411 > Project: Infinispan > Issue Type: Feature Request > Components: Hibernate Cache > Affects Versions: 8.2.8.Final, 9.1.1.Final > Environment: WildFly 10.1.0, WildFly 11.0.0.CR1, WildFly master, Hibernate 2LC > Reporter: Emond Papegaaij > Assignee: Radim Vansa > > Infinispan currently does not seem to implement an efficient way to clear an entire cache cluster-wide. This forces Hibernate to remove all entries one by one when a cache region needs to be cleared, for example when a buld CriteriaUpdate or CriteriaDelete is used. > The behavior we are observing is: > # All nodes in the cluster are queried for the keyset in a region > # A lock seems to be in place for this region for the duration of the commit > # The initiating node constructs a message with {{InvalidateCommands}} for all keys > # This large message (230MB for 200k entries) is sent to all nodes in the cluster > For large caches this can take very long. We had to increase the remote-timeout to 60 seconds to prevent timeouts. During this time, the entire cluster is locked an busy processing the cache invalidations. As you can understand, this is not a workable solution for us. On some places we can prevent the cache clear by updating the records one by one, but in other places this is not an option. > The corresponding report at Hibernate can be found here: https://hibernate.atlassian.net/browse/HHH-12036 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8464) Calculate & adjust default persistence size

by Pedro Zapata (JIRA)

Pedro Zapata created ISPN-8464: ---------------------------------- Summary: Calculate & adjust default persistence size Key: ISPN-8464 URL: https://issues.jboss.org/browse/ISPN-8464 Project: Infinispan Issue Type: Enhancement Components: Cloud Integrations Reporter: Pedro Zapata There's a persistence volume claim of 1GiB. However, the amount of data to be stored for runtime info, given no cache store will be used, should be minimal. Goal: get some measures of the expected amount of persistent space consumed and reduce the 1GiB claim to a more adjusted amount. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8463) Add total container memory parameter

by Pedro Zapata (JIRA)

Pedro Zapata created ISPN-8463: ---------------------------------- Summary: Add total container memory parameter Key: ISPN-8463 URL: https://issues.jboss.org/browse/ISPN-8463 Project: Infinispan Issue Type: Enhancement Components: Cloud Integrations Reporter: Pedro Zapata Add parameter TOTAL_CONTAINER_MEM - integer, in MiB, no defaults, validate to >= 256 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 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 seem to be able to reproduce it much faster when I reduce the number of address counts as well. :) > 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)

7 years, 2 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: ------------------------------------- Also tried having the cache full and just doing multiple read threads only and not write threads and can't reproduce this. So it seems to only happen with both read and write threads together. > 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)

7 years, 2 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 edited comment on ISPN-8454 at 11/1/17 5:16 PM: -------------------------------------------------------------- This only ever happens if reads are done with writes. If a ton of writes are done this isn't an issue. I was able to get the following exception to be thrown as well: {quote} Caused by: java.lang.AssertionError at org.infinispan.container.offheap.BoundedOffHeapDataContainer.removeNode(BoundedOffHeapDataContainer.java:152) at org.infinispan.container.offheap.BoundedOffHeapDataContainer.entryReplaced(BoundedOffHeapDataContainer.java:76) at org.infinispan.container.offheap.OffHeapDataContainer.performPut(OffHeapDataContainer.java:207) at org.infinispan.container.offheap.OffHeapDataContainer.put(OffHeapDataContainer.java:177) at org.infinispan.container.offheap.BoundedOffHeapDataContainer.put(BoundedOffHeapDataContainer.java:51) at org.infinispan.container.offheap.BoundedOffHeapDataContainer.put(BoundedOffHeapDataContainer.java:27) at org.infinispan.container.offheap.OffHeapSingleNodeStressTest.lambda$testLotsOfPutsAndReads$0(OffHeapSingleNodeStressTest.java:64) at java.util.concurrent.FutureTask.run(FutureTask.java:266) {quote} I can't seem to locate a bug in the moveToEnd code, as it appears it should work fine while holding the lruLock which it does. I am trying to look into this more. was (Author: william.burns): This only ever happens if reads are done with writes. If a ton of writes are done this isn't an issue. I was able to get the following exception to be thrown as well: {quote} Caused by: java.lang.AssertionError at org.infinispan.container.offheap.BoundedOffHeapDataContainer.removeNode(BoundedOffHeapDataContainer.java:152) at org.infinispan.container.offheap.BoundedOffHeapDataContainer.entryReplaced(BoundedOffHeapDataContainer.java:76) at org.infinispan.container.offheap.OffHeapDataContainer.performPut(OffHeapDataContainer.java:207) at org.infinispan.container.offheap.OffHeapDataContainer.put(OffHeapDataContainer.java:177) at org.infinispan.container.offheap.BoundedOffHeapDataContainer.put(BoundedOffHeapDataContainer.java:51) at org.infinispan.container.offheap.BoundedOffHeapDataContainer.put(BoundedOffHeapDataContainer.java:27) at org.infinispan.container.offheap.OffHeapSingleNodeStressTest.lambda$testLotsOfPutsAndReads$0(OffHeapSingleNodeStressTest.java:64) at java.util.concurrent.FutureTask.run(FutureTask.java:266) {quote} > 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)

7 years, 2 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: ------------------------------------- This only ever happens if reads are done with writes. If a ton of writes are done this isn't an issue. I was able to get the following exception to be thrown as well: {quote} Caused by: java.lang.AssertionError at org.infinispan.container.offheap.BoundedOffHeapDataContainer.removeNode(BoundedOffHeapDataContainer.java:152) at org.infinispan.container.offheap.BoundedOffHeapDataContainer.entryReplaced(BoundedOffHeapDataContainer.java:76) at org.infinispan.container.offheap.OffHeapDataContainer.performPut(OffHeapDataContainer.java:207) at org.infinispan.container.offheap.OffHeapDataContainer.put(OffHeapDataContainer.java:177) at org.infinispan.container.offheap.BoundedOffHeapDataContainer.put(BoundedOffHeapDataContainer.java:51) at org.infinispan.container.offheap.BoundedOffHeapDataContainer.put(BoundedOffHeapDataContainer.java:27) at org.infinispan.container.offheap.OffHeapSingleNodeStressTest.lambda$testLotsOfPutsAndReads$0(OffHeapSingleNodeStressTest.java:64) at java.util.concurrent.FutureTask.run(FutureTask.java:266) {quote} > 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)

7 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2017