April 2017 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-7224) Support synchronous get in Spring's cache abstraction

by Mike Noordermeer (JIRA)

[ https://issues.jboss.org/browse/ISPN-7224?page=com.atlassian.jira.plugin.... ] Mike Noordermeer commented on ISPN-7224: ---------------------------------------- Another issue is that {{get(Object key, Callable<T> valueLoader)}} does not handle {{null}}-values. It should be inserting {{NullValue.NULL}} if the result of the {{valueLoader}} is {{null}} > Support synchronous get in Spring's cache abstraction > ----------------------------------------------------- > > Key: ISPN-7224 > URL: https://issues.jboss.org/browse/ISPN-7224 > Project: Infinispan > Issue Type: Feature Request > Components: Spring Integration > Reporter: Stéphane Nicoll > Assignee: Sebastian Łaskawiec > Priority: Critical > Fix For: 9.0.0.Beta1, 9.0.0.Final > > > Spring Framework 4.3 has introduced a read-through option See https://jira.spring.io/browse/SPR-9254 for more details. In practice this would require you to compile against 4.3 and implement the additional method. > The code is meant to be backward compatible with previous version, as long as you're guarding the new exception in an inner class, see [this implementation for an example|https://github.com/hazelcast/hazelcast/blob/37ba79c4a8d35617c5f6a...] > Let me know if I can help. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7697) DefaultDataContainer.containsKey expires entry without synchronization and notification

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-7697?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-7697: -------------------------------- Status: Open (was: New) > DefaultDataContainer.containsKey expires entry without synchronization and notification > --------------------------------------------------------------------------------------- > > Key: ISPN-7697 > URL: https://issues.jboss.org/browse/ISPN-7697 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.0.0.Final > Reporter: Radim Vansa > Assignee: William Burns > > {{DefaultDataContainer.containsKey}} calls entries.remove if the entry is expired without any checks/atomicity. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7696) RemoveExpired could be called with updated value

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-7696?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-7696: -------------------------------- Fix Version/s: 9.1.0.Final > RemoveExpired could be called with updated value > ------------------------------------------------ > > Key: ISPN-7696 > URL: https://issues.jboss.org/browse/ISPN-7696 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.0.0.Final > Reporter: Radim Vansa > Assignee: William Burns > Fix For: 9.1.0.Final > > > In {{ClusterExpirationManager.handleLifespanExpireEntry}} the value for {{removeExpired}} is retrieved in the {{Runnable}}, which is not executed under synchronized > block. There is a comment in CEM.handleInMemoryExpiration about the need > for synchronization, but it seems to me that the Cache.removeExpired > does not get the value we're checking the metadata for - there is a > window when the value can change after we've checked the expiration. > The value should stored in local variable while under synchronization, and captured in the Runnable/lambda. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7696) RemoveExpired could be called with updated value

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-7696?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-7696: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/5054 > RemoveExpired could be called with updated value > ------------------------------------------------ > > Key: ISPN-7696 > URL: https://issues.jboss.org/browse/ISPN-7696 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.0.0.Final > Reporter: Radim Vansa > Assignee: William Burns > Fix For: 9.1.0.Final > > > In {{ClusterExpirationManager.handleLifespanExpireEntry}} the value for {{removeExpired}} is retrieved in the {{Runnable}}, which is not executed under synchronized > block. There is a comment in CEM.handleInMemoryExpiration about the need > for synchronization, but it seems to me that the Cache.removeExpired > does not get the value we're checking the metadata for - there is a > window when the value can change after we've checked the expiration. > The value should stored in local variable while under synchronization, and captured in the Runnable/lambda. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7686) Stat getNumberOfEntries should include passivated entries

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-7686?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-7686: ------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/5037, https://github.com/infinispan/infinispan/pull/5052 (was: https://github.com/infinispan/infinispan/pull/5037) > Stat getNumberOfEntries should include passivated entries > --------------------------------------------------------- > > Key: ISPN-7686 > URL: https://issues.jboss.org/browse/ISPN-7686 > Project: Infinispan > Issue Type: Enhancement > Components: JMX, reporting and management > Affects Versions: 9.0.0.CR4 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Fix For: 9.0.0.Final > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7696) RemoveExpired could be called with updated value

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-7696?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-7696: -------------------------------- Status: Open (was: New) > RemoveExpired could be called with updated value > ------------------------------------------------ > > Key: ISPN-7696 > URL: https://issues.jboss.org/browse/ISPN-7696 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.0.0.Final > Reporter: Radim Vansa > Assignee: William Burns > > In {{ClusterExpirationManager.handleLifespanExpireEntry}} the value for {{removeExpired}} is retrieved in the {{Runnable}}, which is not executed under synchronized > block. There is a comment in CEM.handleInMemoryExpiration about the need > for synchronization, but it seems to me that the Cache.removeExpired > does not get the value we're checking the metadata for - there is a > window when the value can change after we've checked the expiration. > The value should stored in local variable while under synchronization, and captured in the Runnable/lambda. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7698) Administration console - minor issues with removing node

by Roman Macor (JIRA)

Roman Macor created ISPN-7698: --------------------------------- Summary: Administration console - minor issues with removing node Key: ISPN-7698 URL: https://issues.jboss.org/browse/ISPN-7698 Project: Infinispan Issue Type: Bug Components: JMX, reporting and management Affects Versions: 9.0.0.Final Reporter: Roman Macor Priority: Minor Removing node opens confirmation dialog which says: Remove server new-node from undefined? Suggested fix: The node must be in stopped state to perform the operation so the cluster info is not available. The confirmation might just say: Remove server new-node? After clicking confirm the Loading icon is displayed until users click on one of the tabs. (The node is successfully removed) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7224) Support synchronous get in Spring's cache abstraction

by Stéphane Nicoll (JIRA)

[ https://issues.jboss.org/browse/ISPN-7224?page=com.atlassian.jira.plugin.... ] Stéphane Nicoll commented on ISPN-7224: --------------------------------------- What Mike said. Sebastian, do you seriously expecting us to lock in a smart way in an abstraction while stating at the same time you can't knowing what is actually happening behind the scenes? I mean, the purpose of that separate method (and contract) is to give a chance for cache implementations to do the right thing. I think that's pretty obvious we can't do that with our abstraction. That extra method is also only called when the sync flag is true and we ask [users to refer to the doc of the cache provider for more details|http://docs.spring.io/spring-framework/docs/current/spring-framework-reference/htmlsingle/#cache-annotations-cacheable-synchronized]. Whatever you decide to do should probably be explicitly documented. Thanks! > Support synchronous get in Spring's cache abstraction > ----------------------------------------------------- > > Key: ISPN-7224 > URL: https://issues.jboss.org/browse/ISPN-7224 > Project: Infinispan > Issue Type: Feature Request > Components: Spring Integration > Reporter: Stéphane Nicoll > Assignee: Sebastian Łaskawiec > Priority: Critical > Fix For: 9.0.0.Beta1, 9.0.0.Final > > > Spring Framework 4.3 has introduced a read-through option See https://jira.spring.io/browse/SPR-9254 for more details. In practice this would require you to compile against 4.3 and implement the additional method. > The code is meant to be backward compatible with previous version, as long as you're guarding the new exception in an inner class, see [this implementation for an example|https://github.com/hazelcast/hazelcast/blob/37ba79c4a8d35617c5f6a...] > Let me know if I can help. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7697) DefaultDataContainer.containsKey expires entry without synchronization and notification

by Radim Vansa (JIRA)

Radim Vansa created ISPN-7697: --------------------------------- Summary: DefaultDataContainer.containsKey expires entry without synchronization and notification Key: ISPN-7697 URL: https://issues.jboss.org/browse/ISPN-7697 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 9.0.0.Final Reporter: Radim Vansa Assignee: William Burns {{DefaultDataContainer.containsKey}} calls entries.remove if the entry is expired without any checks/atomicity. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7696) RemoveExpired could be called with updated value

by Radim Vansa (JIRA)

Radim Vansa created ISPN-7696: --------------------------------- Summary: RemoveExpired could be called with updated value Key: ISPN-7696 URL: https://issues.jboss.org/browse/ISPN-7696 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 9.0.0.Final Reporter: Radim Vansa Assignee: William Burns In {{ClusterExpirationManager.handleLifespanExpireEntry}} the value for {{removeExpired}} is retrieved in the {{Runnable}}, which is not executed under synchronized block. There is a comment in CEM.handleInMemoryExpiration about the need for synchronization, but it seems to me that the Cache.removeExpired does not get the value we're checking the metadata for - there is a window when the value can change after we've checked the expiration. The value should stored in local variable while under synchronization, and captured in the Runnable/lambda. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues April 2017