September 2017 - infinispan-issues

[JBoss JIRA] (ISPN-8127) Prevent Hot Rod client from failing on certain scenarios

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-8127?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec commented on ISPN-8127: ------------------------------------------- The most common example is using Infinispan Hot Rod client in Cloud environment for caching method results (via JCache or Spring Cache). In that scenario, when the server is down we shouldn't throw an exception but just return null. In such scenarios, missing value or server failure are equal to the client - it just needs to execute the expensive method (whether it's a DB call, going to a remote service - it doesn't matter). > Prevent Hot Rod client from failing on certain scenarios > -------------------------------------------------------- > > Key: ISPN-8127 > URL: https://issues.jboss.org/browse/ISPN-8127 > Project: Infinispan > Issue Type: Enhancement > Components: Cloud Integrations, Remote Protocols > Reporter: Sebastian Łaskawiec > > In some scenarios it should be possible to use Hot Rod client in graceful mode. It shouldn't fail when it can not contact the server (especially when {{putIfAbsent}} is concerned). > As long as near caching is concerned, we could provide stale data in such scenario. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8310) LockedStream evalAll

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8310?page=com.atlassian.jira.plugin.... ] Work on ISPN-8310 started by William Burns. ------------------------------------------- > LockedStream evalAll > -------------------- > > Key: ISPN-8310 > URL: https://issues.jboss.org/browse/ISPN-8310 > Project: Infinispan > Issue Type: Feature Request > Reporter: William Burns > Assignee: William Burns > > We need a way to run a command for all data in the cache (while under a lock) but also return a value for the data processed. > There are a few different APIs we could do for this having a {{Cache<K, V>}} > blocking variant > {code} > <R> Map<K, R> evalAll(BiFunction<Cache<K, V>, ? super CacheEntry<K, V>, R> biFunction) > {code} > back pressure aware variant - this would have to be a hot observer on subscribe > {code} > <R> Producer<R> evalAll(BiFunction<Cache<K, V>, ? super CacheEntry<K, V> R> biFunction) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8310) LockedStream evalAll

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8310?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-8310: -------------------------------- Status: Open (was: New) > LockedStream evalAll > -------------------- > > Key: ISPN-8310 > URL: https://issues.jboss.org/browse/ISPN-8310 > Project: Infinispan > Issue Type: Feature Request > Reporter: William Burns > Assignee: William Burns > > We need a way to run a command for all data in the cache (while under a lock) but also return a value for the data processed. > There are a few different APIs we could do for this having a {{Cache<K, V>}} > blocking variant > {code} > <R> Map<K, R> evalAll(BiFunction<Cache<K, V>, ? super CacheEntry<K, V>, R> biFunction) > {code} > back pressure aware variant - this would have to be a hot observer on subscribe > {code} > <R> Producer<R> evalAll(BiFunction<Cache<K, V>, ? super CacheEntry<K, V> R> biFunction) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8310) LockedStream evalAll

by William Burns (JIRA)

William Burns created ISPN-8310: ----------------------------------- Summary: LockedStream evalAll Key: ISPN-8310 URL: https://issues.jboss.org/browse/ISPN-8310 Project: Infinispan Issue Type: Feature Request Reporter: William Burns Assignee: William Burns We need a way to run a command for all data in the cache (while under a lock) but also return a value for the data processed. There are a few different APIs we could do for this having a {{Cache<K, V>}} blocking variant {code} <R> Map<K, R> evalAll(BiFunction<Cache<K, V>, ? super CacheEntry<K, V>, R> biFunction) {code} back pressure aware variant - this would have to be a hot observer on subscribe {code} <R> Producer<R> evalAll(BiFunction<Cache<K, V>, ? super CacheEntry<K, V> R> biFunction) {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8298) DistAsyncFuncTest.testLockedStreamSetValue random test failure

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8298?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-8298: ------------------------------------- I can't figure out why this is failing exactly, but from the stack trace there must be some kind of timing issue in ReplListener that I just can't spot atm. Unfortunately this means that hundreds of tests could fail randomly if this is the case, since they all rely on ReplListener to tell when a command has been properly replicated. I might suggest rewriting this portion if we cannot locate the issue, although that could also have its own issues :( > DistAsyncFuncTest.testLockedStreamSetValue random test failure > -------------------------------------------------------------- > > Key: ISPN-8298 > URL: https://issues.jboss.org/browse/ISPN-8298 > Project: Infinispan > Issue Type: Bug > Reporter: William Burns > Assignee: William Burns > > Test failure at: http://ci.infinispan.org/job/Infinispan/job/master/144/ > Looking at the stack trace, this test failed before it even got to the lock stream. For some reason the async write wasn't completed properly... > It seems the ReplListener was just recently fixed for something similar with L1 invalidations https://github.com/infinispan/infinispan/commit/fb165dc25cba7f26652292a1f... I fear this test in general may not be very deterministic and could fail for any test using it. I would suggest replacing it possibly. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8299) LocalStreamIteratorWithPassivationTest.testConcurrentPassivation random failure

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8299?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-8299: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/5441 > LocalStreamIteratorWithPassivationTest.testConcurrentPassivation random failure > ------------------------------------------------------------------------------- > > Key: ISPN-8299 > URL: https://issues.jboss.org/browse/ISPN-8299 > Project: Infinispan > Issue Type: Bug > Reporter: William Burns > Assignee: William Burns > Fix For: 9.2.0.Final, 9.1.1.Final > > > Test failure at: http://ci.infinispan.org/job/Infinispan/job/master/144/ -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8299) LocalStreamIteratorWithPassivationTest.testConcurrentPassivation random failure

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8299?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-8299: -------------------------------- Fix Version/s: 9.2.0.Final 9.1.1.Final > LocalStreamIteratorWithPassivationTest.testConcurrentPassivation random failure > ------------------------------------------------------------------------------- > > Key: ISPN-8299 > URL: https://issues.jboss.org/browse/ISPN-8299 > Project: Infinispan > Issue Type: Bug > Reporter: William Burns > Assignee: William Burns > Fix For: 9.2.0.Final, 9.1.1.Final > > > Test failure at: http://ci.infinispan.org/job/Infinispan/job/master/144/ -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8299) LocalStreamIteratorWithPassivationTest.testConcurrentPassivation random failure

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8299?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-8299: ------------------------------------- This is caused by either one of the following: 1. Dist and Local iterator tests shared the same in memory backed store. Need to separate these (can cause failures if tests are ran together) 2. Rewiring the persistence manager a second time actually readds the same loader again a second time. We have to make sure that stopping the persistence manager actually removes stores so it can be restarted without failure. > LocalStreamIteratorWithPassivationTest.testConcurrentPassivation random failure > ------------------------------------------------------------------------------- > > Key: ISPN-8299 > URL: https://issues.jboss.org/browse/ISPN-8299 > Project: Infinispan > Issue Type: Bug > Reporter: William Burns > Assignee: William Burns > > Test failure at: http://ci.infinispan.org/job/Infinispan/job/master/144/ -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8281) Overload collect() to take Supplier and SerializableSupplier

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-8281?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-8281: ----------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/5421, https://github.com/infinispan/infinispan/pull/5440 > Overload collect() to take Supplier and SerializableSupplier > ------------------------------------------------------------ > > Key: ISPN-8281 > URL: https://issues.jboss.org/browse/ISPN-8281 > Project: Infinispan > Issue Type: Enhancement > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 9.2.0.Final > > > Whenever a collect() is called in a distributed environment, you have to wrap up in a serializable supplier method call to make it serializable, e.g. > {code} > Map<Integer, Long> totalPerHour = cache.values().stream() > .collect( > CacheCollectors.serializableCollector(() -> Collectors.groupingBy( > e -> getHourOfDay(e.departureTs), > Collectors.counting() > ))); > {code} > This is a bit clunky. We should overload collect to take a SerializableSupplier in CacheStream. > It would also be nice to have an overloaded version that takes Supplier in case you want to provide your own serialization for it. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8281) Overload collect() to take Supplier and SerializableSupplier

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-8281?page=com.atlassian.jira.plugin.... ] Work on ISPN-8281 started by Galder Zamarreño. ---------------------------------------------- > Overload collect() to take Supplier and SerializableSupplier > ------------------------------------------------------------ > > Key: ISPN-8281 > URL: https://issues.jboss.org/browse/ISPN-8281 > Project: Infinispan > Issue Type: Enhancement > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 9.2.0.Final > > > Whenever a collect() is called in a distributed environment, you have to wrap up in a serializable supplier method call to make it serializable, e.g. > {code} > Map<Integer, Long> totalPerHour = cache.values().stream() > .collect( > CacheCollectors.serializableCollector(() -> Collectors.groupingBy( > e -> getHourOfDay(e.departureTs), > Collectors.counting() > ))); > {code} > This is a bit clunky. We should overload collect to take a SerializableSupplier in CacheStream. > It would also be nice to have an overloaded version that takes Supplier in case you want to provide your own serialization for it. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 6 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2017