September 2020 - infinispan-issues

[JBoss JIRA] (ISPN-12353) REST allow backup restore progress to be submitted and polled

by Ryan Emerson (Jira)

[ https://issues.redhat.com/browse/ISPN-12353?page=com.atlassian.jira.plugi... ] Ryan Emerson updated ISPN-12353: -------------------------------- Description: The current rest endpoint for restoring backups is too restrictive, as there is no way to submit a restoration and then poll it's current status. We should add the following so that the endpoints are akin to the process for creating a backup: {code} # Create, return 202 or 409 if {restoreName} already exists POST /rest/v2/cache-managers/{cacheManagerName}/restores/{restoreName} # Poll progress 201 complete, 202 if in progress, or 404 if not found HEAD /rest/v2/cache-managers/{cacheManagerName}/restores/{restoreName} {code} was: The current rest endpoint for restoring backups is too restrictive, as there is no way to submit a restoration and then poll it's current status. We should add the following so that the endpoints are akin to the process for creating a backup: {code} # Create, return 202 or 409 if \{restoreName} already exists POST /rest/v2/cache-managers/\{cacheManagerName}/restores/\{restoreName} # Poll progress 201 complete, 202 if in progress, or 404 if not found HEAD /rest/v2/cache-managers/ {cacheManagerName}/restores/{restoreName} {code} > REST allow backup restore progress to be submitted and polled > ------------------------------------------------------------- > > Key: ISPN-12353 > URL: https://issues.redhat.com/browse/ISPN-12353 > Project: Infinispan > Issue Type: Enhancement > Components: REST > Affects Versions: 12.0.0.Dev03 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 12.0.0.Final > > > The current rest endpoint for restoring backups is too restrictive, as there is no way to submit a restoration and then poll it's current status. We should add the following so that the endpoints are akin to the process for creating a backup: > {code} > # Create, return 202 or 409 if {restoreName} already exists > POST /rest/v2/cache-managers/{cacheManagerName}/restores/{restoreName} > # Poll progress 201 complete, 202 if in progress, or 404 if not found > HEAD /rest/v2/cache-managers/{cacheManagerName}/restores/{restoreName} > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12353) REST allow backup restore progress to be submitted and polled

by Ryan Emerson (Jira)

[ https://issues.redhat.com/browse/ISPN-12353?page=com.atlassian.jira.plugi... ] Ryan Emerson updated ISPN-12353: -------------------------------- Description: The current rest endpoint for restoring backups is too restrictive, as there is no way to submit a restoration and then poll it's current status. We should add the following so that the endpoints are akin to the process for creating a backup: {code} # Create, return 202 or 409 if \{restoreName} already exists POST /rest/v2/cache-managers/\{cacheManagerName}/restores/\{restoreName} # Poll progress 201 complete, 202 if in progress, or 404 if not found HEAD /rest/v2/cache-managers/ {cacheManagerName}/restores/{restoreName} {code} was: The current rest endpoint for restoring backups is too restrictive, as there is no way to submit a restoration and then poll it's current status. We should add the following so that the endpoints are akin to the process for creating a backup: ``` # Create, return 202 or 409 if \{restoreName} already exists POST /rest/v2/cache-managers/\{cacheManagerName}/restores/\{restoreName} # Poll progress 201 complete, 202 if in progress, or 404 if not found HEAD /rest/v2/cache-managers/ \{cacheManagerName} /restores/ {restoreName} ``` > REST allow backup restore progress to be submitted and polled > ------------------------------------------------------------- > > Key: ISPN-12353 > URL: https://issues.redhat.com/browse/ISPN-12353 > Project: Infinispan > Issue Type: Enhancement > Components: REST > Affects Versions: 12.0.0.Dev03 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 12.0.0.Final > > > The current rest endpoint for restoring backups is too restrictive, as there is no way to submit a restoration and then poll it's current status. We should add the following so that the endpoints are akin to the process for creating a backup: > {code} > # Create, return 202 or 409 if \{restoreName} already exists > POST /rest/v2/cache-managers/\{cacheManagerName}/restores/\{restoreName} > # Poll progress 201 complete, 202 if in progress, or 404 if not found > HEAD /rest/v2/cache-managers/ {cacheManagerName}/restores/{restoreName} > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12353) REST allow backup restore progress to be submitted and polled

by Ryan Emerson (Jira)

Ryan Emerson created ISPN-12353: ----------------------------------- Summary: REST allow backup restore progress to be submitted and polled Key: ISPN-12353 URL: https://issues.redhat.com/browse/ISPN-12353 Project: Infinispan Issue Type: Enhancement Components: REST Affects Versions: 12.0.0.Dev03 Reporter: Ryan Emerson Assignee: Ryan Emerson Fix For: 12.0.0.Final The current rest endpoint for restoring backups is too restrictive, as there is no way to submit a restoration and then poll it's current status. We should add the following so that the endpoints are akin to the process for creating a backup: ``` # Create, return 202 or 409 if \{restoreName} already exists POST /rest/v2/cache-managers/\{cacheManagerName}/restores/\{restoreName} # Poll progress 201 complete, 202 if in progress, or 404 if not found HEAD /rest/v2/cache-managers/ \{cacheManagerName} /restores/ {restoreName} ``` -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12352) Set license information when missing

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-12352?page=com.atlassian.jira.plugi... ] Pedro Ruivo updated ISPN-12352: ------------------------------- Status: Open (was: New) > Set license information when missing > ------------------------------------ > > Key: ISPN-12352 > URL: https://issues.redhat.com/browse/ISPN-12352 > Project: Infinispan > Issue Type: Enhancement > Components: Build > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Major > Fix For: 11.0.4.Final, 12.0.0.Dev04 > > > There are some dependencies that don't report the licenses in the expected places (pom.xml for maven, package.json for nodejs). In those cases, the license is reported as "unknown" or empty. > Create a new class in infinispan-tools where it receives an XML (manually created) with the licenses for "problematic" dependencies and merge it in the licenses.xml file. It shouldn't touch correct reported licenses. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12352) Set license information when missing

by Pedro Ruivo (Jira)

Pedro Ruivo created ISPN-12352: ---------------------------------- Summary: Set license information when missing Key: ISPN-12352 URL: https://issues.redhat.com/browse/ISPN-12352 Project: Infinispan Issue Type: Enhancement Components: Build Reporter: Pedro Ruivo Assignee: Pedro Ruivo Fix For: 11.0.4.Final, 12.0.0.Dev04 There are some dependencies that don't report the licenses in the expected places (pom.xml for maven, package.json for nodejs). In those cases, the license is reported as "unknown" or empty. Create a new class in infinispan-tools where it receives an XML (manually created) with the licenses for "problematic" dependencies and merge it in the licenses.xml file. It shouldn't touch correct reported licenses. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12351) ImmutableListCopy makes too many copies

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-12351?page=com.atlassian.jira.plugi... ] Dan Berindei updated ISPN-12351: -------------------------------- Status: Open (was: New) > ImmutableListCopy makes too many copies > --------------------------------------- > > Key: ISPN-12351 > URL: https://issues.redhat.com/browse/ISPN-12351 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 12.0.0.Dev03 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Minor > Fix For: 12.0.0.Dev04 > > > An array copy is not needed when creating a new {{ImmutableListCopy}} instance from another {{ImmutableListCopy}}. > The constructor with 2 list parameters can also avoid one array allocation by pre-allocating the array, or by using one list's array when the other list is empty. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12351) ImmutableListCopy makes too many copies

by Dan Berindei (Jira)

Dan Berindei created ISPN-12351: ----------------------------------- Summary: ImmutableListCopy makes too many copies Key: ISPN-12351 URL: https://issues.redhat.com/browse/ISPN-12351 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 12.0.0.Dev03 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 12.0.0.Dev04 An array copy is not needed when creating a new {{ImmutableListCopy}} instance from another {{ImmutableListCopy}}. The constructor with 2 list parameters can also avoid one array allocation by pre-allocating the array, or by using one list's array when the other list is empty. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12350) Persistent UUIDs are only used for initial consistent hash

by Dan Berindei (Jira)

Dan Berindei created ISPN-12350: ----------------------------------- Summary: Persistent UUIDs are only used for initial consistent hash Key: ISPN-12350 URL: https://issues.redhat.com/browse/ISPN-12350 Project: Infinispan Issue Type: Bug Components: Core, State Transfer Affects Versions: 11.0.3.Final, 12.0.0.Dev03 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 12.0.0.Final After a graceful restart, the persisted UUIDs are used to re-create the consistent hash of the cache before shutdown. This initial CH will not be rebalanced, so there is no state transfer immediately after cluster restart. However, if something then triggers a rebalance (e.g. a node join/leave), the persistent UUIDs are ignored, and {{SyncConsistentHashFactory}} allocates segments based on the new JGroups addresses instead of the persistent UUIDs. I modified {{ThreeNodeDistGlobalStateRestartTest}} to force a rebalance after restart, and I got {noformat} 11:24:07,424 TRACE (jgroups-7,Test-NodeD:[]) [ClusterCacheStatus] Cache testCache topology updated: CacheTopology{id=1, phase=NO_REBALANCE, rebalanceId=1, currentCH=DefaultConsistentHash{ns=256, owners = (3)[Test-NodeD: 83+0, Test-NodeE: 87+0, Test-NodeF: 86+0]}, pendingCH=null, unionCH=null, actualMembers=[Test-NodeD, Test-NodeE, Test-NodeF], persistentUUIDs=[1ba71c04-a6b9-4a5c-9f51-e5e358081dc6, 6d3ff549-aafa-4d8a-8617-84ac6f119549, f37f6a8c-32a4-4dda-b1b0-876c24f42c6a]}, members = [Test-NodeD, Test-NodeE, Test-NodeF], joiners = [] 11:24:07,889 TRACE (testng-Test:[]) [ClusterCacheStatus] Rebalancing consistent hash for cache testCache, members are [Test-NodeD, Test-NodeE, Test-NodeF] 11:24:07,909 TRACE (testng-Test:[]) [ClusterCacheStatus] Updating cache testCache topology for rebalance: CacheTopology{id=2, phase=READ_OLD_WRITE_ALL, rebalanceId=2, currentCH=DefaultConsistentHash{ns=256, owners = (3)[Test-NodeD: 83+0, Test-NodeE: 87+0, Test-NodeF: 86+0]}, pendingCH=DefaultConsistentHash{ns=256, owners = (3)[Test-NodeD: 87+0, Test-NodeE: 83+0, Test-NodeF: 86+0]}, unionCH=null, actualMembers=[Test-NodeD, Test-NodeE, Test-NodeF], persistentUUIDs=[1ba71c04-a6b9-4a5c-9f51-e5e358081dc6, 6d3ff549-aafa-4d8a-8617-84ac6f119549, f37f6a8c-32a4-4dda-b1b0-876c24f42c6a]} 11:24:07,910 TRACE (testng-Test:[]) [ClusterCacheStatus] Moved segments: [Test-NodeD added 72 removed 68, Test-NodeE added 49 removed 53, Test-NodeF added 59 removed 59] {noformat} This issue does not affect caches using {{DefaultConsistentHashFactory}}, because it doesn't care about member UUIDs. Since there is no {{SyncScatteredConsistentHashFactory}}, scattered cache are not affected at all. Replicated caches with the default {{SyncReplicateedConsistentHashFactory}} will change primary owners, but they won't need any state transfer. {{TestingUtil.waitForNoRebalance()}} works around the issue by not checking whether the initial consistent hash (with topologyId==1) is balanced. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12342) Add Dependencies Manifest header to Spring artifacts

by Katia Aresti (Jira)

[ https://issues.redhat.com/browse/ISPN-12342?page=com.atlassian.jira.plugi... ] Katia Aresti updated ISPN-12342: -------------------------------- Fix Version/s: 12.0.0.Dev04 > Add Dependencies Manifest header to Spring artifacts > ---------------------------------------------------- > > Key: ISPN-12342 > URL: https://issues.redhat.com/browse/ISPN-12342 > Project: Infinispan > Issue Type: Patch > Components: Spring Integration > Reporter: Philippe Marschall > Priority: Major > Fix For: 12.0.0.Dev04 > > > We deploy a Spring application inside of WildFly. We use the Infinispan Spring integration to access Infinispan from WildFly through the Spring Cache abstraction. > > The Infinispan Spring integration artifacts are part of our deployment but Infinispan is not. The Infinispan Spring integration artifacts instead access the Infinispan modules in WildFly. > > This means that we'll either have to add a Dependencies manifest header to our deployment or use jboss-deployment-structure.xml. If instead the Infinispan Spring integration artifacts had a Dependencies manifest header then that step would be redundant. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12342) Add Dependencies Manifest header to Spring artifacts

by Katia Aresti (Jira)

[ https://issues.redhat.com/browse/ISPN-12342?page=com.atlassian.jira.plugi... ] Katia Aresti updated ISPN-12342: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Add Dependencies Manifest header to Spring artifacts > ---------------------------------------------------- > > Key: ISPN-12342 > URL: https://issues.redhat.com/browse/ISPN-12342 > Project: Infinispan > Issue Type: Patch > Components: Spring Integration > Reporter: Philippe Marschall > Priority: Major > > We deploy a Spring application inside of WildFly. We use the Infinispan Spring integration to access Infinispan from WildFly through the Spring Cache abstraction. > > The Infinispan Spring integration artifacts are part of our deployment but Infinispan is not. The Infinispan Spring integration artifacts instead access the Infinispan modules in WildFly. > > This means that we'll either have to add a Dependencies manifest header to our deployment or use jboss-deployment-structure.xml. If instead the Infinispan Spring integration artifacts had a Dependencies manifest header then that step would be redundant. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 6 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 September 2020