[JBoss JIRA] (ISPN-4903) ServerFailureRetrySingleOwnerTest doesn't actually test client retry
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4903?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-4903:
-------------------------------
Fix Version/s: 8.2.0.CR1
(was: 8.2.0.Beta1)
> 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.2.0.CR1
>
> 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.4.11#64026)
8 years, 11 months
[JBoss JIRA] (ISPN-5012) ClusterRegistry as a service cache provider
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-5012?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-5012:
-------------------------------
Fix Version/s: 8.2.0.CR1
(was: 8.2.0.Beta1)
> 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.2.0.CR1
>
>
> 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.4.11#64026)
8 years, 11 months
[JBoss JIRA] (ISPN-5077) Custom remote events can be slightly inefficient
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-5077?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-5077:
-------------------------------
Fix Version/s: 8.2.0.CR1
(was: 8.2.0.Beta1)
> Custom remote events can be slightly inefficient
> ------------------------------------------------
>
> Key: ISPN-5077
> URL: https://issues.jboss.org/browse/ISPN-5077
> Project: Infinispan
> Issue Type: Enhancement
> Components: hot, Remote Protocols
> Affects Versions: 7.0.2.Final
> Reporter: Galder Zamarreño
> Fix For: 8.2.0.CR1
>
>
> Something we might want to improve for Hot Rod 3.0 protocol:
> [16:40] <galderz> i've been thinking further about converters, and I think i've found a slight mismatch between what converter means for embedded listeners vs remote listeners
> [16:40] <wburns> oh yeah?
> [16:40] <galderz> for embedded listeners, it essentially transforms what you see as `value`
> [16:41] <galderz> with the knowledge that key and metadata information will be shipped
> [16:41] <galderz> the way i mapped converter to remote listeners is that whatever the converter returns, we ship that, as is, to the client
> [16:41] <galderz> so, if a remote listener wants a custom event that includes key + value
> [16:41] <galderz> it needs to develop a converter impl that returns bytes containing key + value
> [16:41] <galderz> which is inefficient because you are passing around the key twice
> [16:42] <galderz> once as part of the event itself, and again inside the converted value
> [16:42] <galderz> inefficient from the POV of shipping stuff around from other nodes to where the cluster listener is located
> [16:44] <wburns> yeah makes sense
> [16:44] <galderz> not a major issue but not easy to fix without changing semantics or public protocol
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (ISPN-5073) Improve "Number of Entries" stats
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-5073?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-5073:
-------------------------------
Fix Version/s: 8.2.0.CR1
(was: 8.2.0.Beta1)
> 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.2.0.CR1
>
>
> 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.4.11#64026)
8 years, 11 months
[JBoss JIRA] (ISPN-5076) Pessimistic transactions can lose their locks when the primary owner changes
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-5076?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-5076:
-------------------------------
Fix Version/s: 8.2.0.CR1
(was: 8.2.0.Beta1)
> 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.2.0.CR1
>
>
> 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.4.11#64026)
8 years, 11 months