January 2015 - infinispan-issues - Jboss List Archives

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

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4923?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4923: -------------------------------- Fix Version/s: 7.2.0.Alpha1 (was: 7.1.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: 7.2.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 10 months

1
0
0 / 0

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

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4903?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4903: -------------------------------- Fix Version/s: 7.2.0.Alpha1 (was: 7.1.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: 7.2.0.Alpha1 > > 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.11#6341)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4899) Update user guide regarding protobuf schema definition API

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4899?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4899: -------------------------------- Fix Version/s: 7.2.0.Alpha1 (was: 7.1.0.Final) > Update user guide regarding protobuf schema definition API > ---------------------------------------------------------- > > Key: ISPN-4899 > URL: https://issues.jboss.org/browse/ISPN-4899 > Project: Infinispan > Issue Type: Task > Components: Documentation-Query > Affects Versions: 7.0.0.CR2 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.2.0.Alpha1 > > > Describe the usage of __protobuf_metadata cache -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5022) Create a cachestore archetype

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5022?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5022: -------------------------------- Fix Version/s: 7.2.0.Alpha1 (was: 7.1.0.Final) > Create a cachestore archetype > ----------------------------- > > Key: ISPN-5022 > URL: https://issues.jboss.org/browse/ISPN-5022 > Project: Infinispan > Issue Type: Feature Request > Components: Demos and Tutorials, Loaders and Stores > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.2.0.Alpha1 > > > We should have an AdvancedCacheWriter archetype which describes how to implement a proper cache store. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 10 months

1
0
0 / 0

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

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5021?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5021: -------------------------------- Fix Version/s: 7.2.0.Alpha1 (was: 7.1.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: 7.2.0.Alpha1 > > > 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.11#6341)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5019) After coordinator change, cache topologies should be installed in parallel

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5019?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5019: -------------------------------- Fix Version/s: 7.2.0.Alpha1 (was: 7.1.0.Final) > After coordinator change, cache topologies should be installed in parallel > -------------------------------------------------------------------------- > > Key: ISPN-5019 > URL: https://issues.jboss.org/browse/ISPN-5019 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.2.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.2.0.Alpha1 > > > When the coordinator crashes, the new coordinator has to recover the cache topologies from all the nodes in the cluster and install updated topologies for all the caches. This is done on a single thread, and it can take a long time when there are a lot of caches. > We should be accelerate this by doing the topology installation on separate threads. However, we have to be careful with the async transport pool, because {{executeOnClusterAsync}} actually needs to spawn a new thread in the same pool. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5013) Server-side scripting using JSR-223 (javax.script)

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5013?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5013: -------------------------------- Fix Version/s: 7.2.0.Alpha1 (was: 7.1.0.Final) > Server-side scripting using JSR-223 (javax.script) > -------------------------------------------------- > > Key: ISPN-5013 > URL: https://issues.jboss.org/browse/ISPN-5013 > Project: Infinispan > Issue Type: Feature Request > Components: Core, Server > Affects Versions: 7.0.2.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.2.0.Alpha1 > > > Implement a scripting manager which stores custom scripts in a dedicated cache. These scripts will be invoked with a user-specified binding (i.e. a set of named parameters). > This component should support all known "code" extension points: simple, tasks, distexec, map/reduce, listeners, etc. > The script type should be supported by the available JSR-223 scripting engines -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 10 months

1
0
0 / 0

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

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5012?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5012: -------------------------------- Fix Version/s: 7.2.0.Alpha1 (was: 7.1.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: 7.2.0.Alpha1 > > > 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.11#6341)

10 years, 10 months

1
0
0 / 0

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

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5083?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5083: -------------------------------- Fix Version/s: 7.2.0.Alpha1 (was: 7.1.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: 7.2.0.Alpha1 > > > 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.11#6341)

10 years, 10 months

1
0
0 / 0

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

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5076?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5076: -------------------------------- Fix Version/s: 7.2.0.Alpha1 (was: 7.1.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: 7.2.0.Alpha1 > > > 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.11#6341)

10 years, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2015