August 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5699) Simplify entry wrapping

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5699?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5699: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > Simplify entry wrapping > ----------------------- > > Key: ISPN-5699 > URL: https://issues.jboss.org/browse/ISPN-5699 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 8.0.0.CR1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.1.0.Final > > > The entry wrapping should be more or less the same for all write commands. > Currently we have some optimizations to skip wrapping in some cases, in the first phase we should probably keep them: > * Non-repeatable reads don't store anything in the context if the value is null > * Replace and remove store a null entry in the context > * PutForExternalRead doesn't store anything in the context if the value is non-null -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5691) Server should enable writeSkew for some configurations by default

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5691?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5691: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > Server should enable writeSkew for some configurations by default > ----------------------------------------------------------------- > > Key: ISPN-5691 > URL: https://issues.jboss.org/browse/ISPN-5691 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Reporter: Galder Zamarreño > Assignee: Tristan Tarrant > Fix For: 8.1.0.Final, 7.2.5.Final > > > By default, optimistic locking caches do not enable write skew. This was already spotted in ISPN-3655. > In an embedded environment, the user can always enable write skew in its configuration, but this cannot be enabled in server mode. > Widlfly does enable write skew programmatically depending on the configuration: > {quote} > > hey, quick q: can you configure writeSkew on infinispan wildfly > config? > <pferraro> we always enable write skew for synchronous, optimistic, > repeatable-read caches, and disable otherwise > > pferraro: ah, you do it in the integration code? > <pferraro> yes > {quote} > We need to be doing the same in server configuration, otherwise we run the risk of having issues with conditional operations under failure situations (see ISPN-2956) -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5671) Implement missing RemoteCache read operations using near cache

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5671?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5671: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > Implement missing RemoteCache read operations using near cache > -------------------------------------------------------------- > > Key: ISPN-5671 > URL: https://issues.jboss.org/browse/ISPN-5671 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Protocols > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 8.1.0.Final > > > For example: getAll, getWithMetadata, containsKey, getBulk, getAsync, values, retrieveEntries, and entrySet. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5665) Query should not rely on the results of return values of write commands

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5665?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5665: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > Query should not rely on the results of return values of write commands > ----------------------------------------------------------------------- > > Key: ISPN-5665 > URL: https://issues.jboss.org/browse/ISPN-5665 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 8.0.0.Beta2 > Reporter: Dan Berindei > Assignee: Gustavo Fernandes > Fix For: 8.1.0.Final > > > The query interceptor relies on the return value of the write commands to know the previous value of the modified entries. This is not correct, because some write commands do not return the previous value, e.g. {{remove(key, value)}}, {{replace(key, oldValue, newValue)}}, and {{putAll(map)}}. > The query interceptor should instead look up the previous values in the invocation context, and also force the loading of old values in the invocation context if the command doesn't do it explicitly (e.g. {{putAll(map)}}, or {{put(k, v)}} with the {{IGNORE_RETURN_VALUES}} flag). -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5657) Add missing embedded configuration elements to server schema

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5657?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5657: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > Add missing embedded configuration elements to server schema > ------------------------------------------------------------ > > Key: ISPN-5657 > URL: https://issues.jboss.org/browse/ISPN-5657 > Project: Infinispan > Issue Type: Bug > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 8.1.0.Final > > > The embedded and server schema, while mostly compatible with each other, still differ in a number of aspects, e.g. store-as-binary, unsafe, etc. > The server should be able to parse these additional elements. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5654) Make DeadlockDetectingLockManager aware of single-node locking

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5654?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5654: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > Make DeadlockDetectingLockManager aware of single-node locking > -------------------------------------------------------------- > > Key: ISPN-5654 > URL: https://issues.jboss.org/browse/ISPN-5654 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 8.0.0.Beta2 > Reporter: Dan Berindei > Fix For: 8.1.0.Final > > > {{DeadlockDetectingLockManager}} seems to assume that the node that started a transaction acquires a local lock before replicating, which is wrong since we switched to locking only on the primary owner. > In particular, {{isSameKeyDeadlock}} can probably be removed altogether. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 10 months

1
0
0 / 0

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

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5643?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5643: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > 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.Final > > > 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)

8 years, 10 months

1
0
0 / 0

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

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5644?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5644: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > 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.Final > > > {{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)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5714) Add value/metadata aware store expiration listener

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5714?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5714: -------------------------------- Description: Expiration listener for stores currently only provide the key in a calback. It would be preferred if a store is able to also tell us the value and/or metadata so we can properly expire this entry across the cluster. The current implementation can expire incorrect values due to the fact that we only expired based on key, this will be remedied with this addition for stores that support it. (was: Expiration listener for stores currently only provide the key in a calback. It would be preferred if a store is able to also tell us the value and/or metadata so we can properly expire this entry across the cluster. The current implementation can expire incorrect values due to the fact that ) > Add value/metadata aware store expiration listener > -------------------------------------------------- > > Key: ISPN-5714 > URL: https://issues.jboss.org/browse/ISPN-5714 > Project: Infinispan > Issue Type: Sub-task > Components: Expiration > Reporter: William Burns > Assignee: William Burns > Fix For: 8.0.0.Final > > > Expiration listener for stores currently only provide the key in a calback. It would be preferred if a store is able to also tell us the value and/or metadata so we can properly expire this entry across the cluster. The current implementation can expire incorrect values due to the fact that we only expired based on key, this will be remedied with this addition for stores that support it. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5714) Add value/metadata aware store expiration listener

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5714?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5714: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Add value/metadata aware store expiration listener > -------------------------------------------------- > > Key: ISPN-5714 > URL: https://issues.jboss.org/browse/ISPN-5714 > Project: Infinispan > Issue Type: Sub-task > Components: Expiration > Reporter: William Burns > Assignee: William Burns > Fix For: 8.0.0.Final > > > Expiration listener for stores currently only provide the key in a calback. It would be preferred if a store is able to also tell us the value and/or metadata so we can properly expire this entry across the cluster. The current implementation can expire incorrect values due to the fact that -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues August 2015