June 2020 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-11671) Start a State transfert

by Katia Aresti (Jira)

[ https://issues.redhat.com/browse/ISPN-11671?page=com.atlassian.jira.plugi... ] Work on ISPN-11671 started by Katia Aresti. ------------------------------------------- > Start a State transfert > ------------------------ > > Key: ISPN-11671 > URL: https://issues.redhat.com/browse/ISPN-11671 > Project: Infinispan > Issue Type: Enhancement > Components: Console > Affects Versions: 10.1.6.Final > Reporter: Katia Aresti > Assignee: Katia Aresti > Priority: Major > Labels: console-ng > > Add a state transfert button in the list of sites > https://marvelapp.com/620b19g/screen/68148086 > Ask for confirmation > https://marvelapp.com/620b19g/screen/68148087 > Display the status > https://marvelapp.com/620b19g/screen/68148088 > When the transfert is over, display the result > Ok https://marvelapp.com/620b19g/screen/68148090 > Error https://marvelapp.com/620b19g/screen/68148092 > The state transfert can't be launched again if we don't clear the state transfert result -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11671) Start a State transfert

by Katia Aresti (Jira)

[ https://issues.redhat.com/browse/ISPN-11671?page=com.atlassian.jira.plugi... ] Katia Aresti updated ISPN-11671: -------------------------------- Status: Open (was: New) > Start a State transfert > ------------------------ > > Key: ISPN-11671 > URL: https://issues.redhat.com/browse/ISPN-11671 > Project: Infinispan > Issue Type: Enhancement > Components: Console > Affects Versions: 10.1.6.Final > Reporter: Katia Aresti > Assignee: Katia Aresti > Priority: Major > Labels: console-ng > > Add a state transfert button in the list of sites > https://marvelapp.com/620b19g/screen/68148086 > Ask for confirmation > https://marvelapp.com/620b19g/screen/68148087 > Display the status > https://marvelapp.com/620b19g/screen/68148088 > When the transfert is over, display the result > Ok https://marvelapp.com/620b19g/screen/68148090 > Error https://marvelapp.com/620b19g/screen/68148092 > The state transfert can't be launched again if we don't clear the state transfert result -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11669) Display Cross Site Replication Sites for a Cache

by Katia Aresti (Jira)

[ https://issues.redhat.com/browse/ISPN-11669?page=com.atlassian.jira.plugi... ] Katia Aresti updated ISPN-11669: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan-console/pull/52 > Display Cross Site Replication Sites for a Cache > ------------------------------------------------ > > Key: ISPN-11669 > URL: https://issues.redhat.com/browse/ISPN-11669 > Project: Infinispan > Issue Type: Enhancement > Components: Console > Affects Versions: 10.1.6.Final > Reporter: Katia Aresti > Assignee: Katia Aresti > Priority: Major > Labels: console-ng > > Display the number of backups in the header of a cache that has remote backups > Add a link to manage those backups > https://marvelapp.com/620b19g/screen/68148080 > The link lands into a new page to manage those backups > The data displayed in a list > * Site name > * Status > https://marvelapp.com/620b19g/screen/68148081 -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11669) Display Cross Site Replication Sites for a Cache

by Katia Aresti (Jira)

[ https://issues.redhat.com/browse/ISPN-11669?page=com.atlassian.jira.plugi... ] Katia Aresti updated ISPN-11669: -------------------------------- Status: Open (was: New) > Display Cross Site Replication Sites for a Cache > ------------------------------------------------ > > Key: ISPN-11669 > URL: https://issues.redhat.com/browse/ISPN-11669 > Project: Infinispan > Issue Type: Enhancement > Components: Console > Affects Versions: 10.1.6.Final > Reporter: Katia Aresti > Assignee: Katia Aresti > Priority: Major > Labels: console-ng > > Display the number of backups in the header of a cache that has remote backups > Add a link to manage those backups > https://marvelapp.com/620b19g/screen/68148080 > The link lands into a new page to manage those backups > The data displayed in a list > * Site name > * Status > https://marvelapp.com/620b19g/screen/68148081 -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11975) RemoteCacheImpl entry retrieval should be non blocking

by Will Burns (Jira)

[ https://issues.redhat.com/browse/ISPN-11975?page=com.atlassian.jira.plugi... ] Will Burns updated ISPN-11975: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/8438 > RemoteCacheImpl entry retrieval should be non blocking > ------------------------------------------------------ > > Key: ISPN-11975 > URL: https://issues.redhat.com/browse/ISPN-11975 > Project: Infinispan > Issue Type: Enhancement > Components: Hot Rod > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 12.0.0.Final > > > The RemoteCacheImpl class currently employs blocking while performing entry retrieval. We should able to change this to be fully non blocking, be server segment aware and perform retrieval in parallel across all needed servers. > We will have to add rxjava and reactive streams to the list of dependencies unfortunately, but is well worth it. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11975) RemoteCacheImpl entry retrieval should be non blocking

by Will Burns (Jira)

[ https://issues.redhat.com/browse/ISPN-11975?page=com.atlassian.jira.plugi... ] Will Burns updated ISPN-11975: ------------------------------ Status: Open (was: New) > RemoteCacheImpl entry retrieval should be non blocking > ------------------------------------------------------ > > Key: ISPN-11975 > URL: https://issues.redhat.com/browse/ISPN-11975 > Project: Infinispan > Issue Type: Enhancement > Components: Hot Rod > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 12.0.0.Final > > > The RemoteCacheImpl class currently employs blocking while performing entry retrieval. We should able to change this to be fully non blocking, be server segment aware and perform retrieval in parallel across all needed servers. > We will have to add rxjava and reactive streams to the list of dependencies unfortunately, but is well worth it. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11975) RemoteCacheImpl entry retrieval should be non blocking

by Will Burns (Jira)

Will Burns created ISPN-11975: --------------------------------- Summary: RemoteCacheImpl entry retrieval should be non blocking Key: ISPN-11975 URL: https://issues.redhat.com/browse/ISPN-11975 Project: Infinispan Issue Type: Enhancement Components: Hot Rod Reporter: Will Burns Assignee: Will Burns Fix For: 12.0.0.Final The RemoteCacheImpl class currently employs blocking while performing entry retrieval. We should able to change this to be fully non blocking, be server segment aware and perform retrieval in parallel across all needed servers. We will have to add rxjava and reactive streams to the list of dependencies unfortunately, but is well worth it. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11969) Find a replacement for the Key-Content-Type REST request header

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-11969?page=com.atlassian.jira.plugi... ] Dan Berindei updated ISPN-11969: -------------------------------- Component/s: REST Fix Version/s: 12.0.0.Final > Find a replacement for the Key-Content-Type REST request header > --------------------------------------------------------------- > > Key: ISPN-11969 > URL: https://issues.redhat.com/browse/ISPN-11969 > Project: Infinispan > Issue Type: Task > Components: REST > Reporter: Dan Berindei > Priority: Major > Fix For: 12.0.0.Final > > > A REST URI should uniquely identify a resource. > But in our server, the {{Key-Content-Type}} request header changes the way the URI is mapped to a cache key, > so a single URI could be seen by the server as multiple different cache entries. > The simplest solution would be to extend the URI of cache entries with a query parameter, e.g. {{/rest/v2/caches/<cache>/<key>?key-content-type=<media-type>}}. > I have 2 small concerns with this solution: > 1. When doing a POST request, browsers will put all the parameters in the request body instead of the location. > I don't expect us to have browsers acting as clients, and the search request already does this, but something to keep in mind. > 2. Although resource URIs can be anything, they are usually thought to include only the path part of the URL. > Everybody knows query parameters affect `GET` requests, but the difference between > `DELETE /rest/v2/caches/<cache>/<key>` and > `DELETE /rest/v2/caches/<cache>/<key>?key-content-type=application/octet-stream` > might be surprising to some. > I would prefer to put the key media type in the path of the URI, > e.g. {{/rest/v2/caches/<cache>/<key-content-type>/<key>}}. > It also has a problem: it makes it look like encodings create separate namespaces, > but they actually overlap, and the same logical "cache entry resource" can be accessed > with multiple key content types. > So perhaps we should instead say the {{/rest/v2/caches/<cache>/<key>}} resources are always {{text/plain;charset=UTF-8}} keys, > and for any other content type the client should use a different resource, {{/rest/v2/caches/<cache>/entry/}} > (the extra {{/}} may or may not be required to avoid clashing with regular keys). > The {{/rest/v2/caches/<cache>/entry/}} resource would have {{key}} and {{key-content-type}} parameters > that could be sent either in a `GET` query string or in a `POST` body. > Note: Some key content types will have additional parameters to tell the server how to decode them, e.g. {{application/x-java-object;type=java.long.Double}}, or {{application/octet-stream;encoding=hex}}. > I have created ISPN-11966 to deprecate the {{application/x-java-object}} handling, and ISPN-11968 to deprecate the {{encoding}} parameter in {{application/octet-stream}}. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11879) client-id for LoginResource

by Katia Aresti (Jira)

[ https://issues.redhat.com/browse/ISPN-11879?page=com.atlassian.jira.plugi... ] Katia Aresti updated ISPN-11879: -------------------------------- Fix Version/s: 11.0.0.Final > client-id for LoginResource > --------------------------- > > Key: ISPN-11879 > URL: https://issues.redhat.com/browse/ISPN-11879 > Project: Infinispan > Issue Type: Enhancement > Components: Security > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 11.0.0.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11879) client-id for LoginResource

by Katia Aresti (Jira)

[ https://issues.redhat.com/browse/ISPN-11879?page=com.atlassian.jira.plugi... ] Katia Aresti updated ISPN-11879: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > client-id for LoginResource > --------------------------- > > Key: ISPN-11879 > URL: https://issues.redhat.com/browse/ISPN-11879 > Project: Infinispan > Issue Type: Enhancement > Components: Security > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 12 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2020