July 2017 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-7963) Relocate Infinispan Hibernate cache provider

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-7963?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-7963: ----------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/5254, https://github.com/infinispan/infinispan/pull/5268 (was: https://github.com/infinispan/infinispan/pull/5254) > Relocate Infinispan Hibernate cache provider > -------------------------------------------- > > Key: ISPN-7963 > URL: https://issues.jboss.org/browse/ISPN-7963 > Project: Infinispan > Issue Type: Task > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > > Relocate Infinispan Hibernate second-level cache implementation to the Infinispan repository. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8008) Add Fault-tolerance to write-behind stores

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-8008?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec reassigned ISPN-8008: ----------------------------------------- Assignee: Ryan Emerson (was: Sebastian Łaskawiec) > Add Fault-tolerance to write-behind stores > ------------------------------------------ > > Key: ISPN-8008 > URL: https://issues.jboss.org/browse/ISPN-8008 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Reporter: Ryan Emerson > Assignee: Ryan Emerson > > Currently when a store is configured to be write-behind, three attempts are made to write the queued modifications to the store. If all three attempts fail, then this error is simply logged and the modifications are never written to the store. > We should allow users to configure a write-behind store so that: In the event that a write-behind fails, further operations on the cache are not allowed and the modifications which failed to write to the store are queued indefinitely. Once the underlying store becomes available, the queued modifications should be written and then the cache should become available. > To determine whether a store has become available again, the AsyncCacheWriter will have to poll the store's availability. Currently the CacheWriter interface does not allow such behaviour, therefore there are two options: > * Attempt a write and catch an exception if the store is not currently available > * Add a method to return the current status of a store to the CacheWriter interface -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2019) Allow HotRod to ues String keys for interoperability with REST and Memcached

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-2019?page=com.atlassian.jira.plugin.... ] Tristan Tarrant closed ISPN-2019. --------------------------------- Resolution: Out of Date Superseded by compatiblity mode and transcoding > Allow HotRod to ues String keys for interoperability with REST and Memcached > ---------------------------------------------------------------------------- > > Key: ISPN-2019 > URL: https://issues.jboss.org/browse/ISPN-2019 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Affects Versions: 5.1.4.FINAL > Reporter: NadirX > Priority: Trivial > > In JDG multiple server protocols can be mapped to the same caches. Since HotRod uses ByteArrayKey keys, it is not possible to read/write keys which need to be accessed via REST and/or Memcached. Maybe add a flag so that a key is interpreted as a String. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2174) CommandAwareRpcDispatcher swallows thread interruptions

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-2174?page=com.atlassian.jira.plugin.... ] Tristan Tarrant closed ISPN-2174. --------------------------------- Resolution: Out of Date > CommandAwareRpcDispatcher swallows thread interruptions > ------------------------------------------------------- > > Key: ISPN-2174 > URL: https://issues.jboss.org/browse/ISPN-2174 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 5.1.5.FINAL > Reporter: Michal Linhard > Assignee: Galder Zamarreño > Labels: jdg, jdg6 > > When interruption happens in FutureCollator.getResponseList() method > see > https://github.com/infinispan/infinispan/blob/5.1.x/core/src/main/java/or... > it is ignored and later wrongly dealt with as TimeoutException > (The original exception is not even set as cause anywhere) > This disables possibility of interrupting some cache operations. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-924) Support Atomic arithmetic operations in the API

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-924?page=com.atlassian.jira.plugin.s... ] Tristan Tarrant closed ISPN-924. -------------------------------- Fix Version/s: 9.1.0.Final Assignee: Pedro Ruivo Resolution: Done Implemented in ISPN-7284 > Support Atomic arithmetic operations in the API > ----------------------------------------------- > > Key: ISPN-924 > URL: https://issues.jboss.org/browse/ISPN-924 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Reporter: Erik Salter > Assignee: Pedro Ruivo > Fix For: 9.1.0.Final > > > It would be useful if Infinispan supported cluster-wide atomic operations for java.lang.Number types in the API -- similar to the AtomicX API in Java. > Right now, to cobble this functionality, we'd need to do something like: > - Start a tx > - Single-lock a key > - Get and increment > - Commit > - And, of course, handle the cache exceptions =) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2810) In REST, default values for maxIdleTimeSeconds and timeToLiveSeconds should be 0

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-2810?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec reassigned ISPN-2810: ----------------------------------------- Assignee: Sebastian Łaskawiec (was: Galder Zamarreño) > In REST, default values for maxIdleTimeSeconds and timeToLiveSeconds should be 0 > -------------------------------------------------------------------------------- > > Key: ISPN-2810 > URL: https://issues.jboss.org/browse/ISPN-2810 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Affects Versions: 5.2.0.Final > Reporter: Dan Berindei > Assignee: Sebastian Łaskawiec > > Contrary to what ISPN-732 says, timeToLiveSeconds=0 and maxIdleTimeSeconds=0 are now treated correctly by the server and the entry is stored in the cache with the default lifespan/maxIdle. > But if the user PUTs or POSTs an entry and doesn't specify timeToLiveSeconds=0 and maxIdleTimeSeconds=0 explicitly, the entries are stored with infinite lifespan/maxIdle. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1307) REST protocol improvements for version 2

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-1307?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec reassigned ISPN-1307: ----------------------------------------- Assignee: Sebastian Łaskawiec (was: Galder Zamarreño) > REST protocol improvements for version 2 > ---------------------------------------- > > Key: ISPN-1307 > URL: https://issues.jboss.org/browse/ISPN-1307 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Protocols > Reporter: Galder Zamarreño > Assignee: Sebastian Łaskawiec > Labels: REST > > This JIRA is meant to act as an umbrella for improvements we might want to do in the REST protocol. For example: > - As shown in ISPN-1285 and https://docs.jboss.org/author/display/ISPN/Accessing+data+in+Infinispan+v..., the use of 0 as timeToLiveSeconds and/or maxIdleTimeSeconds parameter(s) is not very intuitive and it's not even symmetric. This should be sorted out. This has been highlighted again in ISPN-1425. One option could be to use -2 as @DefaultValue in order to distinguish between no values given and other options. > This JIRA should also figure out how to support multiple REST protocol versions. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8008) Add Fault-tolerance to write-behind stores

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-8008?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec reassigned ISPN-8008: ----------------------------------------- Assignee: Sebastian Łaskawiec (was: Ryan Emerson) > Add Fault-tolerance to write-behind stores > ------------------------------------------ > > Key: ISPN-8008 > URL: https://issues.jboss.org/browse/ISPN-8008 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Reporter: Ryan Emerson > Assignee: Sebastian Łaskawiec > > Currently when a store is configured to be write-behind, three attempts are made to write the queued modifications to the store. If all three attempts fail, then this error is simply logged and the modifications are never written to the store. > We should allow users to configure a write-behind store so that: In the event that a write-behind fails, further operations on the cache are not allowed and the modifications which failed to write to the store are queued indefinitely. Once the underlying store becomes available, the queued modifications should be written and then the cache should become available. > To determine whether a store has become available again, the AsyncCacheWriter will have to poll the store's availability. Currently the CacheWriter interface does not allow such behaviour, therefore there are two options: > * Attempt a write and catch an exception if the store is not currently available > * Add a method to return the current status of a store to the CacheWriter interface -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1242) Add dynamic grouping capabilities for unmodifiable key classes.

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-1242?page=com.atlassian.jira.plugin.... ] Tristan Tarrant closed ISPN-1242. --------------------------------- Resolution: Won't Fix > Add dynamic grouping capabilities for unmodifiable key classes. > --------------------------------------------------------------- > > Key: ISPN-1242 > URL: https://issues.jboss.org/browse/ISPN-1242 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 5.0.0.CR7 > Reporter: Erik Salter > > The grouping API should be enhanced to add grouping capabilities to a a cache's put() or replace() methods. > This encompasses the following scenario: > Cache A uses a custom key class where the group is dynamically generated. Cache B's key is an unmodifiable String that needs to be grouped with the dynamic value of a key from Cache A. (Cache B's key can't be encapsulated in a custom key class since it needs to be queried from external entities that will not know the group context). > And in pseudo-code: > {code} > Group class InternalResourceKey { > String group; > ... > @Group > String getGroup() { > return group; > } > } > InternalResourceKey key = new InternalResourceKey(); > {code} > ... > {code} > resourceCache.lock( key ); > // Get the previous result. > ResourceResult result = resourceCache.get( key ); > ResourceResult newResult = doWork( key, result ); > resourceCache.put( key, newResult ); > // I also want to group an external identifier that an external client knows about with the result so they will be on the same node > employeeCache.put( "111-111-1111", newResult, key.getGroup() ); > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6677) Deal with unavailable dependencies during startup

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-6677?page=com.atlassian.jira.plugin.... ] Ryan Emerson reassigned ISPN-6677: ---------------------------------- Assignee: Ryan Emerson (was: Sebastian Łaskawiec) > Deal with unavailable dependencies during startup > ------------------------------------------------- > > Key: ISPN-6677 > URL: https://issues.jboss.org/browse/ISPN-6677 > Project: Infinispan > Issue Type: Feature Request > Components: Cloud Integrations > Reporter: Sebastian Łaskawiec > Assignee: Ryan Emerson > Priority: Blocker > > In Kubernetes not all Pods start at the same time. It is perfectly possible to start first Infinispan and a bit later the database (in this configuration we are assuming that Infinispan has a dependency to DB). Note that this setup would fails. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2017