March 2019 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-10028) Deprecate ConcurrentWeakKeyHashMap

by Ryan Emerson (Jira)

[ https://issues.jboss.org/browse/ISPN-10028?page=com.atlassian.jira.plugin... ] Ryan Emerson updated ISPN-10028: -------------------------------- Status: Open (was: New) > Deprecate ConcurrentWeakKeyHashMap > ---------------------------------- > > Key: ISPN-10028 > URL: https://issues.jboss.org/browse/ISPN-10028 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 10.0.0.Beta2 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 10.0.0.Beta3 > > > We should deprecate {{ConcurrentWeakKeyHashMap}} and utilise a Caffeine cache that has weak-keys i.e. {{Caffeine.newBuilder().weakKeys().build()}}. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-10028) Deprecate ConcurrentWeakKeyHashMap

by Ryan Emerson (Jira)

Ryan Emerson created ISPN-10028: ----------------------------------- Summary: Deprecate ConcurrentWeakKeyHashMap Key: ISPN-10028 URL: https://issues.jboss.org/browse/ISPN-10028 Project: Infinispan Issue Type: Enhancement Components: Core Affects Versions: 10.0.0.Beta2 Reporter: Ryan Emerson Assignee: Ryan Emerson Fix For: 10.0.0.Beta3 We should deprecate {{ConcurrentWeakKeyHashMap}} and utilise a Caffeine cache that has weak-keys i.e. {{Caffeine.newBuilder().weakKeys().build()}}. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-9560) Docs: Feedback on Transactions Docs

by Don Naro (Jira)

[ https://issues.jboss.org/browse/ISPN-9560?page=com.atlassian.jira.plugin.... ] Don Naro updated ISPN-9560: --------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/6748 > Docs: Feedback on Transactions Docs > ----------------------------------- > > Key: ISPN-9560 > URL: https://issues.jboss.org/browse/ISPN-9560 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation-Core > Reporter: Don Naro > Assignee: Don Naro > Priority: Major > Attachments: zulip-chat > > > Docs for isolation levels are confusing and seem to conflict with the schema. > https://infinispan.zulipchat.com/#narrow/stream/118645-infinispan/subject... -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-9560) Docs: Feedback on Transactions Docs

by Don Naro (Jira)

[ https://issues.jboss.org/browse/ISPN-9560?page=com.atlassian.jira.plugin.... ] Don Naro updated ISPN-9560: --------------------------- Status: Open (was: New) > Docs: Feedback on Transactions Docs > ----------------------------------- > > Key: ISPN-9560 > URL: https://issues.jboss.org/browse/ISPN-9560 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation-Core > Reporter: Don Naro > Assignee: Don Naro > Priority: Major > Attachments: zulip-chat > > > Docs for isolation levels are confusing and seem to conflict with the schema. > https://infinispan.zulipchat.com/#narrow/stream/118645-infinispan/subject... -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-9982) Test deadlock for clustered caches with Expiration enabled

by William Burns (Jira)

[ https://issues.jboss.org/browse/ISPN-9982?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-9982: -------------------------------- Summary: Test deadlock for clustered caches with Expiration enabled (was: Possible deadlock for clustered caches with Expiration enabled) > Test deadlock for clustered caches with Expiration enabled > ---------------------------------------------------------- > > Key: ISPN-9982 > URL: https://issues.jboss.org/browse/ISPN-9982 > Project: Infinispan > Issue Type: Bug > Reporter: Diego Lovison > Assignee: Diego Lovison > Priority: Minor > Fix For: 10.0.0.Beta3 > > > Add a test case for the following scenario: > If a cache is configured for expiration an the intervall is != -1 there is a possiblity for a deadlock with JGroups and Infinispan threads because the reaper and any access to the same entry can cause a deadlock. > The possibility is higher if the configured interval for the reaper is shorter. > A thread dump might show something like followed: > "HotRod-hotrod-internalServerWorker-4-12" #279 prio=5 os_prio=0 tid=0x00007f35980b8800 nid=0xbbb waiting for monitor entry [0x00007f356cfb4000] > java.lang.Thread.State: BLOCKED (on object monitor) > at org.infinispan.commons.util.concurrent.jdk8backported.EquivalentConcurrentHashMapV8.compute(EquivalentConcurrentHashMapV8.java:1910) > - waiting to lock <0x0000000742cca028> (a org.infinispan.commons.util.concurrent.jdk8backported.EquivalentConcurrentHashMapV8$Node) > at org.infinispan.container.DefaultDataContainer.compute(DefaultDataContainer.java:335) > at org.infinispan.expiration.impl.ExpirationManagerImpl.handleInMemoryExpiration(ExpirationManagerImpl.java:135) > at org.infinispan.expiration.impl.ClusterExpirationManager.handleInMemoryExpiration(ClusterExpirationManager.java:152) > - locked <0x0000000742cc9898> (a org.infinispan.container.entries.metadata.MetadataTransientCacheEntry) > at org.infinispan.container.DefaultDataContainer.get(DefaultDataContainer.java:201) > "pool-7-thread-1" #158 prio=5 os_prio=0 tid=0x00007f35c816c000 nid=0xb35 waiting for monitor entry [0x00007f3575238000] > java.lang.Thread.State: BLOCKED (on object monitor) > at org.infinispan.expiration.impl.ExpirationManagerImpl.lambda$handleInMemoryExpiration$0(ExpirationManagerImpl.java:137) > - waiting to lock <0x0000000742cc9898> (a org.infinispan.container.entries.metadata.MetadataTransientCacheEntry) > at org.infinispan.expiration.impl.ExpirationManagerImpl$$Lambda$374/1904915245.compute(Unknown Source) > at org.infinispan.container.DefaultDataContainer.lambda$compute$3(DefaultDataContainer.java:336) > at org.infinispan.container.DefaultDataContainer$$Lambda$375/1917382785.apply(Unknown Source) > at org.infinispan.commons.util.concurrent.jdk8backported.EquivalentConcurrentHashMapV8.compute(EquivalentConcurrentHashMapV8.java:1919) > - locked <0x0000000742cca028> (a org.infinispan.commons.util.concurrent.jdk8backported.EquivalentConcurrentHashMapV8$Node) > at org.infinispan.container.DefaultDataContainer.compute(DefaultDataContainer.java:335) > at org.infinispan.expiration.impl.ExpirationManagerImpl.handleInMemoryExpiration(ExpirationManagerImpl.java:135) > at org.infinispan.expiration.impl.ClusterExpirationManager.processExpiration(ClusterExpirationManager.java:82) -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-9982) Possible deadlock for clustered caches with Expiration enabled

by William Burns (Jira)

[ https://issues.jboss.org/browse/ISPN-9982?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-9982: ------------------------------------- To clarify this issue was fixed in ISPN-9003 for master. > Possible deadlock for clustered caches with Expiration enabled > -------------------------------------------------------------- > > Key: ISPN-9982 > URL: https://issues.jboss.org/browse/ISPN-9982 > Project: Infinispan > Issue Type: Bug > Reporter: Diego Lovison > Assignee: Diego Lovison > Priority: Minor > Fix For: 10.0.0.Beta3 > > > Add a test case for the following scenario: > If a cache is configured for expiration an the intervall is != -1 there is a possiblity for a deadlock with JGroups and Infinispan threads because the reaper and any access to the same entry can cause a deadlock. > The possibility is higher if the configured interval for the reaper is shorter. > A thread dump might show something like followed: > "HotRod-hotrod-internalServerWorker-4-12" #279 prio=5 os_prio=0 tid=0x00007f35980b8800 nid=0xbbb waiting for monitor entry [0x00007f356cfb4000] > java.lang.Thread.State: BLOCKED (on object monitor) > at org.infinispan.commons.util.concurrent.jdk8backported.EquivalentConcurrentHashMapV8.compute(EquivalentConcurrentHashMapV8.java:1910) > - waiting to lock <0x0000000742cca028> (a org.infinispan.commons.util.concurrent.jdk8backported.EquivalentConcurrentHashMapV8$Node) > at org.infinispan.container.DefaultDataContainer.compute(DefaultDataContainer.java:335) > at org.infinispan.expiration.impl.ExpirationManagerImpl.handleInMemoryExpiration(ExpirationManagerImpl.java:135) > at org.infinispan.expiration.impl.ClusterExpirationManager.handleInMemoryExpiration(ClusterExpirationManager.java:152) > - locked <0x0000000742cc9898> (a org.infinispan.container.entries.metadata.MetadataTransientCacheEntry) > at org.infinispan.container.DefaultDataContainer.get(DefaultDataContainer.java:201) > "pool-7-thread-1" #158 prio=5 os_prio=0 tid=0x00007f35c816c000 nid=0xb35 waiting for monitor entry [0x00007f3575238000] > java.lang.Thread.State: BLOCKED (on object monitor) > at org.infinispan.expiration.impl.ExpirationManagerImpl.lambda$handleInMemoryExpiration$0(ExpirationManagerImpl.java:137) > - waiting to lock <0x0000000742cc9898> (a org.infinispan.container.entries.metadata.MetadataTransientCacheEntry) > at org.infinispan.expiration.impl.ExpirationManagerImpl$$Lambda$374/1904915245.compute(Unknown Source) > at org.infinispan.container.DefaultDataContainer.lambda$compute$3(DefaultDataContainer.java:336) > at org.infinispan.container.DefaultDataContainer$$Lambda$375/1917382785.apply(Unknown Source) > at org.infinispan.commons.util.concurrent.jdk8backported.EquivalentConcurrentHashMapV8.compute(EquivalentConcurrentHashMapV8.java:1919) > - locked <0x0000000742cca028> (a org.infinispan.commons.util.concurrent.jdk8backported.EquivalentConcurrentHashMapV8$Node) > at org.infinispan.container.DefaultDataContainer.compute(DefaultDataContainer.java:335) > at org.infinispan.expiration.impl.ExpirationManagerImpl.handleInMemoryExpiration(ExpirationManagerImpl.java:135) > at org.infinispan.expiration.impl.ClusterExpirationManager.processExpiration(ClusterExpirationManager.java:82) -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-10022) Tx compute command updates are not written to stores

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-10022?page=com.atlassian.jira.plugin... ] Dan Berindei updated ISPN-10022: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/6746, https://github.com/infinispan/infinispan/pull/6747 > Tx compute command updates are not written to stores > ---------------------------------------------------- > > Key: ISPN-10022 > URL: https://issues.jboss.org/browse/ISPN-10022 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.4.8.Final, 10.0.0.Beta2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Beta3, 9.4.9.Final > > > {{TxBatchUpdater}} collects the modifications from all the commands in a transaction in order to write them to the stores. However, it doesn't implement the {{visitCompute*}} commands, so it doesn't collect any modifications from {{compute()}}, {{computeIfAbsent()}}, and {{computeIfPresent()}}. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-10022) Tx compute command updates are not written to stores

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-10022?page=com.atlassian.jira.plugin... ] Dan Berindei updated ISPN-10022: -------------------------------- Status: Open (was: New) > Tx compute command updates are not written to stores > ---------------------------------------------------- > > Key: ISPN-10022 > URL: https://issues.jboss.org/browse/ISPN-10022 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.4.8.Final, 10.0.0.Beta2 > Reporter: Dan Berindei > Priority: Major > Fix For: 10.0.0.Beta3, 9.4.9.Final > > > {{TxBatchUpdater}} collects the modifications from all the commands in a transaction in order to write them to the stores. However, it doesn't implement the {{visitCompute*}} commands, so it doesn't collect any modifications from {{compute()}}, {{computeIfAbsent()}}, and {{computeIfPresent()}}. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-10022) Tx compute command updates are not written to stores

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-10022?page=com.atlassian.jira.plugin... ] Dan Berindei reassigned ISPN-10022: ----------------------------------- Assignee: Dan Berindei > Tx compute command updates are not written to stores > ---------------------------------------------------- > > Key: ISPN-10022 > URL: https://issues.jboss.org/browse/ISPN-10022 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.4.8.Final, 10.0.0.Beta2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Beta3, 9.4.9.Final > > > {{TxBatchUpdater}} collects the modifications from all the commands in a transaction in order to write them to the stores. However, it doesn't implement the {{visitCompute*}} commands, so it doesn't collect any modifications from {{compute()}}, {{computeIfAbsent()}}, and {{computeIfPresent()}}. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-10027) Operator README and repo docs

by Don Naro (Jira)

Don Naro created ISPN-10027: ------------------------------- Summary: Operator README and repo docs Key: ISPN-10027 URL: https://issues.jboss.org/browse/ISPN-10027 Project: Infinispan Issue Type: Enhancement Components: Documentation-Core Reporter: Don Naro Assignee: Don Naro -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

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 2019