August 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5607) NearCache: it is possible to read stale data with a put/remove followed by a get

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5607?page=com.atlassian.jira.plugin.... ] Galder Zamarreño reassigned ISPN-5607: -------------------------------------- Assignee: Galder Zamarreño (was: Tristan Tarrant) > NearCache: it is possible to read stale data with a put/remove followed by a get > -------------------------------------------------------------------------------- > > Key: ISPN-5607 > URL: https://issues.jboss.org/browse/ISPN-5607 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.2.3.Final > Environment: one hotrod client with 2 hotrod servers > Reporter: Enrico Olivelli > Assignee: Galder Zamarreño > Priority: Blocker > Fix For: 8.0.0.Final, 7.2.5.Final > > > Writes to the NearCache do not invalidate/update local data on put/remove operations, and so the NearCache (LAZY MODE) is invalidated using an eventlistener in an asynch way. > It is possible for a client to write a value and issue a get on the same key, and the result of the get would not be the latest value but the one which was present before the update operation. > This happens frequently when there is very much traffic on the connection of the listener which receives the events for the NearCache. > It would be better at least to invalidate locally every entry modified from the client itself -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5607) NearCache: it is possible to read stale data with a put/remove followed by a get

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5607?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5607: ----------------------------------- Fix Version/s: 7.2.5.Final (was: 7.2.4.Final) > NearCache: it is possible to read stale data with a put/remove followed by a get > -------------------------------------------------------------------------------- > > Key: ISPN-5607 > URL: https://issues.jboss.org/browse/ISPN-5607 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.2.3.Final > Environment: one hotrod client with 2 hotrod servers > Reporter: Enrico Olivelli > Assignee: Tristan Tarrant > Priority: Blocker > Fix For: 8.0.0.Final, 7.2.5.Final > > > Writes to the NearCache do not invalidate/update local data on put/remove operations, and so the NearCache (LAZY MODE) is invalidated using an eventlistener in an asynch way. > It is possible for a client to write a value and issue a get on the same key, and the result of the get would not be the latest value but the one which was present before the update operation. > This happens frequently when there is very much traffic on the connection of the listener which receives the events for the NearCache. > It would be better at least to invalidate locally every entry modified from the client itself -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5664) Null is returned for a not expired entry in Hot Rod client

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5664?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-5664: ------------------------------------- The previous issue is a problem, however I found the real issue: https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o... That line should be passing timeService.wallClockTime() instead. The same with line 307. Otherwise they pass the expiration timeout value which will always be lower than unless they specify a huge timeout. > Null is returned for a not expired entry in Hot Rod client > ---------------------------------------------------------- > > Key: ISPN-5664 > URL: https://issues.jboss.org/browse/ISPN-5664 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 8.0.0.Beta2 > Reporter: William Burns > Assignee: William Burns > > For a mortal entry (lifespan > -1), overwriting it with lifespan=-1 (make it immortal) unexpectedly removes the entry like follows. > ~~~ > cache.put(key, "value1", 100, TimeUnit.SECONDS, 100, TimeUnit.SECONDS); > cache.get(key); // returns "value1" > cache.put(key, "value2", -1, TimeUnit.SECONDS, 100, TimeUnit.SECONDS); > cache.get(key); // returns null, expected "value2" > cache.put(key, "value3", -1, TimeUnit.SECONDS, 100, TimeUnit.SECONDS); > cache.get(key); // returns "value3" > ~~~ > In library mode, the 2nd get returns non-null as expected. The same behaviour is observed for a transient (maxIdle > -1) entry also. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5553) Functional Java 8 API

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5553?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-5553: ---------------------------------------- Javadocs for Infinispan 8.0.0.Beta3 not appearing... > Functional Java 8 API > --------------------- > > Key: ISPN-5553 > URL: https://issues.jboss.org/browse/ISPN-5553 > Project: Infinispan > Issue Type: Feature Request > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 8.0.0.CR1, 8.0.0.Final > > > Infinispan 8 is baselining on Java 8 and that enables a more advanced , functional, APIs to be built instead of relying on the traditional Map-like APIs. Such APIs, taking lambda functions, can improve on the current APIs in the following way: > * Being able to provide a write operation, where the operation is defined as a lambda, better enables conditional (CAS) like operations that are based in functions other than equality, e.g. version equality. If this functions can be executed atomically, they provide a better solution for Hot Rod version-based replace operations that currently can cause some weird behaviour (ISPN-4972) > * When operations are defined as lambdas, it's easier to move towards a model that tracks/replicates operations leading to state, rather than replicating state itself. This makes it easier to implement more-efficiently replicated alternative data structures, such as counts, lists...etc, and paths the way towards CRDTs, particularly CmRDT (Commutative Replicated Data Types) or operation-based CRDTs. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5553) Functional Java 8 API

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5553?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5553: ----------------------------------- Fix Version/s: 8.0.0.CR1 (was: 8.0.0.Beta3) > Functional Java 8 API > --------------------- > > Key: ISPN-5553 > URL: https://issues.jboss.org/browse/ISPN-5553 > Project: Infinispan > Issue Type: Feature Request > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 8.0.0.CR1, 8.0.0.Final > > > Infinispan 8 is baselining on Java 8 and that enables a more advanced , functional, APIs to be built instead of relying on the traditional Map-like APIs. Such APIs, taking lambda functions, can improve on the current APIs in the following way: > * Being able to provide a write operation, where the operation is defined as a lambda, better enables conditional (CAS) like operations that are based in functions other than equality, e.g. version equality. If this functions can be executed atomically, they provide a better solution for Hot Rod version-based replace operations that currently can cause some weird behaviour (ISPN-4972) > * When operations are defined as lambdas, it's easier to move towards a model that tracks/replicates operations leading to state, rather than replicating state itself. This makes it easier to implement more-efficiently replicated alternative data structures, such as counts, lists...etc, and paths the way towards CRDTs, particularly CmRDT (Commutative Replicated Data Types) or operation-based CRDTs. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5662) Change stream timeout values for remote operations to use replication timeout

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5662?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5662: ----------------------------------- Fix Version/s: 8.0.0.CR1 (was: 8.0.0.Beta3) > Change stream timeout values for remote operations to use replication timeout > ----------------------------------------------------------------------------- > > Key: ISPN-5662 > URL: https://issues.jboss.org/browse/ISPN-5662 > Project: Infinispan > Issue Type: Sub-task > Components: Core > Reporter: William Burns > Assignee: William Burns > Fix For: 8.0.0.CR1 > > > Currently the AbstractCacheStream and others have hard coded wait times for remote operation timeouts. We should instead change those to be the replication timeout values. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5646) Remove deprecated CacheEntryEvictedEvent

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5646?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5646: ----------------------------------- Fix Version/s: 8.0.0.CR1 (was: 8.0.0.Beta3) > Remove deprecated CacheEntryEvictedEvent > ---------------------------------------- > > Key: ISPN-5646 > URL: https://issues.jboss.org/browse/ISPN-5646 > Project: Infinispan > Issue Type: Bug > Components: Core > Reporter: William Burns > Assignee: William Burns > Fix For: 8.0.0.CR1 > > > CacheEntryEvictedEvent has been deprecated way back since ISPN 6. We should finally remove it. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5644) IsMarshallableInterceptor doesn't check serializability of LockControlCommand keys

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5644?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5644: ----------------------------------- Fix Version/s: 8.0.0.CR1 (was: 8.0.0.Beta3) > IsMarshallableInterceptor doesn't check serializability of LockControlCommand keys > ---------------------------------------------------------------------------------- > > Key: ISPN-5644 > URL: https://issues.jboss.org/browse/ISPN-5644 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.0.0.Beta2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.0.0.CR1 > > > {{IsMarshallableInterceptor}} checks the serializability of the collection, which tries to serialize it the first time, and then it skips the serialization regardless of what keys are in it. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5643) Simplify handling of previous values

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5643?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5643: ----------------------------------- Fix Version/s: 8.0.0.CR1 (was: 8.0.0.Beta3) > Simplify handling of previous values > ------------------------------------ > > Key: ISPN-5643 > URL: https://issues.jboss.org/browse/ISPN-5643 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 8.0.0.Beta2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.0.0.CR1 > > > There are 5 ways the user can influence whether the previous value is read from a store/remote node: > * unsafe.unreliableReturnValues > * IGNORE_RETURN_VALUES > * SKIP_CACHE_LOAD > * SKIP_REMOTE_LOOKUP > * CACHE_MODE_LOCAL > Currently the effect of each is slightly different, depending on whether the operation is conditional, whether it's a delta-aware write etc. This is how I think it should work: > * unsafe.unreliableReturnValues and IGNORE_RETURN_VALUES should skip reading the previous value only if it doesn't change the outcome of the operation (i.e. no effect for reads, conditional operations, or delta-aware). > * SKIP_CACHE_LOAD should *always* skip the cache loader. > * SKIP_REMOTE_LOOKUP and CACHE_MODE_LOCAL should *always* skip the remote lookup -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5632) Address rework comments for ISPN-5293

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5632?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5632: ----------------------------------- Fix Version/s: 8.0.0.CR1 (was: 8.0.0.Beta3) > Address rework comments for ISPN-5293 > ------------------------------------- > > Key: ISPN-5632 > URL: https://issues.jboss.org/browse/ISPN-5632 > Project: Infinispan > Issue Type: Sub-task > Components: Core > Reporter: William Burns > Assignee: William Burns > Fix For: 8.0.0.CR1 > > > There are some new rework comments for https://github.com/infinispan/infinispan/pull/3569. This issue will cover those. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 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 August 2015