January 2021 - infinispan-issues - Jboss List Archives

[Red Hat JIRA] (ISPN-12226) BlockingManager enhance limited concurrency API

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12226?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12226: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > BlockingManager enhance limited concurrency API > ----------------------------------------------- > > Key: ISPN-12226 > URL: https://issues.redhat.com/browse/ISPN-12226 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Ryan Emerson > Priority: Major > Fix For: 12.1.0.Final > > > Currently the {{BlockingManager}} allows a series of tasks to be executed on a subset of the total number of blocking threads via the {{BlockingManager.BlockingExecutor}} and {{BlockingManager#limitedBlockingExecutor}}. However, the {{BlockingExecutor}} has a limited number of methods in comparison to that provided by {{BlockingManager}}. We should provide an API that allows for the full {{BlockingManager}} capabilities to be executed on a limited executor with the specified level of concurrency. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-8412) Conflict resolution should utilise Merkle trees to improve performance

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-8412?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-8412: ---------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > Conflict resolution should utilise Merkle trees to improve performance > ---------------------------------------------------------------------- > > Key: ISPN-8412 > URL: https://issues.redhat.com/browse/ISPN-8412 > Project: Infinispan > Issue Type: Enhancement > Components: Core, State Transfer > Affects Versions: 9.2.0.Alpha1 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 12.1.0.Final > > > Currently we detect conflicts between CacheEntry replicas by retrieving all entries for a cache segment and comparing their values on the node initiating the conflict resolution. This does not scale. Instead, we should generate a Merkle tree for each segment on the replica nodes. When initiating conflict resolution, it is then possible to retrieve a segments hash from each of its owners and determine if a conflict is present before requesting the conflicting entries. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-9079) Cache operations during Conflict Resolution phase should force CR on that key

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-9079?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-9079: ---------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > Cache operations during Conflict Resolution phase should force CR on that key > ----------------------------------------------------------------------------- > > Key: ISPN-9079 > URL: https://issues.redhat.com/browse/ISPN-9079 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 9.2.1.Final > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 12.1.0.Final > > > During a partition merge conflict resolution can take a long time when there are many entries, therefore if a user initiates an operation on a key during this phase, it should force CR to occur on the key before executing the operation. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-9084) Conflict resolution should be distributed amongst primary replicas

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-9084?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-9084: ---------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > Conflict resolution should be distributed amongst primary replicas > ------------------------------------------------------------------ > > Key: ISPN-9084 > URL: https://issues.redhat.com/browse/ISPN-9084 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 9.2.1.Final > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 12.1.0.Final > > > Currently conflict resolution is executed entirely on the cluster coordinator on a per segment basis. However, as conflict resolution requires the retrieval of all copies of a given segment to be returned, it's only possible to process entries one segment at a time in an attempt to avoid the coordinator running out of memory. Distributing CR to each segment's primary owner will allow for greater parallelism and scalability as the size of the cluster increases. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-9592) Lockdown query internals

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-9592?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-9592: ---------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > Lockdown query internals > ------------------------ > > Key: ISPN-9592 > URL: https://issues.redhat.com/browse/ISPN-9592 > Project: Infinispan > Issue Type: Task > Reporter: Nistor Adrian > Assignee: Nistor Adrian > Priority: Major > Labels: SesarchNG > Fix For: 12.1.0.Final > > > Many things in query implementation are left public although they are very prone to creating insidious bugs if accessed externally. These are not proper extension points and should be made package local or provided strictly via SearchManagerImplementor. > * Move SearchManager.purge(Class) method to SearchManagerImplementor > * DefaultSearchWorkCreator should be moved to org.infinispan.query.backend and made package local > * TransactionalEventTransactionContext is not used, can be removed, and its non-tx counterpart (NoTransactionContext) no longer has to be public > * all public methods in QueryInterceptor must be reviewed and made package local ASAP -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-9738) Support for entry iteration in the REST server

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-9738?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-9738: ---------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > Support for entry iteration in the REST server > ---------------------------------------------- > > Key: ISPN-9738 > URL: https://issues.redhat.com/browse/ISPN-9738 > Project: Infinispan > Issue Type: Enhancement > Components: REST > Affects Versions: 9.4.1.Final > Reporter: Gustavo Fernandes > Assignee: Katia Aresti > Priority: Optional > Fix For: 12.1.0.Final > > > Currently the REST server has an operation to get all keys that has limitations since all the keys are retrieved to a single node before serving to the client. > Ideally, it should have an efficient way of retrieving entries making use of iterators. The API should provide a cursor/scroll/handle so that the client can pull the data without causing memory issues. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-10030) Add Automatic-Module-Names to jars

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-10030?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-10030: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > Add Automatic-Module-Names to jars > ---------------------------------- > > Key: ISPN-10030 > URL: https://issues.redhat.com/browse/ISPN-10030 > Project: Infinispan > Issue Type: Feature Request > Components: Build > Reporter: Tristan Tarrant > Assignee: Dan Berindei > Priority: Major > Fix For: 12.1.0.Final > > > All jars should have a Automatic-Module-Name entry added to the MANIFEST -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-11110) JdbcStringBasedStore Purge should not use FOR UPDATE to avoid excessive locking

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11110?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11110: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > JdbcStringBasedStore Purge should not use FOR UPDATE to avoid excessive locking > ------------------------------------------------------------------------------- > > Key: ISPN-11110 > URL: https://issues.redhat.com/browse/ISPN-11110 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 10.1.0.CR1 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 12.1.0.Final > > > https://issues.redhat.com/browse/ISPN-10337 Added the FOR UPDATE to the select query used by the purge method in order to ensure that the purge method would lock all of the affected rows so that no subsequent updates to a key could be incorrectly removed by the purge method. > However, if the purge does a select for update and does a single commit at the end of the purge, that will block write operations on all the expired keys for the entire duration of the purge. The clustered purge listener does cache.removeLifespanExpired(key, null, null).join(), so the entire duration of the purge could mean a really long time. > Instead we should utilise a normal select query followed by a 'delete from table where id = ? and timestamp = ?' to prevent accidentally deleting an update. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-11117) In a distributed cache stale entries are not removed from the store

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11117?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11117: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > In a distributed cache stale entries are not removed from the store > ------------------------------------------------------------------- > > Key: ISPN-11117 > URL: https://issues.redhat.com/browse/ISPN-11117 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 9.3.6.Final, 9.4.17.Final, 10.0.1.Final, 10.1.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 12.1.0.Final > > > This is a follow-up on ISPN-11116. It's wrong for invalidation commands to load the previous value from the store, but we also have the opposite problem: in a distributed cache, when a node loses some segments and the store is not segmented, we use an {{InvalidateCommand}} to remove stale entries, and it doesn't actually remove any entries from the store. > Instead of keeping {{InvalidateCommand}} as is and finding another solution for removing stale segments, we could change {{InvalidateCommand}} to also remove entries from private stores. > Invalidation mode is very unlikely to be used with private stores, but we don't actually prohibit it, so it's better for invalidation mode as well if {{InvalidateCommand}} removed entries from the private stores and ignored the shared stores. The only problem remaining is to actually optimize {{CacheLoaderInterceptor}} so that it doesn't load the previous value unless there is a listener. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-11137) Remove AdvancedCache.removeLifespanExpired and removeMaxIdleExpired

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11137?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11137: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > Remove AdvancedCache.removeLifespanExpired and removeMaxIdleExpired > ------------------------------------------------------------------- > > Key: ISPN-11137 > URL: https://issues.redhat.com/browse/ISPN-11137 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 10.1.0.Final > Reporter: Dan Berindei > Assignee: Will Burns > Priority: Major > Fix For: 12.1.0.Final > > > {{removeLifespanExpired}} and {{removeMaxIdleExpired}} are in the {{AdvancedCache}} interface, but they are only for internal use, not public API. > We should remove them, and {{ClusterExpirationManager.removeMaxIdle()}} should create a {{RemoveExpiredCommand}} and execute it with the invocation chain just like {{org.infinispan.cache.impl.CacheImpl.performRemoveExpiredCommand()}} does. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 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 2021