May 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4927) Bulk Ops in HotRod should use new implementations of keySet and entrySet

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4927?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4927: ------------------------------ Fix Version/s: 8.0.0.Final (was: 7.2.0.Final) > Bulk Ops in HotRod should use new implementations of keySet and entrySet > ------------------------------------------------------------------------ > > Key: ISPN-4927 > URL: https://issues.jboss.org/browse/ISPN-4927 > Project: Infinispan > Issue Type: Enhancement > Affects Versions: 7.0.0.CR2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 8.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4923) Server should allow toggling statistics at runtime

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4923?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4923: ------------------------------ Fix Version/s: 8.0.0.Final (was: 7.2.0.Final) > Server should allow toggling statistics at runtime > -------------------------------------------------- > > Key: ISPN-4923 > URL: https://issues.jboss.org/browse/ISPN-4923 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Affects Versions: 7.0.0.CR2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 8.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5046) PartitionHandling: split during commit can leave the cache inconsistent after merge

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5046?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5046: ------------------------------ Fix Version/s: 8.0.0.Final (was: 7.2.0.Final) > PartitionHandling: split during commit can leave the cache inconsistent after merge > ----------------------------------------------------------------------------------- > > Key: ISPN-5046 > URL: https://issues.jboss.org/browse/ISPN-5046 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 7.0.2.Final, 7.1.0.Alpha1 > Reporter: Dan Berindei > Assignee: Pedro Ruivo > Priority: Critical > Fix For: 8.0.0.Final > > > Say we have a cluster ABCD; a transaction T was started on A, with B as the primary owner and C the backup owner. B and C both acknowledge the prepare, and the network splits into AB and CD right before A sends the commit command. Eventually A suspects C and D, but the commit still succeeds on B before C and D are suspected. And SuspectExceptions are ignored for commit commands, so the user won't see any error. > However, C will eventually suspect A and B. When the CD cache topology is installed, it will roll back transaction T. After the merge, both partitions are in degraded mode, so we assume that they both have the latest data and the key is never updated on C. > From C's point of view, this is very similar to ISPN-3421. The fix should also be similar, we could delay the transaction rollback on C until we get a confirmation from B that T was not committed there. Since B is inaccessible, it will eventually get a SuspectException and the CD cache topology, at which point the cache is in degraded mode and it can wait for a merge. On merge, it should check the status of the transaction on B again, and either commit or rollback based on what B did. > We also need to suspend the cleanup of completed transactions while the cache is in degraded mode, otherwise C might not find T on B after the merge. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5042) Remote gets caused by writes could be replicated only to the primary owner

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5042?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5042: ------------------------------ Fix Version/s: 8.0.0.Final (was: 7.2.0.Final) > Remote gets caused by writes could be replicated only to the primary owner > -------------------------------------------------------------------------- > > Key: ISPN-5042 > URL: https://issues.jboss.org/browse/ISPN-5042 > Project: Infinispan > Issue Type: Enhancement > Components: Core, State Transfer > Affects Versions: 7.1.0.Alpha1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Minor > Labels: 7.0 > Fix For: 8.0.0.Final > > > For write operations that need the previous value, a write CH-only owner that doesn't have a key locally will attempt to retrieve the key from the read CH-owners. > Sending the remote get command to all the previous owners will create extra load on the cluster during state transfer, so it should be more efficient to send the remote get only to the primary owner. Even though the latency of some write operations will be higher, the average latency should be better. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5021) Nodes that finish the rebalance later can see outdated values

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5021?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5021: ------------------------------ Fix Version/s: 8.0.0.Final (was: 7.2.0.Final) > Nodes that finish the rebalance later can see outdated values > ------------------------------------------------------------- > > Key: ISPN-5021 > URL: https://issues.jboss.org/browse/ISPN-5021 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 7.0.2.Final > Reporter: Dan Berindei > Assignee: Pedro Ruivo > Priority: Critical > Fix For: 8.0.0.Final > > > Copied from [ISPN-4444|https://issues.jboss.org/browse/ISPN-4444?focusedCommentId=1302...] > If the CH_UPDATE command is delayed on the old owner, the new owners might update the key without the old owner knowing, and a locality check on the old owner won't help. > I remember one thing that struck me when reading the Raft algorithm was that they install configuration changes symmetrically, in 3 phases. We might need to do the same for our rebalance: start a rebalance with read_ch=old, write_ch=old+new, when the new owners have all the data install read_ch=new, write_ch=old+new, and finally read_ch=new, write_ch=new. Old cache entries are removed during the 2nd topology update, and further writes should be ignored, in order for this to work. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5012) ClusterRegistry as a service cache provider

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5012?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5012: ------------------------------ Fix Version/s: 8.0.0.Final (was: 7.2.0.Final) > ClusterRegistry as a service cache provider > ------------------------------------------- > > Key: ISPN-5012 > URL: https://issues.jboss.org/browse/ISPN-5012 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 8.0.0.Final > > > The ClusterRegistry is currently a volatile, replicated cache with a composite key and it does not serve the original purpose for which it was built. It should be refactored to be a service cache factory with a builder API based on desired features and a NamingStrategy so that we can have "well-known" caches as well as temporary caches. It should also be possible to use the cache dependency mechanism to "chain" service cache lifecycles to other caches. > Here's an example API (not a real example): > RegistryBuilder builder = registry.getBuilder(); > builder.persistent().clustered().dependsOn(Cache<?,?> cache).namingStrategy(new StaticCacheNamingStrategy("___protobuf_metadata")) > This registry would be able to provide caches to the following use cases: > - protobuf schemas > - hotrod topology > - security acl > - map/reduce work caches > - index caches > - etc. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5076) Pessimistic transactions can lose their locks when the primary owner changes

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5076?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5076: ------------------------------ Fix Version/s: 8.0.0.Final (was: 7.2.0.Final) > Pessimistic transactions can lose their locks when the primary owner changes > ---------------------------------------------------------------------------- > > Key: ISPN-5076 > URL: https://issues.jboss.org/browse/ISPN-5076 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 7.0.2.Final, 7.1.0.Alpha1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Labels: 7.0 > Fix For: 8.0.0.Final > > > In a pessimistic cache, if a transaction {{T1}} has a {{put(k, v)}} operation and the primary owner of the key is the originator, the lock is acquired on the originator but it is not replicated to on the backup(s). > If one of the backup owners becomes the primary owner, it will allow another transaction {{T2}} to lock (and update) key {{k}} before it receives the one-phase prepare command from the originator of {{T1}}. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5073) Improve "Number of Entries" stats

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5073?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5073: ------------------------------ Fix Version/s: 8.0.0.Final (was: 7.2.0.Final) > Improve "Number of Entries" stats > --------------------------------- > > Key: ISPN-5073 > URL: https://issues.jboss.org/browse/ISPN-5073 > Project: Infinispan > Issue Type: Task > Components: Core, JMX, reporting and management > Affects Versions: 7.1.0.Alpha1 > Reporter: Tristan Tarrant > Assignee: Vladimir Blagojevic > Fix For: 8.0.0.Final > > > Currently the getNumberOfEntries in CacheMgmtInterceptor returns the size of the datacontainer which doesn't take into account expired entries and cache stores. > To avoid compatibility issues, modify the description to reflect its behaviour and add proper statistics, possibly with different flag combinations (SKIP_REMOTE, SKIP_CACHE_LOAD) -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5067) CLI for server docs need updating to reflect WildFly base

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5067?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5067: ------------------------------ Fix Version/s: 8.0.0.Final (was: 7.2.0.Final) > CLI for server docs need updating to reflect WildFly base > --------------------------------------------------------- > > Key: ISPN-5067 > URL: https://issues.jboss.org/browse/ISPN-5067 > Project: Infinispan > Issue Type: Bug > Components: Documentation-Servers > Affects Versions: 7.1.0.Alpha1 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 8.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5083) Hot Rod decoder should use async Cache operations

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5083?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5083: ------------------------------ Fix Version/s: 8.0.0.Final (was: 7.2.0.Final) > Hot Rod decoder should use async Cache operations > ------------------------------------------------- > > Key: ISPN-5083 > URL: https://issues.jboss.org/browse/ISPN-5083 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Protocols > Reporter: Galder Zamarreño > Assignee: Gustavo Fernandes > Fix For: 8.0.0.Final > > > Hot Rod decoder is currently tying up Netty threads as a result of calling up to Infinispan sync operations. Instead, Hot Rod decoder should call up async operations, convert the Notifying Futures to Scala Futures, and write up the reply when it's received. This should increase performance specially under heavy load. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2015