December 2020 - infinispan-issues

[Red Hat JIRA] (ISPN-11398) Change XSiteStateTransferProviderImpl to be non blocking

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-11398?page=com.atlassian.jira.plugi... ] Pedro Ruivo updated ISPN-11398: ------------------------------- Status: Pull Request Sent (was: Coding In Progress) > Change XSiteStateTransferProviderImpl to be non blocking > -------------------------------------------------------- > > Key: ISPN-11398 > URL: https://issues.redhat.com/browse/ISPN-11398 > Project: Infinispan > Issue Type: Bug > Components: Core, Cross-Site Replication > Reporter: Will Burns > Assignee: Pedro Ruivo > Priority: Major > > When sending state xsite the transfer blocks at https://github.com/infinispan/infinispan/blob/d3093ed6ccbe2553a3dbde1d0d6... and a few other places. > For now I have offloaded this to the blocking thread pool, but this should be fixed to be totally non blocking. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[Red Hat JIRA] (ISPN-12582) CLI aliases are not persistent

by Ryan Emerson (Jira)

[ https://issues.redhat.com/browse/ISPN-12582?page=com.atlassian.jira.plugi... ] Ryan Emerson resolved ISPN-12582. --------------------------------- Resolution: Done > CLI aliases are not persistent > ------------------------------ > > Key: ISPN-12582 > URL: https://issues.redhat.com/browse/ISPN-12582 > Project: Infinispan > Issue Type: Bug > Reporter: Wolf-Dieter Fink > Assignee: Tristan Tarrant > Priority: Major > Fix For: 12.0.0.CR1 > > > alias command in CLI is to set shortcuts > like > alias co=connect > so far it works, but I assume that it should be stored in .config/infinispan/aliases which not happen > also set something in aliases files and start CLI will not work -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[Red Hat JIRA] (ISPN-11426) Add UUID to core SerializationContexts

by Will Burns (Jira)

[ https://issues.redhat.com/browse/ISPN-11426?page=com.atlassian.jira.plugi... ] Will Burns updated ISPN-11426: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Add UUID to core SerializationContexts > -------------------------------------- > > Key: ISPN-11426 > URL: https://issues.redhat.com/browse/ISPN-11426 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 10.1.3.Final, 11.0.0.Alpha2 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 12.0.0.Final > > > Currently we only register a ProtoStream marshaller for java.util.UUID in the server as they are required for the event logger, however this will also be required by core for `MultiClusterEventCommand` and `ClusterEvent`. It's not possible to register a class in multiple contexts when utilising a TypeId, therefore in order to avoid having to provide a TypeId for UUIDs in both core and server, we should register this in the core's persistence initializers. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[Red Hat JIRA] (ISPN-11614) PersistenceMarshaller should utilise an independent SerializationContext for user types

by Will Burns (Jira)

[ https://issues.redhat.com/browse/ISPN-11614?page=com.atlassian.jira.plugi... ] Will Burns updated ISPN-11614: ------------------------------ Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/8827 > PersistenceMarshaller should utilise an independent SerializationContext for user types > --------------------------------------------------------------------------------------- > > Key: ISPN-11614 > URL: https://issues.redhat.com/browse/ISPN-11614 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 10.1.5.Final, 11.0.0.Dev03 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > > If a user configures a SerializationContextInitializer it is currently registered to the same SerializationContext as the persistent internal types. This means that it is possible for a user to reference internal protobuf message types in their .proto files. > We should introduce the following: > # A "user" SerializationContext that is used exclusively for user types configured via xml/service-loader/programmatically: > User types are only registered with this context. The global and persistence contexts do not register these types. If a type does not exist in the global/persistence context, then it's wrapped with a MarshallableUserObject and marshalling is delegated to the user marshaller. Previously this only occurred if a custom marshaller was defined as user types were added to the global/persistence context, but as this is no longer the case all user types are wrapped. > # A USER_MARSHALLER created by MarshallerFactory, which if a custom marshaller is not defined creates a ProtoStream based marshaller that consumes the user SerializationContext, if a custom marshaller is defined then that is returned: > This logic was previously in the PersistenceMarshallerImpl, but this allows us to inject the marshaller directly into various places in the code. > # DelegatingUserMarshaller. A wrapper class to call the start/stop of the configured user marshaller and log the marshaller being used. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[Red Hat JIRA] (ISPN-12093) Service loaded SCIs not registered with the SerializationContextRegistry

by Will Burns (Jira)

[ https://issues.redhat.com/browse/ISPN-12093?page=com.atlassian.jira.plugi... ] Will Burns updated ISPN-12093: ------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: 12.0.0.CR1 (was: 12.0.0.Final) Resolution: Done > Service loaded SCIs not registered with the SerializationContextRegistry > ------------------------------------------------------------------------ > > Key: ISPN-12093 > URL: https://issues.redhat.com/browse/ISPN-12093 > Project: Infinispan > Issue Type: Bug > Components: Configuration, Remote Querying > Affects Versions: 11.0.1.Final > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 12.0.0.CR1 > > > The {{ProtobufMetadataManagerImpl}} loads SerializationContextInitializer implementations via the service loader, however they are currently only registered with the query SerializationContext. Consequently, if a user utilises the service loader to automatically register there SCI the classes won't be marshallable by the GlobalMarshaller or the persistence marshaller. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[Red Hat JIRA] (ISPN-11614) PersistenceMarshaller should utilise an independent SerializationContext for user types

by Will Burns (Jira)

[ https://issues.redhat.com/browse/ISPN-11614?page=com.atlassian.jira.plugi... ] Will Burns updated ISPN-11614: ------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: 12.0.0.CR1 Resolution: Done > PersistenceMarshaller should utilise an independent SerializationContext for user types > --------------------------------------------------------------------------------------- > > Key: ISPN-11614 > URL: https://issues.redhat.com/browse/ISPN-11614 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 10.1.5.Final, 11.0.0.Dev03 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 12.0.0.CR1 > > > If a user configures a SerializationContextInitializer it is currently registered to the same SerializationContext as the persistent internal types. This means that it is possible for a user to reference internal protobuf message types in their .proto files. > We should introduce the following: > # A "user" SerializationContext that is used exclusively for user types configured via xml/service-loader/programmatically: > User types are only registered with this context. The global and persistence contexts do not register these types. If a type does not exist in the global/persistence context, then it's wrapped with a MarshallableUserObject and marshalling is delegated to the user marshaller. Previously this only occurred if a custom marshaller was defined as user types were added to the global/persistence context, but as this is no longer the case all user types are wrapped. > # A USER_MARSHALLER created by MarshallerFactory, which if a custom marshaller is not defined creates a ProtoStream based marshaller that consumes the user SerializationContext, if a custom marshaller is defined then that is returned: > This logic was previously in the PersistenceMarshallerImpl, but this allows us to inject the marshaller directly into various places in the code. > # DelegatingUserMarshaller. A wrapper class to call the start/stop of the configured user marshaller and log the marshaller being used. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[Red Hat JIRA] (ISPN-12579) Able to choose operator documentation version at the site

by Dmitry Volodin (Jira)

[ https://issues.redhat.com/browse/ISPN-12579?page=com.atlassian.jira.plugi... ] Dmitry Volodin updated ISPN-12579: ---------------------------------- Summary: Able to choose operator documentation version at the site (was: Able to choose operator version documentation at the site) > Able to choose operator documentation version at the site > --------------------------------------------------------- > > Key: ISPN-12579 > URL: https://issues.redhat.com/browse/ISPN-12579 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation, Operator, Website > Reporter: Dmitry Volodin > Assignee: Dmitry Volodin > Priority: Minor > > Number of Infinispan operator release become countable. It would be nice to choose version at the site documentation > Also mapping between operator version and Infinispan server version would be prefer to publish in the documentation -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[Red Hat JIRA] (ISPN-12579) Able to choose operator version documentation at the site

by Dmitry Volodin (Jira)

[ https://issues.redhat.com/browse/ISPN-12579?page=com.atlassian.jira.plugi... ] Dmitry Volodin reassigned ISPN-12579: ------------------------------------- Assignee: Dmitry Volodin (was: Donald Naro) > Able to choose operator version documentation at the site > --------------------------------------------------------- > > Key: ISPN-12579 > URL: https://issues.redhat.com/browse/ISPN-12579 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation, Operator, Website > Reporter: Dmitry Volodin > Assignee: Dmitry Volodin > Priority: Minor > > Number of Infinispan operator release become countable. It would be nice to choose version at the site documentation > Also mapping between operator version and Infinispan server version would be prefer to publish in the documentation -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[Red Hat JIRA] (ISPN-12561) CacheV2ResourceTest does not close RestClient responses

by Will Burns (Jira)

[ https://issues.redhat.com/browse/ISPN-12561?page=com.atlassian.jira.plugi... ] Will Burns updated ISPN-12561: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > CacheV2ResourceTest does not close RestClient responses > ------------------------------------------------------- > > Key: ISPN-12561 > URL: https://issues.redhat.com/browse/ISPN-12561 > Project: Infinispan > Issue Type: Bug > Components: REST, Test Suite > Affects Versions: 12.0.0.Dev07 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Minor > Fix For: 12.0.0.CR1 > > > {{RestClient}} needs responses with bodies to be closed, either explicitly, or implicitly by reading the entire body. {{CacheV2ResourceTest}} checks only the HTTP status for most responses, without reading the body. > OkHttpClient logs a WARN message when a response is not closed. If debug logging is enabled for {{okhttp3.OkHttpClient}}, the message includes a stack trace: > {noformat} > 10:22:36,569 WARN (OkHttp ConnectionPool) [OkHttpClient] A connection to https://localhost:43483/ was leaked. Did you forget to close a response body? > java.lang.Throwable: response.body().close() > at okhttp3.internal.platform.Platform.getStackTraceForCloseable(Platform.java:149) > at okhttp3.internal.connection.Transmitter.callStart(Transmitter.java:116) > at okhttp3.RealCall.enqueue(RealCall.java:92) > at org.infinispan.client.rest.impl.okhttp.RestClientOkHttp.execute(RestClientOkHttp.java:248) > at org.infinispan.client.rest.impl.okhttp.RestCacheClientOkHttp.post(RestCacheClientOkHttp.java:94) > at org.infinispan.rest.resources.CacheV2ResourceTest.testCacheV2KeyOps(CacheV2ResourceTest.java:142) > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[Red Hat JIRA] (ISPN-12582) CLI aliases are not persistent

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12582?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12582: ----------------------------------- Status: Open (was: New) > CLI aliases are not persistent > ------------------------------ > > Key: ISPN-12582 > URL: https://issues.redhat.com/browse/ISPN-12582 > Project: Infinispan > Issue Type: Bug > Reporter: Wolf-Dieter Fink > Priority: Major > > alias command in CLI is to set shortcuts > like > alias co=connect > so far it works, but I assume that it should be stored in .config/infinispan/aliases which not happen > also set something in aliases files and start CLI will not work -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues December 2020