March 2016 - infinispan-issues - Jboss List Archives

[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: 9.0.0.Alpha1 (was: 8.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: 9.0.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.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5077) Custom remote events can be slightly inefficient

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5077?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5077: ------------------------------ Fix Version/s: 9.0.0.Alpha1 (was: 8.2.0.Final) > 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: 9.0.0.Alpha1 > > > 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)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5075) org.infinispan.IllegalLifecycleStateException in query tests

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5075?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5075: ------------------------------ Fix Version/s: 9.0.0.Alpha1 (was: 8.2.0.Final) > org.infinispan.IllegalLifecycleStateException in query tests > ------------------------------------------------------------ > > Key: ISPN-5075 > URL: https://issues.jboss.org/browse/ISPN-5075 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Query > Affects Versions: 7.1.0.Alpha1 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 9.0.0.Alpha1 > > > Many query tests log an error after running: > {code} > Exception in thread "Hibernate Search: async deletion of index segments-1" org.infinispan.IllegalLifecycleStateException: ISPN000323: Cache 'LuceneIndexesMetadata' is in 'TERMINATED' state and so it does not accept new invocations. Either restart it or recreate the cache container. > at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:89) > at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71) > at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:77) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:44) > at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333) > at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:422) > at org.infinispan.cache.impl.DecoratedCache.get(DecoratedCache.java:427) > at org.infinispan.lucene.impl.FileListOperations.getFileList(FileListOperations.java:160) > at org.infinispan.lucene.impl.FileListOperations.deleteFileName(FileListOperations.java:129) > at org.infinispan.lucene.impl.DirectoryImplementor.deleteFile(DirectoryImplementor.java:64) > at org.infinispan.lucene.impl.DirectoryLuceneV4$DeleteTask.run(DirectoryLuceneV4.java:195) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > {code} > That error does not cause the tests to fail, and are due to the async deletes of segments recently implemented. Need to check if the executors are being flushed correctly when the cache manager stops -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

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: 9.0.0.Alpha1 (was: 8.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: 9.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

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: 9.0.0.Alpha1 (was: 8.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: 9.0.0.Alpha1 > > > 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)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5058) Document example configurations using a CacheStore to persist the Lucene index

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5058?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5058: ------------------------------ Fix Version/s: 9.0.0.Alpha1 (was: 8.2.0.Final) > Document example configurations using a CacheStore to persist the Lucene index > ------------------------------------------------------------------------------ > > Key: ISPN-5058 > URL: https://issues.jboss.org/browse/ISPN-5058 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation-Query > Reporter: Sanne Grinovero > Assignee: Gustavo Fernandes > Fix For: 9.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5211) NPE on NumericVersionGenerator.start() when JGroups configuration resource not found

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5211?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5211: ------------------------------ Fix Version/s: 9.0.0.Alpha1 (was: 8.2.0.Final) > NPE on NumericVersionGenerator.start() when JGroups configuration resource not found > ------------------------------------------------------------------------------------ > > Key: ISPN-5211 > URL: https://issues.jboss.org/browse/ISPN-5211 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.1.0.Final > Reporter: Sanne Grinovero > Fix For: 9.0.0.Alpha1 > > > This is easy to reproduce: start a {{CacheManager}} which has a {{Transport}} configured with a non-existent resource name for the JGroups configuration. > Would be great to have a better error message. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5210) Support writing multiple modifications to cache stores in batch when using Transactions

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5210?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5210: ------------------------------ Fix Version/s: 9.0.0.Alpha1 (was: 8.2.0.Final) > Support writing multiple modifications to cache stores in batch when using Transactions > --------------------------------------------------------------------------------------- > > Key: ISPN-5210 > URL: https://issues.jboss.org/browse/ISPN-5210 > Project: Infinispan > Issue Type: Feature Request > Components: Loaders and Stores > Affects Versions: 6.0.2.Final, 7.1.0.Final > Reporter: Richard Lucas > Fix For: 9.0.0.Alpha1 > > > Currently writes to a cache store are performed individually for each modification to the cache. > While this makes sense when using a non-tx cache it would be beneficial to support writing multiple modifications to a cache store in a single call when using a Tx cache. > Currently all writes are performed in the commit phase and are done by looping through the modifications in the Tx and writing each one in turn to the the store. > Instead of doing this it would useful to pass all modifications to the store in a single call, this would allow: > a) Taking advantage of support for batch updates in underlying stores (JDBC, MongoDB, DynamoDB) for a more efficient write through. > b) Allow store implementations the chance to clean up if one or more updates in the batch fail (this is especially useful if the store does not support Tx and rollbacks as it means the store implementation can at least try to clean up any partial updates it has performed, something which is not currently possible). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5218) Add batching to the AdvancedCacheWriter interface

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5218?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5218: ------------------------------ Fix Version/s: 9.0.0.Alpha1 (was: 8.2.0.Final) > Add batching to the AdvancedCacheWriter interface > ------------------------------------------------- > > Key: ISPN-5218 > URL: https://issues.jboss.org/browse/ISPN-5218 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Reporter: Tristan Tarrant > Fix For: 9.0.0.Alpha1 > > > The AdvancedCacheWriter should be extended with a write operation which takes multiple entries so that stores which can do batching can optimize this. This would benefit both passivation and the async writer. > Immediate users would be the JDBC stores. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5163) A write operation with the SKIP_LOCKING flag can roll back the transaction

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5163?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5163: ------------------------------ Fix Version/s: 9.0.0.Alpha1 (was: 8.2.0.Final) > A write operation with the SKIP_LOCKING flag can roll back the transaction > -------------------------------------------------------------------------- > > Key: ISPN-5163 > URL: https://issues.jboss.org/browse/ISPN-5163 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.3.Final, 7.1.0.Beta1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.0.0.Alpha1 > > > When a write operation has the SKIP_LOCKING flag, it does not send a {{LockControlCommand}} to the primary owner, but it can send a {{ClusteredGetCommand}} with {{acquireRemoteLocks=true}} instead. The {{ClusteredGetCommmand}} will then execute a {{LockControlCommand}} with the origin not set properly, and {{TxInterceptor}} will roll back the transaction because the originator ({{null}}) appears to have left the cluster. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2016