May 2017 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-7777) Remote JCache implementation should use Hot Rod admin ops

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-7777?page=com.atlassian.jira.plugin.... ] Ryan Emerson resolved ISPN-7777. -------------------------------- Fix Version/s: 9.1.0.Alpha1 (was: 9.1.0.Final) Resolution: Done > Remote JCache implementation should use Hot Rod admin ops > --------------------------------------------------------- > > Key: ISPN-7777 > URL: https://issues.jboss.org/browse/ISPN-7777 > Project: Infinispan > Issue Type: Sub-task > Components: JCache > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 9.1.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7771) Common protocol server admin API

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-7771?page=com.atlassian.jira.plugin.... ] Ryan Emerson resolved ISPN-7771. -------------------------------- Fix Version/s: 9.1.0.Alpha1 (was: 9.1.0.Final) Resolution: Done > Common protocol server admin API > -------------------------------- > > Key: ISPN-7771 > URL: https://issues.jboss.org/browse/ISPN-7771 > Project: Infinispan > Issue Type: Sub-task > Components: Server > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 9.1.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7588) Admin operations to Hot Rod server

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-7588?page=com.atlassian.jira.plugin.... ] Ryan Emerson resolved ISPN-7588. -------------------------------- Fix Version/s: 9.1.0.Alpha1 (was: 9.1.0.Final) Resolution: Done > Admin operations to Hot Rod server > ---------------------------------- > > Key: ISPN-7588 > URL: https://issues.jboss.org/browse/ISPN-7588 > Project: Infinispan > Issue Type: Sub-task > Components: Integration > Reporter: Sebastian Łaskawiec > Assignee: Tristan Tarrant > Labels: FeedHenry > Fix For: 9.1.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7869) modules for EAP does not include all necessary indexes

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created ISPN-7869: -------------------------------------- Summary: modules for EAP does not include all necessary indexes Key: ISPN-7869 URL: https://issues.jboss.org/browse/ISPN-7869 Project: Infinispan Issue Type: Bug Components: WildFly modules Reporter: Wolf-Dieter Fink To use JCache with CDI annotations together with the WildFly modules it is necessary to have a jandex.idx index file within the jar files. This is needed for Wildfly, otherwise no annotations are found if the dependency (MANIFEST or jboss-deployment-structure.xml) is declared with annotations=true -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7802) Use chunked reads/writes in TcpTransport

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-7802?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-7802: ------------------------------- Fix Version/s: 9.0.2.Final > Use chunked reads/writes in TcpTransport > ---------------------------------------- > > Key: ISPN-7802 > URL: https://issues.jboss.org/browse/ISPN-7802 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 9.0.0.Final > Reporter: Radim Vansa > Assignee: Tristan Tarrant > Fix For: 9.1.0.Final, 9.1.0.Alpha1, 9.0.2.Final > > > The buffering implementation of {{TcpTransport.socketInputStream}} needs to use fixed size input buffer, rather than growing as {{BufferedInputStream}} does. Growing buffer can lead to excessive memory consumption on heap, and more importantly, by direct memory allocated in JDK classes and pooled in thread-local caches. > EDIT: As Tristan pointed out, the {{BufferedInputStream}} does not grow in our use case, but if {{TcpTransport}} passes a big {{byte[]}} buffer, the implementation works as read through/write through. Therefore we need to chunk all calls. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7868) RemtoeStore support for encryption and authentication

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-7868: ------------------------------------- Summary: RemtoeStore support for encryption and authentication Key: ISPN-7868 URL: https://issues.jboss.org/browse/ISPN-7868 Project: Infinispan Issue Type: Enhancement Reporter: Tristan Tarrant The RemoteStore does not support configuring the underlying RemoteCacheManager with encryption and/or authentication. At the very least we should support encryption with both truststore and keystore, and SASL with PLAIN, MD5 and EXTERNAL. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7802) Use chunked reads/writes in TcpTransport

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-7802?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-7802: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.1.0.Final 9.1.0.Alpha1 Resolution: Done > Use chunked reads/writes in TcpTransport > ---------------------------------------- > > Key: ISPN-7802 > URL: https://issues.jboss.org/browse/ISPN-7802 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 9.0.0.Final > Reporter: Radim Vansa > Assignee: Tristan Tarrant > Fix For: 9.1.0.Final, 9.1.0.Alpha1 > > > The buffering implementation of {{TcpTransport.socketInputStream}} needs to use fixed size input buffer, rather than growing as {{BufferedInputStream}} does. Growing buffer can lead to excessive memory consumption on heap, and more importantly, by direct memory allocated in JDK classes and pooled in thread-local caches. > EDIT: As Tristan pointed out, the {{BufferedInputStream}} does not grow in our use case, but if {{TcpTransport}} passes a big {{byte[]}} buffer, the implementation works as read through/write through. Therefore we need to chunk all calls. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7802) Use chunked reads/writes in TcpTransport

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-7802?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-7802: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/5133 > Use chunked reads/writes in TcpTransport > ---------------------------------------- > > Key: ISPN-7802 > URL: https://issues.jboss.org/browse/ISPN-7802 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 9.0.0.Final > Reporter: Radim Vansa > Assignee: Tristan Tarrant > > The buffering implementation of {{TcpTransport.socketInputStream}} needs to use fixed size input buffer, rather than growing as {{BufferedInputStream}} does. Growing buffer can lead to excessive memory consumption on heap, and more importantly, by direct memory allocated in JDK classes and pooled in thread-local caches. > EDIT: As Tristan pointed out, the {{BufferedInputStream}} does not grow in our use case, but if {{TcpTransport}} passes a big {{byte[]}} buffer, the implementation works as read through/write through. Therefore we need to chunk all calls. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7802) Use chunked reads/writes in TcpTransport

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-7802?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-7802: ------------------------------- Status: Open (was: New) > Use chunked reads/writes in TcpTransport > ---------------------------------------- > > Key: ISPN-7802 > URL: https://issues.jboss.org/browse/ISPN-7802 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 9.0.0.Final > Reporter: Radim Vansa > Assignee: Tristan Tarrant > > The buffering implementation of {{TcpTransport.socketInputStream}} needs to use fixed size input buffer, rather than growing as {{BufferedInputStream}} does. Growing buffer can lead to excessive memory consumption on heap, and more importantly, by direct memory allocated in JDK classes and pooled in thread-local caches. > EDIT: As Tristan pointed out, the {{BufferedInputStream}} does not grow in our use case, but if {{TcpTransport}} passes a big {{byte[]}} buffer, the implementation works as read through/write through. Therefore we need to chunk all calls. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3128) Better support for (Spring) read caching

by Mike Noordermeer (JIRA)

[ https://issues.jboss.org/browse/ISPN-3128?page=com.atlassian.jira.plugin.... ] Mike Noordermeer commented on ISPN-3128: ---------------------------------------- > Spring 4.3.8 (and possibly earlier versions as well) invokes cache.put(Object, Object) for @CachePut methods, and cache.get(Object, Callable) for @Cacheable methods. I think that's only true for a synchronized cache, not for a standard cache. There are also some issues with the current implementation, see ISPN-7224 > Better support for (Spring) read caching > ---------------------------------------- > > Key: ISPN-3128 > URL: https://issues.jboss.org/browse/ISPN-3128 > Project: Infinispan > Issue Type: Feature Request > Components: Spring Integration > Affects Versions: 5.3.0.Beta2 > Environment: Spring 3.1+ > Reporter: Mike Noordermeer > Assignee: Gustavo Fernandes > > We're having a bit of an issue using Infinispan as backing cache for Spring's Caching annotations. The reasons are clear, but I haven't found a proper solution yet. I thought I would describe the issues in a feature request, so we can try to make the necessary changes to fix the situation. > As already described in [the forums|https://community.jboss.org/thread/201086], an Infinispan cache in invalidation mode sends an invalidation message to other cache nodes if something is put into the cache. This conflicts with Spring's idea of {{@Cacheable}} annotations, which are ment to provide read caching for methods. Imagine the following scenario: > - Method A is annotated with {{@Cacheable}}, backed by a cache in invalidation mode > - Node X calls Method A, the method is executed and the return value is locally cached (and an invalidation message is sent to Node Y) > - Node Y calls Method A, the method is executed and the return value is locally cached, *also, the cache of Node X is invalidated* > - Node X calls Method A and has to execute the method again, since its cache is gone, etc... etc... > The reason we want to be able to invalidate the read cache, is because if the application executed an update method for the underlying data (usually marked with {{@CacheEvict}} or {{@CachePut}}) we *do* want to invalidate the other ndoes. > In Infinispan, this problem can be solved by caching using {{cache.putForExternalRead()}}. That will not invalidate other caches on a put, but will invalidate the cache when asked explicitly. However, simply changing {{put()}} to {{putForExternalRead()}} in {{SpringCache}} leads to a couple of other issues: > - This is probably not the behaviour everyone wants (people that do not use Spring annotations, but expect the usual Infinispan behaviour). > - Changing {{put()}} to {{putForExternalRead()}} would break the expected {{@CachePut}} behaviour (a new value is generated, so the old values should be invalidated), but it would fix {{@Cacheable}} behaviour. > Maybe there should be an option in the factory bean to switch between {{put()}} and {{putForExternalRead()}}? Maybe Spring should change or amend its interface so we can differentiate between calls coming from {{@CachePut}} and calls coming from {{@Cacheable}}? An other option is to make the invalidation behaviour configurable in Infinispan (that's the way Ehcache handles this issue, you can choose if puts or updates should be replicated, or just replicate invalidations). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 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 May 2017