January 2015 - infinispan-issues - Jboss List Archives

[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 commented on ISPN-5103: ----------------------------------------- Even being stored, Lucene will store it once, the same for the derived terms. The overhead is that for very large indexes, since this entity is present on all documents, there'll be a big posting list associated with it. Even if the postings are stored and traversed efficiently (skip lists + Vint) we could certainly get rid of it if not needed. I'm just thinking if it could be useful when querying directly via Lucene. > 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-4955) JCache implementation over HotRod

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4955?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-4955: ------------------------------------- Assignee: Ion Savin > JCache implementation over HotRod > --------------------------------- > > Key: ISPN-4955 > URL: https://issues.jboss.org/browse/ISPN-4955 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Reporter: Tristan Tarrant > Assignee: Ion Savin > Fix For: 7.1.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4955) JCache implementation over HotRod

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4955?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4955: ---------------------------------- Status: Open (was: New) > JCache implementation over HotRod > --------------------------------- > > Key: ISPN-4955 > URL: https://issues.jboss.org/browse/ISPN-4955 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Reporter: Tristan Tarrant > Assignee: Ion Savin > Fix For: 7.1.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5131) Deploy custom cache store to Infinispan Server

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-5131: ------------------------------------- Summary: Deploy custom cache store to Infinispan Server Key: ISPN-5131 URL: https://issues.jboss.org/browse/ISPN-5131 Project: Infinispan Issue Type: Feature Request Components: Loaders and Stores, Server Reporter: Tristan Tarrant Assignee: Galder Zamarreño Fix For: 7.2.0.Final Support the deployment and configuration of a custom cache store -- 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)

Galder Zamarreño created ISPN-5130: -------------------------------------- Summary: 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.0.3.Final, 7.1.0.Alpha1 Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 7.1.0.Beta1, 7.1.0.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-5000) Cleanup rebalance confirmation collector when node is not coord

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5000?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5000: ----------------------------------------------- Radim Vansa <rvansa(a)redhat.com> changed the Status of [bug 1166243|https://bugzilla.redhat.com/show_bug.cgi?id=1166243] from ON_QA to VERIFIED > Cleanup rebalance confirmation collector when node is not coord > --------------------------------------------------------------- > > Key: ISPN-5000 > URL: https://issues.jboss.org/browse/ISPN-5000 > Project: Infinispan > Issue Type: Bug > Components: State Transfer > Affects Versions: 7.0.1.Final > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.1.0.Beta1, 7.0.3.Final > > > The rebalance confirmation collector is not properly cleared when node becomes non-coordinator. Therefore, when it becomes coordinator, it does not start the rebalance. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5129) Add a clustered transactional cache example for Infinispan Server

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-5129: -------------------------------------- Summary: Add a clustered transactional cache example for Infinispan Server Key: ISPN-5129 URL: https://issues.jboss.org/browse/ISPN-5129 Project: Infinispan Issue Type: Task Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 7.1.0.Beta1, 7.1.0.Final We should add a transactional cache example as a separate configuration in docs/examples folder. There's no such example at the moment, and this is really needed in order to avoid WARN messages when conditional versioned operations are used, e.g. {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} Also, this WARN message should only appear when the cache is clustered and there's > 1 node in the cluster, but currently it also appears in local caches, but this is a different issue... -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5129) Add a clustered transactional cache example for Infinispan Server

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5129?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5129: ----------------------------------- Description: We should add a transactional cache example as a separate configuration in docs/examples folder. There's no such example at the moment, and this is really needed in order to avoid WARN messages when conditional versioned operations are used, e.g. {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} Also, this WARN message should only appear when the cache is clustered and there's > 1 node in the cluster, but currently it also appears in local caches, but this is a different issue... was: We should add a transactional cache example as a separate configuration in docs/examples folder. There's no such example at the moment, and this is really needed in order to avoid WARN messages when conditional versioned operations are used, e.g. {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} Also, this WARN message should only appear when the cache is clustered and there's > 1 node in the cluster, but currently it also appears in local caches, but this is a different issue... > Add a clustered transactional cache example for Infinispan Server > ----------------------------------------------------------------- > > Key: ISPN-5129 > URL: https://issues.jboss.org/browse/ISPN-5129 > Project: Infinispan > Issue Type: Task > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.1.0.Beta1, 7.1.0.Final > > > We should add a transactional cache example as a separate configuration in docs/examples folder. > There's no such example at the moment, and this is really needed in order to avoid WARN messages when conditional versioned operations are used, e.g. > {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} > Also, this WARN message should only appear when the cache is clustered and there's > 1 node in the cluster, but currently it also appears in local caches, but this is a different issue... -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5060) PartitionHandling: remove unavailable mode

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5060?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5060: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1179926|https://bugzilla.redhat.com/show_bug.cgi?id=1179926] from NEW to ASSIGNED > PartitionHandling: remove unavailable mode > ------------------------------------------ > > Key: ISPN-5060 > URL: https://issues.jboss.org/browse/ISPN-5060 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 7.0.2.Final, 7.1.0.Alpha1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.1.0.Final > > > The Unavailable mode name is misleading, because some keys are available, just like in Degraded mode. > The only difference between Degraded and Unavailable is that with Degraded the cluster might recover without manual intervention. The administrator still has to know a lot more details in order to decide whether manual intervention is needed or not. So it would be less confusing if gracefully shutting down {{numOwners}} nodes in quick succession would leave the cache in Degraded mode instead of Unavailable. > Instead of removing the Unavailable mode completely, we could also change it to deny access to all the keys and allow the administrator to use it. E.g. if we had an operation to dump the cache into a shared store and another to load the cache from a shared store, the administrator could force the cache into Unavailable mode while dumping/loading the cache. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3959) JdbcBinaryStore's expiration locks buckets indefinitely

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3959?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3959: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1176265|https://bugzilla.redhat.com/show_bug.cgi?id=1176265] from ASSIGNED to POST > JdbcBinaryStore's expiration locks buckets indefinitely > ------------------------------------------------------- > > Key: ISPN-3959 > URL: https://issues.jboss.org/browse/ISPN-3959 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.2.Final, 7.0.0.Alpha4 > Reporter: Radim Vansa > Assignee: Radim Vansa > Fix For: 7.0.0.Alpha5, 7.0.0.Final > > > The buckets are locked in eviction thread (in the main purge method), while unlocked in BucketPurger.call() which is executed in persistence thread. The unlock fails and the buckets stay locked indefinitely. > Another error is that the Bucket class is not serializable. > This is also a bug in BaseStoreTest as this uses WithinThreadExecutor as the executor for purging while usually this is done in different thread. Moreover, as the purge method is actually not obliged to purge anything, the test does not test the purging itself, but rather a check for expired entry when it is loaded (contains operation). The purging should be enforced by purge listener (calling the purge method until all entries are purged). -- 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