February 2018 - infinispan-issues

[JBoss JIRA] (ISPN-8861) DIST Iteration shouldn't go remote when a shared cache store is present

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8861?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-8861: ------------------------------------- Unfortunately we would still have to go to the remote database to make sure there are not extra entries. In this case we still have an essentially unbounded query which will return everything - so we might as well utilize what it returned. And actually by going remote we would then have N requests to the database to go over everything (until we have segment based stores) - instead of just 1. This would put even more strain on the underlying remote store implementation. > DIST Iteration shouldn't go remote when a shared cache store is present > ----------------------------------------------------------------------- > > Key: ISPN-8861 > URL: https://issues.jboss.org/browse/ISPN-8861 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Reporter: William Burns > Assignee: William Burns > Fix For: 9.3.0.Final > > > When a user runs a distributed iteration operation with a shared cache store, this shouldn't go remote as the local node would have all the data available to it. This is similar to the optimization when we don't go remote if the current node is an owner for all required segments. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8861) DIST Iteration shouldn't go remote when a shared cache store is present

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-8861?page=com.atlassian.jira.plugin.... ] Ryan Emerson commented on ISPN-8861: ------------------------------------ This behaviour should be able to be toggled on/off. I'm thinking in certain situations, i.e. a remote database outside the infinispan cluster, it might be quicker to go remote within the local cluster. > DIST Iteration shouldn't go remote when a shared cache store is present > ----------------------------------------------------------------------- > > Key: ISPN-8861 > URL: https://issues.jboss.org/browse/ISPN-8861 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Reporter: William Burns > Assignee: William Burns > Fix For: 9.3.0.Final > > > When a user runs a distributed iteration operation with a shared cache store, this shouldn't go remote as the local node would have all the data available to it. This is similar to the optimization when we don't go remote if the current node is an owner for all required segments. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8862) Iteration and stream operations with passivation disabled shouldn't use in memory

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8862?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-8862: -------------------------------- Description: When passivation is disabled all entries are assumed to be in the cache loader/store. We currently try to merge these together in a sloppy way [1]. This first reads in memory and then from the store and keeps all keys from in memory to exclude them from the store. Unfortunately the store still has to pull the entries even for the already read keys, but just ignores them. This leads to a lot of inefficiency and memory bloat. Instead we should just return the store entries as is when passivation is disabled. [1] https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o... was: When passivation is disabled all entries are assumed to be in the cache loader/store. We currently try to merge these together in a sloppy way [1]. This first reads in memory and then from the store and keeps all keys from in memory to exclude them from the store. Unfortunately the store still has to pull the entries even for the already read keys, but just ignores them. This leads to a lot of inefficiency and memory bloat. Instead we should just return the store entries as is. [1] https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o... > Iteration and stream operations with passivation disabled shouldn't use in memory > --------------------------------------------------------------------------------- > > Key: ISPN-8862 > URL: https://issues.jboss.org/browse/ISPN-8862 > Project: Infinispan > Issue Type: Enhancement > Reporter: William Burns > Assignee: William Burns > Fix For: 9.3.0.Final > > > When passivation is disabled all entries are assumed to be in the cache loader/store. We currently try to merge these together in a sloppy way [1]. This first reads in memory and then from the store and keeps all keys from in memory to exclude them from the store. Unfortunately the store still has to pull the entries even for the already read keys, but just ignores them. This leads to a lot of inefficiency and memory bloat. Instead we should just return the store entries as is when passivation is disabled. > [1] https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8862) Iteration and stream operations with passivation disabled shouldn't use in memory

by William Burns (JIRA)

William Burns created ISPN-8862: ----------------------------------- Summary: Iteration and stream operations with passivation disabled shouldn't use in memory Key: ISPN-8862 URL: https://issues.jboss.org/browse/ISPN-8862 Project: Infinispan Issue Type: Enhancement Reporter: William Burns Assignee: William Burns Fix For: 9.3.0.Final When passivation is disabled all entries are assumed to be in the cache loader/store. We currently try to merge these together in a sloppy way [1]. This first reads in memory and then from the store and keeps all keys from in memory to exclude them from the store. Unfortunately the store still has to pull the entries even for the already read keys, but just ignores them. This leads to a lot of inefficiency and memory bloat. Instead we should just return the store entries as is. [1] https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8861) DIST Iteration shouldn't go remote when a shared cache store is present

by William Burns (JIRA)

William Burns created ISPN-8861: ----------------------------------- Summary: DIST Iteration shouldn't go remote when a shared cache store is present Key: ISPN-8861 URL: https://issues.jboss.org/browse/ISPN-8861 Project: Infinispan Issue Type: Enhancement Components: Loaders and Stores Reporter: William Burns Assignee: William Burns Fix For: 9.3.0.Final When a user runs a distributed iteration operation with a shared cache store, this shouldn't go remote as the local node would have all the data available to it. This is similar to the optimization when we don't go remote if the current node is an owner for all required segments. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8860) Lazy start counter's caches

by Pedro Ruivo (JIRA)

Pedro Ruivo created ISPN-8860: --------------------------------- Summary: Lazy start counter's caches Key: ISPN-8860 URL: https://issues.jboss.org/browse/ISPN-8860 Project: Infinispan Issue Type: Enhancement Components: Clustered Counter Reporter: Pedro Ruivo Assignee: Pedro Ruivo Goal: if counter's are used, there is no need to start counter's caches! Main change: * remove {{__counter_configuration}} and use the {{state-cache}} to store counter's configuration Summary: * When the first counter is defined and stored in the {{state-cache}}, the {{__counter}} cache is started. * When a node joins, it starts the {{__counter}} cache if it finds a counter's configured stored * We need to persist the counter's configuration (for persisted counters only!) manually since the {{state-cache}} isn't persisted Issues * the {{state-cache}} is available during partitions! same counter can be defined with different configuration :( users have to deal with it while I can't find a way to resolve a conflict. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6026) Segment-aware shared cache stores

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-6026?page=com.atlassian.jira.plugin.... ] William Burns reassigned ISPN-6026: ----------------------------------- Assignee: William Burns (was: Ryan Emerson) > Segment-aware shared cache stores > --------------------------------- > > Key: ISPN-6026 > URL: https://issues.jboss.org/browse/ISPN-6026 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Reporter: Tristan Tarrant > Assignee: William Burns > > Shared cache stores (e.g. JDBC) should be segment-aware so that they only load the keys they own. > Possible implementation: add a segment id column, so that the store can SELECT * FROM table WHERE segment_id = segment > Need to think about how to reconstruct segment ids. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8857) Remove distexec, lucene and gridfs webdav demos from main Infinispan repo

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8857?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-8857: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Remove distexec, lucene and gridfs webdav demos from main Infinispan repo > ------------------------------------------------------------------------- > > Key: ISPN-8857 > URL: https://issues.jboss.org/browse/ISPN-8857 > Project: Infinispan > Issue Type: Task > Components: Demos and Tutorials > Affects Versions: 9.2.0.CR2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 9.2.0.CR3 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8847) createCache taking BasicConfiguration does not wait for operation to complete

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8847?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-8847: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > createCache taking BasicConfiguration does not wait for operation to complete > ----------------------------------------------------------------------------- > > Key: ISPN-8847 > URL: https://issues.jboss.org/browse/ISPN-8847 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management, Remote Protocols > Affects Versions: 9.2.0.CR2 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 9.2.0.CR3 > > > It's not logged and it does not fail the create cache operation. TRACE logs can be found [here|https://gist.github.com/galderz/cf06689e03b61b46413e443041d1485b] -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8847) createCache taking BasicConfiguration does not wait for operation to complete

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8847?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-8847: -------------------------------- Fix Version/s: 9.2.0.CR3 (was: 9.2.0.Final) > createCache taking BasicConfiguration does not wait for operation to complete > ----------------------------------------------------------------------------- > > Key: ISPN-8847 > URL: https://issues.jboss.org/browse/ISPN-8847 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management, Remote Protocols > Affects Versions: 9.2.0.CR2 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 9.2.0.CR3 > > > It's not logged and it does not fail the create cache operation. TRACE logs can be found [here|https://gist.github.com/galderz/cf06689e03b61b46413e443041d1485b] -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues February 2018