December 2020 - infinispan-issues

[Red Hat JIRA] (ISPN-12518) Possible deadlock if an entry is replaced at the same time expiration take effect

by Will Burns (Jira)

[ https://issues.redhat.com/browse/ISPN-12518?page=com.atlassian.jira.plugi... ] Will Burns updated ISPN-12518: ------------------------------ Fix Version/s: 11.0.9.Final > Possible deadlock if an entry is replaced at the same time expiration take effect > --------------------------------------------------------------------------------- > > Key: ISPN-12518 > URL: https://issues.redhat.com/browse/ISPN-12518 > Project: Infinispan > Issue Type: Bug > Affects Versions: 12.0.0.Dev06 > Reporter: Wolf-Dieter Fink > Assignee: Will Burns > Priority: Major > Fix For: 12.0.0.CR1, 11.0.9.Final > > Attachments: reproducer.zip > > > When replacing a value for key, close to the keys expiration time, Infinispan can lock itself where both nodes are waiting for each other, resulting in ISPN000427, instead of the command completing with success (expected) or failure (not expected because it should be replaced) > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[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)

5 years, 3 months

1
0
0 / 0

[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: ------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/8940 (was: https://github.com/infinispan/infinispan/pull/7952) > 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)

5 years, 3 months

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)

5 years, 3 months

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)

5 years, 3 months

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)

5 years, 3 months

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)

5 years, 3 months

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)

5 years, 3 months

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)

5 years, 3 months

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)

5 years, 3 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 December 2020