March 2018 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-8953) Do not keep old schemas around in the source tree/distribution

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-8953: ------------------------------------- Summary: Do not keep old schemas around in the source tree/distribution Key: ISPN-8953 URL: https://issues.jboss.org/browse/ISPN-8953 Project: Infinispan Issue Type: Bug Components: Configuration Affects Versions: 9.2.0.Final Reporter: Tristan Tarrant Assignee: Tristan Tarrant Fix For: 9.3.0.Alpha1 We should only keep current schema files in the source tree. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-8952) Parser namespaces should support version wildcards

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-8952: ------------------------------------- Summary: Parser namespaces should support version wildcards Key: ISPN-8952 URL: https://issues.jboss.org/browse/ISPN-8952 Project: Infinispan Issue Type: Enhancement Components: Configuration Reporter: Tristan Tarrant Assignee: Tristan Tarrant Fix For: 9.3.0.Final, 9.3.0.Alpha1 The namespace annotations require a maintenance burden when bumping schema versions. By adding support for version wildcards with support boundaries (since, until) we can simplify maintenance. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-8951) LevelDB store parser should not exist past version 8.0

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-8951: ------------------------------------- Summary: LevelDB store parser should not exist past version 8.0 Key: ISPN-8951 URL: https://issues.jboss.org/browse/ISPN-8951 Project: Infinispan Issue Type: Bug Reporter: Tristan Tarrant The LevelDB config parser should refuse to parse schemas newer than 8.0. Namespace-less XMLs should fail to parse with 9.x+ -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPRK-2) Management of cache lifecycles

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPRK-2?page=com.atlassian.jira.plugin.sy... ] Work on ISPRK-2 started by Gustavo Fernandes. --------------------------------------------- > Management of cache lifecycles > ------------------------------ > > Key: ISPRK-2 > URL: https://issues.jboss.org/browse/ISPRK-2 > Project: Infinispan Spark > Issue Type: Feature Request > Reporter: RJ Nowling > Assignee: Gustavo Fernandes > Fix For: 0.7 > > > For analytics use cases, the caches will rarely be known ahead of time -- they are dependent on the particular jobs being run. As such, jobs should have the ability to manage the lifecycle of caches, in particular: > * Checking if a cache exists > * Creating a cache > * Deleting a cache > * Clearing a cache -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-8949) Clear from data container doesn't remove expired entries

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-8949?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-8949: ------------------------------- Description: ISPN-8548 changed it so that we don't pull entries into memory at once for a clear. However it also is using the iterator method which doesn't return expired entries. We should also return and subsequently remove expired entries. (was: The issue https://issues.jboss.org/browse/ISPN-8548 changed it so that we don't pull entries into memory at once for a clear. However it also is using the iterator method which doesn't return expired entries. We should also return and subsequently remove expired entries.) > Clear from data container doesn't remove expired entries > -------------------------------------------------------- > > Key: ISPN-8949 > URL: https://issues.jboss.org/browse/ISPN-8949 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.2.0.Final > Reporter: William Burns > Assignee: William Burns > Fix For: 9.2.1.Final > > > ISPN-8548 changed it so that we don't pull entries into memory at once for a clear. However it also is using the iterator method which doesn't return expired entries. We should also return and subsequently remove expired entries. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-8868) Expose force unlock with JMX

by Katia Aresti (JIRA)

[ https://issues.jboss.org/browse/ISPN-8868?page=com.atlassian.jira.plugin.... ] Katia Aresti updated ISPN-8868: ------------------------------- Status: Open (was: New) > Expose force unlock with JMX > ---------------------------- > > Key: ISPN-8868 > URL: https://issues.jboss.org/browse/ISPN-8868 > Project: Infinispan > Issue Type: Enhancement > Components: Clustered Locks > Reporter: Katia Aresti > Assignee: Katia Aresti > > Expose a way with JMX to force the release of a lock -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-8868) Expose force unlock with JMX

by Katia Aresti (JIRA)

[ https://issues.jboss.org/browse/ISPN-8868?page=com.atlassian.jira.plugin.... ] Work on ISPN-8868 started by Katia Aresti. ------------------------------------------ > Expose force unlock with JMX > ---------------------------- > > Key: ISPN-8868 > URL: https://issues.jboss.org/browse/ISPN-8868 > Project: Infinispan > Issue Type: Enhancement > Components: Clustered Locks > Reporter: Katia Aresti > Assignee: Katia Aresti > > Expose a way with JMX to force the release of a lock -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-8946) All collection wrappers should always delegate to underlying collections where available

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8946?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-8946: ------------------------------------- I have to rethink this as write operations will not work without first obtaining the lock to the cache in the LOCAL or INVAL cases (REPL/DIST/SCATTERED) would be fine as they always delegate to the cache, unless CACHE_MODE_LOCAL is supplied (which has many issues with write operations on these caches anyways). > All collection wrappers should always delegate to underlying collections where available > ---------------------------------------------------------------------------------------- > > Key: ISPN-8946 > URL: https://issues.jboss.org/browse/ISPN-8946 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.2.0.Final > Reporter: William Burns > Assignee: William Burns > > All places that override values returned from keySet and entrySet should always delegate appropriately to the underlying keySet or entrySet. We should try to be as minimally invasive to each level down as possible. An example would be that we shouldn't create copies of said collections if possible and instead just use delegates. > https://github.com/infinispan/infinispan/pull/5794#discussion_r173789766 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-8946) All collection wrappers should always delegate to underlying collections where available

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8946?page=com.atlassian.jira.plugin.... ] William Burns edited comment on ISPN-8946 at 3/15/18 4:55 PM: -------------------------------------------------------------- Also we should finally fix this so that each level of interceptor properly handle what they are supposed to. The main ones are * (KeySet|EntrySet)Command - the collections produced from here should only ever touch the underlying DataContainer * CacheLoaderInterceptor - the collections produced here should only ever read/write from the store and delegate to super collection * PrefetchInterceptor - this should only affect iterator and stream operations it seems and delegate everything else to super collection * TxInterceptor - the collections produced here should only ever read/write from the transaction and delegate to the super collection * DistributionBulkInterceptor - the collections here should write directly to the cache (as we are in a clustered scenario) This leads to a very distinct set of responsibilities. Also then flags such as CACHE_MODE_LOCAL should just work without having to read them except at the DistributionBulkInterceptor or "InvalidationBulkInterceptor" level. The various cache modes would thus be covered in the following manner: * LOCAL (everything is handled in CacheLoaderInterceptor or commands) * REPL / DIST (DistributionBulkInterceptor relies on all writes to be handled at it's level directly to the cache and uses local reads when necessary) * SCATTERD same as REPL / DIST but Prefetch also sits between bulk and cache loader to guarantee proper iterator/stream * INVAL we will need to add a new interceptor where bulk usually is for the sole purpose of handling invalidation write methods on these collections that is passed directly to the cache object. We also have the collections created at the Cache level (ie. EncoderCache). This should always delegate to the underlying collection and just ensure that all keys/values are properly converted to or from the proper formats. was (Author: william.burns): Also we should finally fix this so that each level of interceptor properly handle what they are supposed to. The main ones are (KeySet|EntrySet)Command - the collections produced from here should only ever touch the underlying DataContainer CacheLoaderInterceptor - the collections produced here should only ever read/write from the store and delegate to super collection PrefetchInterceptor - this should only affect iterator and stream operations it seems and delegate everything else to super collection TxInterceptor - the collections produced here should only ever read/write from the transaction and delegate to the super collection DistributionBulkInterceptor - the collections here should write directly to the cache (as we are in a clustered scenario) This leads to a very distinct set of responsibilities. Also then flags such as CACHE_MODE_LOCAL should just work without having to read them except at the DistributionBulkInterceptor or "InvalidationBulkInterceptor" level. The various cache modes would thus be covered in the following manner: LOCAL (everything is handled in CacheLoaderInterceptor or commands) REPL / DIST (DistributionBulkInterceptor relies on all writes to be handled at it's level directly to the cache and uses local reads when necessary) SCATTERD same as REPL / DIST but Prefetch also sits between bulk and cache loader to guarantee proper iterator/stream INVAL we will need to add a new interceptor where bulk usually is for the sole purpose of handling invalidation write methods on these collections that is passed directly to the cache object. We also have the collections created at the Cache level (ie. EncoderCache). This should always delegate to the underlying collection and just ensure that all keys/values are properly converted to or from the proper formats. > All collection wrappers should always delegate to underlying collections where available > ---------------------------------------------------------------------------------------- > > Key: ISPN-8946 > URL: https://issues.jboss.org/browse/ISPN-8946 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.2.0.Final > Reporter: William Burns > Assignee: William Burns > > All places that override values returned from keySet and entrySet should always delegate appropriately to the underlying keySet or entrySet. We should try to be as minimally invasive to each level down as possible. An example would be that we shouldn't create copies of said collections if possible and instead just use delegates. > https://github.com/infinispan/infinispan/pull/5794#discussion_r173789766 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-8946) All collection wrappers should always delegate to underlying collections where available

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8946?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-8946: ------------------------------------- Also we should finally fix this so that each level of interceptor properly handle what they are supposed to. The main ones are (KeySet|EntrySet)Command - the collections produced from here should only ever touch the underlying DataContainer CacheLoaderInterceptor - the collections produced here should only ever read/write from the store and delegate to super collection PrefetchInterceptor - this should only affect iterator and stream operations it seems and delegate everything else to super collection TxInterceptor - the collections produced here should only ever read/write from the transaction and delegate to the super collection DistributionBulkInterceptor - the collections here should write directly to the cache (as we are in a clustered scenario) This leads to a very distinct set of responsibilities. Also then flags such as CACHE_MODE_LOCAL should just work without having to read them except at the DistributionBulkInterceptor or "InvalidationBulkInterceptor" level. The various cache modes would thus be covered in the following manner: LOCAL (everything is handled in CacheLoaderInterceptor or commands) REPL / DIST (DistributionBulkInterceptor relies on all writes to be handled at it's level directly to the cache and uses local reads when necessary) SCATTERD same as REPL / DIST but Prefetch also sits between bulk and cache loader to guarantee proper iterator/stream INVAL we will need to add a new interceptor where bulk usually is for the sole purpose of handling invalidation write methods on these collections that is passed directly to the cache object. We also have the collections created at the Cache level (ie. EncoderCache). This should always delegate to the underlying collection and just ensure that all keys/values are properly converted to or from the proper formats. > All collection wrappers should always delegate to underlying collections where available > ---------------------------------------------------------------------------------------- > > Key: ISPN-8946 > URL: https://issues.jboss.org/browse/ISPN-8946 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.2.0.Final > Reporter: William Burns > Assignee: William Burns > > All places that override values returned from keySet and entrySet should always delegate appropriately to the underlying keySet or entrySet. We should try to be as minimally invasive to each level down as possible. An example would be that we shouldn't create copies of said collections if possible and instead just use delegates. > https://github.com/infinispan/infinispan/pull/5794#discussion_r173789766 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

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 2018