April 2020 - infinispan-issues - Jboss List Archives

by Pedro Zapata Fernandez (Jira)

[ https://issues.redhat.com/browse/ISPN-11499?page=com.atlassian.jira.plugi... ] Pedro Zapata Fernandez updated ISPN-11499: ------------------------------------------ Fix Version/s: 11.0.0.Final > Delete entry > ------------ > > Key: ISPN-11499 > URL: https://issues.redhat.com/browse/ISPN-11499 > Project: Infinispan > Issue Type: Feature Request > Components: Console > Affects Versions: 10.1.5.Final > Reporter: Katia Aresti > Assignee: Katia Aresti > Priority: Major > Labels: console-ng > Fix For: 11.0.0.Final > > > Kebap menu on an entry line has a "delete" button > https://marvelapp.com/6j85bdb/screen/66827529 > When we click on the button, a pop up is displayed to confirm deletion > If deletion is done, display a confirmation message and add the action in the activity list -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11550) Add way to detect if calling context is blocking or not

by Pedro Zapata Fernandez (Jira)

[ https://issues.redhat.com/browse/ISPN-11550?page=com.atlassian.jira.plugi... ] Pedro Zapata Fernandez reassigned ISPN-11550: --------------------------------------------- Assignee: Will Burns > Add way to detect if calling context is blocking or not > ------------------------------------------------------- > > Key: ISPN-11550 > URL: https://issues.redhat.com/browse/ISPN-11550 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > > A user can use either our blocking (Cache#put) or non blocking (Cache#putAsync) API. We should be able to optimize our usage of blocking threads based on this. In the case that the user is using the blocking API, we can assume the thread is a blocking thread (even though we don't control it), which would allow us to not have to spawn additional threads to wait providing for less context switching and better resource utilization. > The main question is how do we detect such things. An idea is a thread local, command boolean, context flag etc. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11500) Clear all entries

by Pedro Zapata Fernandez (Jira)

[ https://issues.redhat.com/browse/ISPN-11500?page=com.atlassian.jira.plugi... ] Pedro Zapata Fernandez updated ISPN-11500: ------------------------------------------ Fix Version/s: 11.0.0.Final > Clear all entries > ----------------- > > Key: ISPN-11500 > URL: https://issues.redhat.com/browse/ISPN-11500 > Project: Infinispan > Issue Type: Feature Request > Components: Console > Affects Versions: 10.1.5.Final > Reporter: Katia Aresti > Assignee: Katia Aresti > Priority: Major > Labels: console-ng > Fix For: 11.0.0.Final > > > In the kebab menu of the entries tab, display a clear all entries > https://marvelapp.com/6j85bdb/screen/67089688 > Display a confirmation pop up > https://marvelapp.com/6j85bdb/screen/67089690 > If all entries are deleted, come back to the list and display a confirmation message -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11494) Delete cache from the list

by Pedro Zapata Fernandez (Jira)

[ https://issues.redhat.com/browse/ISPN-11494?page=com.atlassian.jira.plugi... ] Pedro Zapata Fernandez updated ISPN-11494: ------------------------------------------ Fix Version/s: 11.0.0.Final > Delete cache from the list > -------------------------- > > Key: ISPN-11494 > URL: https://issues.redhat.com/browse/ISPN-11494 > Project: Infinispan > Issue Type: Feature Request > Components: Console > Affects Versions: 10.1.5.Final > Reporter: Katia Aresti > Assignee: Katia Aresti > Priority: Major > Labels: console-ng > Fix For: 11.0.0.Final > > > Display a kebab menu on each cache in the cache list with a delete button > https://marvelapp.com/6j85bdb/screen/66827505 > When the button is clicked, display a pop up menu with a question and a validation on the cache we want to delete > https://marvelapp.com/6j85bdb/screen/66827506 > if the cache is removed, come back to the list and display a message > https://marvelapp.com/6j85bdb/screen/66827508 -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 12 months

1
0
0 / 0

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

by Pedro Zapata Fernandez (Jira)

[ https://issues.redhat.com/browse/ISPN-8412?page=com.atlassian.jira.plugin... ] Pedro Zapata Fernandez updated ISPN-8412: ----------------------------------------- Fix Version/s: 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.0.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 (v7.13.8#713008)

5 years, 12 months

1
0
0 / 0

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

by Pedro Zapata Fernandez (Jira)

[ https://issues.redhat.com/browse/ISPN-9079?page=com.atlassian.jira.plugin... ] Pedro Zapata Fernandez updated ISPN-9079: ----------------------------------------- Fix Version/s: 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.0.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 (v7.13.8#713008)

5 years, 12 months

1
0
0 / 0

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

by Pedro Zapata Fernandez (Jira)

[ https://issues.redhat.com/browse/ISPN-9084?page=com.atlassian.jira.plugin... ] Pedro Zapata Fernandez updated ISPN-9084: ----------------------------------------- Fix Version/s: 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.0.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 (v7.13.8#713008)

5 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11646) Drop Elasticsearch support

by Gustavo Fernandes (Jira)

[ https://issues.redhat.com/browse/ISPN-11646?page=com.atlassian.jira.plugi... ] Gustavo Fernandes updated ISPN-11646: ------------------------------------- Description: This experimental integration hasn't been maintained for a while and doesn't support all aspects of query/indexing (was: This integration hasn't been maintained for a while and doesn't support all aspects of query/indexing) > Drop Elasticsearch support > -------------------------- > > Key: ISPN-11646 > URL: https://issues.redhat.com/browse/ISPN-11646 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying, Remote Querying > Affects Versions: 11.0.0.Dev04 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > Fix For: 11.0.0.Final, 11.0.0.Dev05 > > > This experimental integration hasn't been maintained for a while and doesn't support all aspects of query/indexing -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10309) Convert Remaining Parts to Non Blocking & Reduce Thread Pools

by Pedro Zapata Fernandez (Jira)

[ https://issues.redhat.com/browse/ISPN-10309?page=com.atlassian.jira.plugi... ] Pedro Zapata Fernandez updated ISPN-10309: ------------------------------------------ Fix Version/s: 11.0.0.Final > Convert Remaining Parts to Non Blocking & Reduce Thread Pools > ------------------------------------------------------------- > > Key: ISPN-10309 > URL: https://issues.redhat.com/browse/ISPN-10309 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 11.0.0.Final > > > We would love to get our thread pools down to a single CPU thread pool (size = numCores) and a blocking thread pool (arbitrarily large). We may also require a scheduler pool for various options as well (limited size 1-2?). > To do this we need to remove remnants of our blocking code as possible. Possible issues for blocking are mostly around locks and io operations. > The persistence layer was completed with ISPN-9722 so that is not an issue. > The requirement around locking can be relaxed if the locks are guaranteed to be small in scope and do not wrap other blocking operations. An example would be a lock such as ones in CHM as long as we don't have large blocks for functional argument types. > If code cannot be made non blocking we must offload the operation to the blocking thread pool. Care must be taken to ensure that once the blocking portion of code is completed that we switch back the to CPU thread pool as soon as possible. The listener API for example is violating this and will run code in Infinispan from any thread that completes the listener that could be done from a user. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11581) Query documentation is outdated

by Pedro Zapata Fernandez (Jira)

[ https://issues.redhat.com/browse/ISPN-11581?page=com.atlassian.jira.plugi... ] Pedro Zapata Fernandez reassigned ISPN-11581: --------------------------------------------- Assignee: Donald Naro (was: Gustavo Fernandes) > Query documentation is outdated > ------------------------------- > > Key: ISPN-11581 > URL: https://issues.redhat.com/browse/ISPN-11581 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation > Reporter: Gustavo Fernandes > Assignee: Donald Naro > Priority: Major > Fix For: 11.0.0.Final > > > It needs a full review since many things changed on 11.0, such as removal of InfinispanIndexManager, AffinityIndexManager, auto-broadcast, removal of Index.ALL/NONE/PRIMARY_OWNER, hibernate search upgrade, etc -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 12 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 April 2020