[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
&…
[View More]gt; 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)
[View Less]
9 years, 7 months
[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
…
[View More]> 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)
[View Less]
9 years, 7 months
[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 …
[View More]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)
[View Less]
9 years, 7 months
[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
> …
[View More]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)
[View Less]
9 years, 7 months