infinispan-issues April 2017

infinispan-issues@lists.jboss.org

1 participants
425 discussions

[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)

7 years, 9 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)

7 years, 9 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)

7 years, 9 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)

7 years, 9 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)

7 years, 9 months

1
0
0 / 0

← Newer
1
...
40
41
42
43
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues April 2017