April 2017 - infinispan-issues - Jboss List Archives

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

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-7224?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec commented on ISPN-7224: ------------------------------------------- I guess you are referring to [this piece of the code|https://github.com/infinispan/infinispan/blob/master/spring/spring4/...]: {code} @Override public <T> T get(Object key, Callable<T> valueLoader) { return cacheImplementation.get(key, valueLoader); } {code} This in turn invokes [this|https://github.com/infinispan/infinispan/blob/master/spring/spring4/...]: {code} @Override public <T> T get(Object key, Callable<T> valueLoader) { return (T) nativeCache.computeIfAbsent(key, keyToBeInserted -> { try { return valueLoader.call(); //loading value in a caller's thread } catch (Exception e) { throw ValueRetrievalExceptionResolver.throwValueRetrievalException(key, valueLoader, e); } }); } {code} >From Spring Cache documentation|http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/cache/Cache.html#get-java.lang.Object-java.util.concurrent.Callable-] we can learn that: {quote} Return the value to which this cache maps the specified key, obtaining that value from valueLoader if necessary. This method provides a simple substitute for the conventional "if cached, return; otherwise create, cache and return" pattern. If possible, implementations should ensure that the loading operation is synchronized so that the specified valueLoader is only called once in case of concurrent access on the same key. {quote} So Spring suggests locking but doesn't enforce it (it is still up to the implementation). And of course you are absolutely right that [computeIfAbsent|https://docs.oracle.com/javase/8/docs/api/java/util/Map.h...] is not atomic: {quote} The default implementation makes no guarantees about synchronization or atomicity properties of this method. Any implementation providing atomicity guarantees must override this method and document its concurrency properties. In particular, all implementations of subinterface ConcurrentMap must document whether the function is applied once atomically only if the value is not present. {quote} To sum it up - I believe we are aligned with the Spring Cache contract (since it doesn't really enforce synchronization). With our implementation we decided to avoid locking (we would need to lock the key, blocking caller's thread is not sufficient because you may use different integrations (like CDI) at the same time) in favor of performance. > 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)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7694) Provide JDK SSLContext/Netty OpenSSLContext bridge and allow using OpenSSL

by Sebastian Łaskawiec (JIRA)

Sebastian Łaskawiec created ISPN-7694: ----------------------------------------- Summary: Provide JDK SSLContext/Netty OpenSSLContext bridge and allow using OpenSSL Key: ISPN-7694 URL: https://issues.jboss.org/browse/ISPN-7694 Project: Infinispan Issue Type: Feature Request Reporter: Sebastian Łaskawiec Assignee: Sebastian Łaskawiec Priority: Critical In order to use OpenSSL with Netty (which is much faster than JDK implementation), and stick with WildFly SSL initialization, we need to provide a bridge from JDK SSLContext into OpenSSLContext. The next step is to use this bridge here: https://github.com/infinispan/infinispan/blob/fd3061a684c13aa7c22d215f439... Finally, we need to put {{netty-tcnative}} into the server's classpath. More information: http://netty.io/wiki/requirements-for-4.x.html#tls-with-openssl -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7693) Create Authenticated JMX Tests

by Ryan Emerson (JIRA)

Ryan Emerson created ISPN-7693: ---------------------------------- Summary: Create Authenticated JMX Tests Key: ISPN-7693 URL: https://issues.jboss.org/browse/ISPN-7693 Project: Infinispan Issue Type: Task Components: Test Suite - Core Affects Versions: 9.0.0.Final Reporter: Ryan Emerson Assignee: Ryan Emerson Currently we don't have any test cases for invoking JMX operations on secured caches. Such test case(s) should get a JMXPrincipal in the ACC -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5728) Implement all the default methods in Java 8's Map interface

by Katia Aresti (JIRA)

[ https://issues.jboss.org/browse/ISPN-5728?page=com.atlassian.jira.plugin.... ] Katia Aresti updated ISPN-5728: ------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/5046 Just compute, computeIfPresent and computeIfAbsent methods > Implement all the default methods in Java 8's Map interface > ----------------------------------------------------------- > > Key: ISPN-5728 > URL: https://issues.jboss.org/browse/ISPN-5728 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 8.0.0.Final > Reporter: Dan Berindei > Assignee: Katia Aresti > > Java 8 added many new methods to the {{Map}} interface. Some of them were already present in {{ConcurrentMap}}, but others are new: {{getOrDefault()}}, {{forEach()}}, {{replaceAll()}}, {{computeIfAbsent()}}, {{computeIfPresent()}}, {{compute()}}, {{merge()}}. > We should try to write Infinispan-specific implementations wherever that would improve correctness and/or performance. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[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: ---------------------------------------- Unfortunately, this doesn't really work. The thread is not blocked and the Callable is executed multiple times on a concurrent get. This is because {{ConcurrentMap.computeIfAbsent()}} is used, which is not atomic ({{ConcurrentHashMap.computeIfAbsent()}} is). > 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)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7580) Use of marsheller is not consistent in all places

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/ISPN-7580?page=com.atlassian.jira.plugin.... ] Ramesh Reddy commented on ISPN-7580: ------------------------------------ [~anistor] Here is another stab at it, little less intrusive then the previous one https://github.com/rareddy/protostream/commit/c07db7ad90d7545e92aa0f0fdeb... This still requires the second commit on Infinispan core code base from above. > Use of marsheller is not consistent in all places > ------------------------------------------------- > > Key: ISPN-7580 > URL: https://issues.jboss.org/browse/ISPN-7580 > Project: Infinispan > Issue Type: Bug > Components: Marshalling, Remote Querying > Reporter: Ramesh Reddy > Assignee: Adrian Nistor > > Usage of extended ProtoStreamMarshaller is not consistent across all the code paths. For the purposes of Teiid translator, I have extended ProtoStreamMarshaller which knows to read/write byte streams in portable fashion for given message type, which are representions of a relational table in Teiid. This works fine, if I just use cache's get/put calls. > However, the same fails when used with RemoteQuery or Continuous query. The reason is, these classes circumvent extended Marsheller and go directly to serialization context registered to do the wrapping/unwrapping. Not only that there are few places code will type cast the SerializationContext to SerializationContextImpl object. Thus I can not even provide my own Serializer nor I can extend this as SerializationContextImpl is declared as final. These need to be corrected such that extended marsheller is used rather than hard coding them. > I am guessing this is first time anyone has even done this without using dedicated java classes as marshellers. > This is extremely critical for me to be fixed to move forward, I can provide the pull request for it? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues April 2017