August 2018 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (IPROTO-42) Add Protostream support in the jvm-serializers benchmark

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/IPROTO-42?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated IPROTO-42: -------------------------------- Fix Version/s: 4.3.0.Final > Add Protostream support in the jvm-serializers benchmark > -------------------------------------------------------- > > Key: IPROTO-42 > URL: https://issues.jboss.org/browse/IPROTO-42 > Project: Infinispan ProtoStream > Issue Type: Feature Request > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 4.3.0.Final > > > This is a well-known (but not a 'standard') benchmark comparing performance of various serilization libs that can be used on the JVM: > https://eishay.github.io/jvm-serializers/prototype-results-page/ > Adding Protostream support is a must before continuing any perf improvements. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-47) A new declarative API using entity field bindings with lambdas

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/IPROTO-47?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated IPROTO-47: -------------------------------- Fix Version/s: 4.3.0.Final > A new declarative API using entity field bindings with lambdas > -------------------------------------------------------------- > > Key: IPROTO-47 > URL: https://issues.jboss.org/browse/IPROTO-47 > Project: Infinispan ProtoStream > Issue Type: Feature Request > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 4.3.0.Final > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9437) Provide automatic translation of Hot Rod client properties into Spring YAML

by Katia Aresti (JIRA)

[ https://issues.jboss.org/browse/ISPN-9437?page=com.atlassian.jira.plugin.... ] Katia Aresti updated ISPN-9437: ------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan-spring-boot/pull/56/files > Provide automatic translation of Hot Rod client properties into Spring YAML > --------------------------------------------------------------------------- > > Key: ISPN-9437 > URL: https://issues.jboss.org/browse/ISPN-9437 > Project: Infinispan > Issue Type: Enhancement > Components: Spring Integration > Reporter: Katia Aresti > Assignee: Katia Aresti > > Find description here : https://github.com/infinispan/infinispan-spring-boot/issues/48 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7409) Replace external marshaller with user marshaller

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-7409?page=com.atlassian.jira.plugin.... ] Work on ISPN-7409 started by Ryan Emerson. ------------------------------------------ > Replace external marshaller with user marshaller > ------------------------------------------------ > > Key: ISPN-7409 > URL: https://issues.jboss.org/browse/ISPN-7409 > Project: Infinispan > Issue Type: Enhancement > Components: Core, Marshalling > Reporter: Galder Zamarreño > Assignee: Ryan Emerson > Fix For: 10.0.0.Final > > > ISPN-6906 brings much needed independence from JBoss Marshalling to our marshalling layer. One of the key aspects it brings it’s the separation between marshalling internal types we know about, e.g. String, byte[], CacheTopologyCommand...etc and external or unknown types, e.g. any types that extend Serializable. > Although this separation helps achieve objectives of ISPN-6906, it’s not an ideal solution: > * If user types map directly to primitive types supported by our internal marshaller, or types that depend on types that are marshalled by our internal marshaller, any changes made to the internal marshaller have a direct impact on the representation of the user types. > * In the ISPN-6906 implementation, Internal marshaller exposes its own externalizer table to the external marshaller so that it can lookup how to marshall internal types. This is done to support corner cases in Hibernate Search where some of the classes that Query module marshalls rely on the fact that some Hibernate Search classes are Serializable, but these classes reference Lucene query classes that are not for which there are externalizers defined. For query logic to work, externalizers have to be found while dealing with Serializable types are being traversed. Gustavo and Sane are aware of this issue and we should soon have externalizers for those Hibernate Search classes and avoid this issue altogether (see ISPN-7156). > So, rather than an external marshaller, a more suitable abstraction would be to have a user marshaller. The job of the user marshaller, which would be configurable, would be to marshall user types. The user marshaller should be independent of the internal marshaller, so it would not be able to piggyback on the internal externalizers. > Externalizers for user types could still be supported, by having a user externalizer table, purely used by the user marshaller. In fact, it would make sense that all externalizers that are configured in Infinispan (regardless of whether via xml, programmatic or via annotation) to be user externalizers. > User types are considered to be: > * Keys and values > * Metadata instances provided by the user via *withMetadata() calls > The benefits of the user marshaller are the following: > * Having the user marshaller configurable would make it easy to try out different marshallers when comparing how key/value types are marshalled, e.g. try out different ways to marshall Strings. > * An easier upgrade path for user types. Since user types no longer rely on internal marshaller details, Infinispan upgrades are easier to deal with. > For reference, custom commands that can be plugged via ModuleCommandFactory implementations would use the internal marshaller since these commands often marshall internal types, e.g. Address. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7409) Replace external marshaller with user marshaller

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-7409?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-7409: ------------------------------- Status: Open (was: Pull Request Sent) Git Pull Request: (was: https://github.com/infinispan/infinispan/pull/6150) > Replace external marshaller with user marshaller > ------------------------------------------------ > > Key: ISPN-7409 > URL: https://issues.jboss.org/browse/ISPN-7409 > Project: Infinispan > Issue Type: Enhancement > Components: Core, Marshalling > Reporter: Galder Zamarreño > Assignee: Ryan Emerson > Fix For: 10.0.0.Final > > > ISPN-6906 brings much needed independence from JBoss Marshalling to our marshalling layer. One of the key aspects it brings it’s the separation between marshalling internal types we know about, e.g. String, byte[], CacheTopologyCommand...etc and external or unknown types, e.g. any types that extend Serializable. > Although this separation helps achieve objectives of ISPN-6906, it’s not an ideal solution: > * If user types map directly to primitive types supported by our internal marshaller, or types that depend on types that are marshalled by our internal marshaller, any changes made to the internal marshaller have a direct impact on the representation of the user types. > * In the ISPN-6906 implementation, Internal marshaller exposes its own externalizer table to the external marshaller so that it can lookup how to marshall internal types. This is done to support corner cases in Hibernate Search where some of the classes that Query module marshalls rely on the fact that some Hibernate Search classes are Serializable, but these classes reference Lucene query classes that are not for which there are externalizers defined. For query logic to work, externalizers have to be found while dealing with Serializable types are being traversed. Gustavo and Sane are aware of this issue and we should soon have externalizers for those Hibernate Search classes and avoid this issue altogether (see ISPN-7156). > So, rather than an external marshaller, a more suitable abstraction would be to have a user marshaller. The job of the user marshaller, which would be configurable, would be to marshall user types. The user marshaller should be independent of the internal marshaller, so it would not be able to piggyback on the internal externalizers. > Externalizers for user types could still be supported, by having a user externalizer table, purely used by the user marshaller. In fact, it would make sense that all externalizers that are configured in Infinispan (regardless of whether via xml, programmatic or via annotation) to be user externalizers. > User types are considered to be: > * Keys and values > * Metadata instances provided by the user via *withMetadata() calls > The benefits of the user marshaller are the following: > * Having the user marshaller configurable would make it easy to try out different marshallers when comparing how key/value types are marshalled, e.g. try out different ways to marshall Strings. > * An easier upgrade path for user types. Since user types no longer rely on internal marshaller details, Infinispan upgrades are easier to deal with. > For reference, custom commands that can be plugged via ModuleCommandFactory implementations would use the internal marshaller since these commands often marshall internal types, e.g. Address. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7168) Prevent user from configuring passivation with a shared store

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-7168?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-7168: -------------------------------- Fix Version/s: 9.4.0.CR1 > Prevent user from configuring passivation with a shared store > ------------------------------------------------------------- > > Key: ISPN-7168 > URL: https://issues.jboss.org/browse/ISPN-7168 > Project: Infinispan > Issue Type: Bug > Affects Versions: 8.2.4.Final > Reporter: William Burns > Assignee: William Burns > Fix For: 9.4.0.CR1, 9.4.0.Final > > > Passivation only makes sense with a non shared cache store. --The problem is that if an entry is passivated on a shared cache store only the first node will be able to activate the entry and subsequent nodes will always see null.-- > Looking closer the bigger issue is if an entry becomes passivated and then subsequently written to you will have a different value in the store as you would in memory. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-47) A new declarative API using entity field bindings with lambdas

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/IPROTO-47?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated IPROTO-47: -------------------------------- Sprint: Sprint 9.4.0.CR1 > A new declarative API using entity field bindings with lambdas > -------------------------------------------------------------- > > Key: IPROTO-47 > URL: https://issues.jboss.org/browse/IPROTO-47 > Project: Infinispan ProtoStream > Issue Type: Feature Request > Reporter: Adrian Nistor > Assignee: Adrian Nistor > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-42) Add Protostream support in the jvm-serializers benchmark

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/IPROTO-42?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated IPROTO-42: -------------------------------- Sprint: Sprint 9.4.0.CR1 > Add Protostream support in the jvm-serializers benchmark > -------------------------------------------------------- > > Key: IPROTO-42 > URL: https://issues.jboss.org/browse/IPROTO-42 > Project: Infinispan ProtoStream > Issue Type: Feature Request > Reporter: Adrian Nistor > Assignee: Adrian Nistor > > This is a well-known (but not a 'standard') benchmark comparing performance of various serilization libs that can be used on the JVM: > https://eishay.github.io/jvm-serializers/prototype-results-page/ > Adding Protostream support is a must before continuing any perf improvements. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-73) Integrate checkstyle plugin in build system and enforce the Infinispan coding style

by Adrian Nistor (JIRA)

Adrian Nistor created IPROTO-73: ----------------------------------- Summary: Integrate checkstyle plugin in build system and enforce the Infinispan coding style Key: IPROTO-73 URL: https://issues.jboss.org/browse/IPROTO-73 Project: Infinispan ProtoStream Issue Type: Task Reporter: Adrian Nistor -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-73) Integrate checkstyle plugin in build system and enforce the Infinispan coding style

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/IPROTO-73?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated IPROTO-73: -------------------------------- Status: Open (was: New) > Integrate checkstyle plugin in build system and enforce the Infinispan coding style > ----------------------------------------------------------------------------------- > > Key: IPROTO-73 > URL: https://issues.jboss.org/browse/IPROTO-73 > Project: Infinispan ProtoStream > Issue Type: Task > Reporter: Adrian Nistor > Fix For: 4.3.0.Final > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 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 August 2018