January 2021 - infinispan-issues - Jboss List Archives

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

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12350?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12350: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > 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: 12.0.0.Dev03, 11.0.3.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 12.1.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 (v8.13.1#813001)

4 years, 11 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-11911) Support iterator for RemoteQueries

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11911?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11911: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > Support iterator for RemoteQueries > ---------------------------------- > > Key: ISPN-11911 > URL: https://issues.redhat.com/browse/ISPN-11911 > Project: Infinispan > Issue Type: Feature Request > Affects Versions: 11.0.0.CR1 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > Labels: SearchNG > Fix For: 12.1.0.Final > > > Query introduced an iterator in ISPN 11 when CacheQuery was deprecated, but it currently does not work for RemoteQueries, which contains a client-side only implementation -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 11 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12282) Documentation to read/write primitives to REST

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12282?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12282: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > Documentation to read/write primitives to REST > ---------------------------------------------- > > Key: ISPN-12282 > URL: https://issues.redhat.com/browse/ISPN-12282 > Project: Infinispan > Issue Type: Enhancement > Components: REST > Affects Versions: 12.0.0.Dev02 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > Fix For: 12.1.0.Final > > > Document how to read/write primitives via REST. > E.g.: > Send an integer literal with > Content-type: application/x-java-object;type=java.lang.Integer > or a JSON with type > {"_type": "int32","_value": 123} -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 11 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12324) WildFly OpenSSL 2.1.0.Final

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12324?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12324: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > WildFly OpenSSL 2.1.0.Final > --------------------------- > > Key: ISPN-12324 > URL: https://issues.redhat.com/browse/ISPN-12324 > Project: Infinispan > Issue Type: Component Upgrade > Components: Build > Affects Versions: 12.0.0.Dev03 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 12.1.0.Final > > > This enables TLS 1.3 -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 11 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-11965) Assume default format for server caches

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11965?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11965: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > Assume default format for server caches > --------------------------------------- > > Key: ISPN-11965 > URL: https://issues.redhat.com/browse/ISPN-11965 > Project: Infinispan > Issue Type: Bug > Components: Core, Server > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > Fix For: 12.1.0.Final > > > Caches that does not specify any MediaType are assumed to have an special media type APPLICATION_UNKNOW that uses the configured marshaller in the server. Embedded caches are already assuming to have application/x-java-object encoding, and since the HR client uses protostream by default, server caches should also use it. The side effect is clients using anything else other than protostream would need to specifically configure the marshalled format in the server. > The alternative is to assume application/octet-stream for server caches -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 11 months

1
0
0 / 0

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

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11969?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11969: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 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.1.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 (v8.13.1#813001)

4 years, 11 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-11878) Embedded configuration builders should automatically be enabled when attributes configured

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11878?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11878: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > Embedded configuration builders should automatically be enabled when attributes configured > ------------------------------------------------------------------------------------------ > > Key: ISPN-11878 > URL: https://issues.redhat.com/browse/ISPN-11878 > Project: Infinispan > Issue Type: Enhancement > Components: Configuration > Affects Versions: 11.0.0.Dev05 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 12.1.0.Final > > > Currently it's neccessary for a user to do the following to configure the global state, as well serveral other configuration elements: > {{globalBuilder.globalState().enable().persistentLocation(location)}} > However the configuration of {{persistentLocation}} should be sufficient to enable the global state, i.e. the following should result in enabled(true) being called: > {{globalBuilder.globalState().persistentLocation(location);}} -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 11 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-11978) Java ScriptEngine

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11978?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11978: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > Java ScriptEngine > ----------------- > > Key: ISPN-11978 > URL: https://issues.redhat.com/browse/ISPN-11978 > Project: Infinispan > Issue Type: Enhancement > Components: Tasks > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 12.1.0.Final > > > Since Java 11 the Nashorn script engine has been deprecated and marked for removal. > We can use either the Java compiler API or JShell to implement a ScriptEngine for Java. -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 11 months

1
0
0 / 0

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

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12351?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12351: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > 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.1.0.Final > > > 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 (v8.13.1#813001)

4 years, 11 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-11966) Deprecate application/x-java-object in the REST API

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11966?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11966: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > Deprecate application/x-java-object in the REST API > --------------------------------------------------- > > Key: ISPN-11966 > URL: https://issues.redhat.com/browse/ISPN-11966 > Project: Infinispan > Issue Type: Task > Components: REST > Affects Versions: 11.0.0.CR1 > Reporter: Dan Berindei > Assignee: Gustavo Fernandes > Priority: Major > Fix For: 12.1.0.Final > > > The REST server supports request header {{Key-Content-Type}}, which changes the meaning of the key in the request URI to be encoded in different media types. > One of the supported media types is {{application/x-java-object}}, which parses Java primitives as if they were Java literals, with special handling for {{String}} and {{byte[]}}. The parsing rules are ad-hoc and undocumented, so I suggest we stop supporting them. > Users who want a readable URI should instead use write the key as JSON and rely on the server to transcode between JSON and the cache storage media type. -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 11 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