January 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2041) Provide putAll(map) and getAll(map) bulk operation on Cache and RemoteCache

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-2041?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-2041: ---------------------------------- Fix Version/s: 7.2.0.Final (was: 7.1.0.Final) > Provide putAll(map) and getAll(map) bulk operation on Cache and RemoteCache > --------------------------------------------------------------------------- > > Key: ISPN-2041 > URL: https://issues.jboss.org/browse/ISPN-2041 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 5.1.4.FINAL > Reporter: susanin > Assignee: Galder Zamarreño > Priority: Minor > Fix For: 7.2.0.Final > > > Currently Infinispan implements putAll(map) by means of looping over all entries and submitting them by means of put() one-by-one. > This is very slow if you have a lot of synchronous updates to apply. > It would be much more efficient, if a special bulk operation would be supported, so that all entries are sent to their respective replica nodes in one go. It would reduce the number of network roundtrips and related overhead and it would also make use of parallel execution, because some of the puts can be executed in parallel as they land on different nodes. > Note: Hazelcast has this optimization. It often improves performance of bulk puts by at least a factor of 2 or 3, even if it is used between a client and Hazelcast server, i.e. a bulk operation is sent to a single grid node from a client and no parallelism can be used. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2041) Provide putAll(map) and getAll(map) bulk operation on Cache and RemoteCache

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-2041?page=com.atlassian.jira.plugin.... ] Tristan Tarrant commented on ISPN-2041: --------------------------------------- The getAll operation should be implemented using a remote iterator > Provide putAll(map) and getAll(map) bulk operation on Cache and RemoteCache > --------------------------------------------------------------------------- > > Key: ISPN-2041 > URL: https://issues.jboss.org/browse/ISPN-2041 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 5.1.4.FINAL > Reporter: susanin > Assignee: Galder Zamarreño > Priority: Minor > Fix For: 7.1.0.Final > > > Currently Infinispan implements putAll(map) by means of looping over all entries and submitting them by means of put() one-by-one. > This is very slow if you have a lot of synchronous updates to apply. > It would be much more efficient, if a special bulk operation would be supported, so that all entries are sent to their respective replica nodes in one go. It would reduce the number of network roundtrips and related overhead and it would also make use of parallel execution, because some of the puts can be executed in parallel as they land on different nodes. > Note: Hazelcast has this optimization. It often improves performance of bulk puts by at least a factor of 2 or 3, even if it is used between a client and Hazelcast server, i.e. a bulk operation is sent to a single grid node from a client and no parallelism can be used. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5130) Conditional operation warning should only appear for clustered caches

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5130?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5130: ----------------------------------- Fix Version/s: 7.0.4.Final > Conditional operation warning should only appear for clustered caches > --------------------------------------------------------------------- > > Key: ISPN-5130 > URL: https://issues.jboss.org/browse/ISPN-5130 > Project: Infinispan > Issue Type: Bug > Affects Versions: 7.1.0.Alpha1, 7.0.3.Final > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.1.0.Beta1, 7.1.0.Final, 7.0.4.Final > > > Even for local caches, the following warning is shown when using conditional operations: > {code} > 08:38:08,920 WARN [org.infinispan.server.hotrod.Decoder2x$] (HotRodServerWorker-6-8) ISPN006010: > Conditional operation 'ReplaceIfUnmodifiedRequest' should be used with transactional caches, otherwise data inconsistency issues could arise under failure situations > {code} > This warning should only appear in clustered situations where the real danger is present (see ISPN-2956) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5103) Inefficient index updates cause high cost merges and increase overall latency

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-5103?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-5103: ------------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3196 PR with a failing test after enabling 'isIndexMetadataComplete' > Inefficient index updates cause high cost merges and increase overall latency > ----------------------------------------------------------------------------- > > Key: ISPN-5103 > URL: https://issues.jboss.org/browse/ISPN-5103 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying > Affects Versions: 7.0.2.Final, 7.1.0.Alpha1 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > > Currently every change to the index is done Lucene-wise combining two operations: > * Delete by query, using a boolean query on the id plus the entity class > * Add > > Under high load, specially during merges those numerous deletes provoke very long delays causing high latency. > We should instead use a simple Lucene Update to add/change documents, since internally it translates to a Delete by term plus an Add operation, and delete by terms are extremely efficient in Lucene. > Some local tests showed average latency of updating the index using this strategy to drop 4 times, both for the SYNC and ASYNC backends > With relation to sharing the index between entities, which was the original motivation of the Delete by query plus add strategy, we have two scenarios: > * Same cache with multiple entity types: that's a non-issue, since obviously there's no id collision in this case > * Different caches with the same index: this scenario happens when different caches shares the same index, for ex: > {code} > @Indexed(indexName=common) > public class Country { ... } > @Indexed(indexName=common) > public class Currency { ... } > cm.getCache("currencies").put(1, new Currency(...)) > cm.getCache("countries").put(1, new Country(...)) > {code} > This would require a delete by query in order to persist both a Country and a Currency with id=1. > It would also require setting "default.exclusive_index_use", "false", with the associated cost of having to reopen the IndexWriter on every operation. > Given the performance gain of doing a simple Update is considerable, we should make the corner case supported by extra configuration or alternatively, generate a unique @ProvidedId, including the entity class or the cache name that work for all cases described above. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5103) Inefficient index updates cause high cost merges and increase overall latency

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-5103?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-5103: ------------------------------------ Status: Open (was: New) > Inefficient index updates cause high cost merges and increase overall latency > ----------------------------------------------------------------------------- > > Key: ISPN-5103 > URL: https://issues.jboss.org/browse/ISPN-5103 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying > Affects Versions: 7.0.2.Final, 7.1.0.Alpha1 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > > Currently every change to the index is done Lucene-wise combining two operations: > * Delete by query, using a boolean query on the id plus the entity class > * Add > > Under high load, specially during merges those numerous deletes provoke very long delays causing high latency. > We should instead use a simple Lucene Update to add/change documents, since internally it translates to a Delete by term plus an Add operation, and delete by terms are extremely efficient in Lucene. > Some local tests showed average latency of updating the index using this strategy to drop 4 times, both for the SYNC and ASYNC backends > With relation to sharing the index between entities, which was the original motivation of the Delete by query plus add strategy, we have two scenarios: > * Same cache with multiple entity types: that's a non-issue, since obviously there's no id collision in this case > * Different caches with the same index: this scenario happens when different caches shares the same index, for ex: > {code} > @Indexed(indexName=common) > public class Country { ... } > @Indexed(indexName=common) > public class Currency { ... } > cm.getCache("currencies").put(1, new Currency(...)) > cm.getCache("countries").put(1, new Country(...)) > {code} > This would require a delete by query in order to persist both a Country and a Currency with id=1. > It would also require setting "default.exclusive_index_use", "false", with the associated cost of having to reopen the IndexWriter on every operation. > Given the performance gain of doing a simple Update is considerable, we should make the corner case supported by extra configuration or alternatively, generate a unique @ProvidedId, including the entity class or the cache name that work for all cases described above. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5125) EventType methods are not public

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5125?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5125: ---------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.1.0.Final Resolution: Done > EventType methods are not public > -------------------------------- > > Key: ISPN-5125 > URL: https://issues.jboss.org/browse/ISPN-5125 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.3.Final > Reporter: William Burns > Assignee: William Burns > Fix For: 7.1.0.Beta1, 7.1.0.Final > > > The org.infinispan.notifications.cachelistener.filter.EventType has some methods that are not marked as public (isRetry, isPreEvent, isRemove, isCreate, isModified). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1342) Support for Near-Cache Pattern

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-1342?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-1342: ---------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.1.0.Beta1 Resolution: Done > Support for Near-Cache Pattern > ------------------------------ > > Key: ISPN-1342 > URL: https://issues.jboss.org/browse/ISPN-1342 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 5.0.0.FINAL > Reporter: Peter Novak > Assignee: Galder Zamarreño > Fix For: 7.1.0.Beta1, 7.1.0.Final > > > Please create some support for near-cache pattern for distributed cache. Some detailed description could be found in Oracle Coherence documentation http://download.oracle.com/docs/cd/E13924_01/coh.340/e13819/nearcache.htm or in Cameron Purdy presentation http://frech.info/themen/CameronPurdy-DistributedCachingEssentialLessons.pdf > It is based on combination of L1 caching in local JVM of application with combination of L2 cache based on distributed cache cluster on other servers. I tried to implement this myself, but HotRod does not support Client-side listeners (The UnsupportedOperationException is thrown). It could be cool, if I could register some kind of eviction listener on client side and use it for invalidation of records in local cache based on event from remote distributed cache (L2). > Some kind of workaround was described in http://community.jboss.org/thread/166993 : "We don't have L1s yet, but you could implement Cache Listeners on the server side and use JMS to notify your clients and build an L1 that way." > Thanks for so great cache like infinispan is. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5132) Create a Docker Image

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5132?page=com.atlassian.jira.plugin.... ] Tristan Tarrant resolved ISPN-5132. ----------------------------------- Resolution: Done > Create a Docker Image > --------------------- > > Key: ISPN-5132 > URL: https://issues.jboss.org/browse/ISPN-5132 > Project: Infinispan > Issue Type: Feature Request > Components: Docker > Reporter: Tristan Tarrant > Assignee: Vojtech Juranek > Fix For: 7.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5132) Create a Docker Image

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-5132: ------------------------------------- Summary: Create a Docker Image Key: ISPN-5132 URL: https://issues.jboss.org/browse/ISPN-5132 Project: Infinispan Issue Type: Feature Request Components: Docker Reporter: Tristan Tarrant Assignee: Vojtech Juranek Fix For: 7.0.0.Final -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4850) Allow for filter and conversion to be done in one step for cache listeners

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4850?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4850: ----------------------------------------------- Tomas Sykora <tsykora(a)redhat.com> changed the Status of [bug 1157392|https://bugzilla.redhat.com/show_bug.cgi?id=1157392] from ON_QA to VERIFIED > Allow for filter and conversion to be done in one step for cache listeners > -------------------------------------------------------------------------- > > Key: ISPN-4850 > URL: https://issues.jboss.org/browse/ISPN-4850 > Project: Infinispan > Issue Type: Enhancement > Components: Listeners > Affects Versions: 7.0.0.CR1 > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Final > > > Currently the cache listeners can install a CacheEventFilter and CacheEventConverter to be used. However each one requires separate invocations. It would be desireable to have this done as a single invocation akin to what we did for ISPN-4640. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2015