August 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4722) CLI remove is not cluster-wide

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4722?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4722: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > CLI remove is not cluster-wide > ------------------------------ > > Key: ISPN-4722 > URL: https://issues.jboss.org/browse/ISPN-4722 > Project: Infinispan > Issue Type: Bug > Components: CLI > Affects Versions: 6.0.2.Final, 7.0.0.Beta1 > Reporter: Galder Zamarreño > Assignee: Tristan Tarrant > Fix For: 8.1.0.Final > > > In CLI, the "remove" command does not delete entries in all nodes of a clustered environment, only the local copy. However, the "put" command does write in all nodes. Is it the expected behavior? See example below: > {code} > node 1 > put k1 v1 > get k1 -> v1 > node 2 > get k1 -> v1 > node 1 > remove k1 > get k1 -> null > node 2 > get k1 -> v1 > {code} > I know that these commands provided by CLI are not used in real world, but they are useful to demonstrate the correct configuration of a JDG cluster. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4584) Stricter validation of cache configurations for distributed indexes

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4584?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4584: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > Stricter validation of cache configurations for distributed indexes > ------------------------------------------------------------------- > > Key: ISPN-4584 > URL: https://issues.jboss.org/browse/ISPN-4584 > Project: Infinispan > Issue Type: Enhancement > Components: Lucene Directory > Reporter: Sanne Grinovero > Assignee: Gustavo Fernandes > Fix For: 8.1.0.Final > > > See also ISPN-4577 : it should not be allowed to configure a distributed metadata cache while the chunks cache is using local mode. > Ideally think of additional strict checks which we should apply.. suggestions? > Mitigated by ISPN-4340 -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 7 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.1.0.Final (was: 8.0.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.1.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)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4912) Switch REST store to better HTTP client library

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4912?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4912: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > Switch REST store to better HTTP client library > ----------------------------------------------- > > Key: ISPN-4912 > URL: https://issues.jboss.org/browse/ISPN-4912 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 8.1.0.Final > > > As a result of https://github.com/infinispan/infinispan/pull/3004, either OkHttp or Netty should do the trick. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 7 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.1.0.Final (was: 8.0.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.1.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 7 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.1.0.Final (was: 8.0.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.1.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)

8 years, 7 months

1
0
0 / 0

[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.1.0.Final (was: 8.0.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.1.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4952) Add back in calls to NDC to push the cache name

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4952?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4952: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > Add back in calls to NDC to push the cache name > ----------------------------------------------- > > Key: ISPN-4952 > URL: https://issues.jboss.org/browse/ISPN-4952 > Project: Infinispan > Issue Type: Enhancement > Reporter: William Burns > Fix For: 8.1.0.Final > > > JBLOGGING-106 has been resolved in 3.2.0.Beta2. After we upgrade to a version that has this fix we need to uncomment the lines in the LogFactory. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4903) ServerFailureRetrySingleOwnerTest doesn't actually test client retry

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4903?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4903: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > ServerFailureRetrySingleOwnerTest doesn't actually test client retry > -------------------------------------------------------------------- > > Key: ISPN-4903 > URL: https://issues.jboss.org/browse/ISPN-4903 > Project: Infinispan > Issue Type: Bug > Components: Server, Test Suite - Server > Affects Versions: 7.0.0.CR2 > Reporter: Dan Berindei > Fix For: 8.1.0.Final > > Attachments: ServerFailureRetrySingleOwnerTest.java > > > With {{useSynchronization = true}} (the default, before ISPN-4166 is integrated), the {{SuspectException}} thrown by the listener is swallowed by the transaction manager and the client doesn't retry. The test doesn't pick that up because the exception is thrown _after_ the entry was updated in the data container (a regular SuspectException would be thrown before). > I changed the configuration to {{useSynchronization = false}}, but it didn't work because the {{SuspectException}} is wrapped in a {{CacheListenerException}}, so the client throws an exception instead of retrying. I also changed the test to use an interceptor instead of a listener, but then I got a {{ClassCastException}}: > {noformat} > Caused by: java.lang.ClassCastException: [B cannot be cast to org.infinispan.container.entries.CacheEntry > at org.infinispan.cache.impl.CacheImpl.getCacheEntry(CacheImpl.java:424) > at org.infinispan.cache.impl.CacheImpl.getCacheEntry(CacheImpl.java:429) > at org.infinispan.server.hotrod.Decoder2x$.customReadKey(Decoder2x.scala:285) > at org.infinispan.server.hotrod.HotRodDecoder.customDecodeKey(HotRodDecoder.scala:156) > at org.infinispan.server.core.AbstractProtocolDecoder.org$infinispan$server$core$AbstractProtocolDecoder$$decodeKey(AbstractProtocolDecoder.scala:176) > at org.infinispan.server.core.AbstractProtocolDecoder.decodeDispatch(AbstractProtocolDecoder.scala:71) ... 14 more > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5009) Upgrade server base to WildFly 9.0.0.Beta2

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5009?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5009: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > Upgrade server base to WildFly 9.0.0.Beta2 > ------------------------------------------ > > Key: ISPN-5009 > URL: https://issues.jboss.org/browse/ISPN-5009 > Project: Infinispan > Issue Type: Component Upgrade > Components: Build process, Server > Affects Versions: 7.0.2.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 8.1.0.Final > > > Originally it was meant to upgrade to Wildfly 8.2.0.Final but some issues where found. Upgrade still needed but upgrading to 9.0.0.Beta2 which solves issues. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 7 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