June 2019 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-9624) Deprecate StreamingMarshaller interface

by Ryan Emerson (Jira)

[ https://issues.jboss.org/browse/ISPN-9624?page=com.atlassian.jira.plugin.... ] Ryan Emerson resolved ISPN-9624. -------------------------------- Resolution: Done > Deprecate StreamingMarshaller interface > --------------------------------------- > > Key: ISPN-9624 > URL: https://issues.jboss.org/browse/ISPN-9624 > Project: Infinispan > Issue Type: Sub-task > Components: Core > Affects Versions: 9.4.0.Final > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 10.0.0.Beta4 > > > The StreamingMarshaller interface is no longer fit for purpose once we move away from jboss-marshalling as the ObjectOutput abstraction does not fit with non-serialization based marshallers. We should provide a simpler interface that simply allows reading/writing objects to a provided stream. This interface should then be exposed via the InitializationContext to store implementations. > {code:java} > @ThreadSafe > public interface StreamAwareMarshaller extends Marshaller { > /** > * Marshall an object to the {@link OutputStream} > * > * @param o the object to write to the {@link OutputStream} > * @param out the {@link OutputStream} to write the object to > * @throws IOException if the object cannot be marshalled to the {@link OutputStream} due to some I/O error > */ > void writeObject(Object o, OutputStream out) throws IOException; > /** > * Unmarshall an object from the {@link InputStream} > * > * @param in the {@link InputStream} to unmarshall an object from > * @return the unmarshalled object instance > * @throws IOException if unmarshalling cannot complete due to some I/O error > * @throws ClassNotFoundException if the class of the object trying to unmarshall is not found > */ > Object readObject(InputStream in) throws ClassNotFoundException, IOException; > } > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 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 resolved ISPN-7409. -------------------------------- Fix Version/s: 10.0.0.Beta4 (was: 10.0.0.Final) Resolution: Done > Replace external marshaller with user marshaller > ------------------------------------------------ > > Key: ISPN-7409 > URL: https://issues.jboss.org/browse/ISPN-7409 > Project: Infinispan > Issue Type: Sub-task > Components: Core, Marshalling > Reporter: Galder Zamarreño > Assignee: Ryan Emerson > Priority: Major > Fix For: 10.0.0.Beta4 > > > 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.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9621) Split global marshaller into Persistence and Internal marshaller

by Ryan Emerson (Jira)

[ https://issues.jboss.org/browse/ISPN-9621?page=com.atlassian.jira.plugin.... ] Ryan Emerson resolved ISPN-9621. -------------------------------- Resolution: Done > Split global marshaller into Persistence and Internal marshaller > ---------------------------------------------------------------- > > Key: ISPN-9621 > URL: https://issues.jboss.org/browse/ISPN-9621 > Project: Infinispan > Issue Type: Sub-task > Components: Core, Loaders and Stores > Affects Versions: 9.4.0.Final > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 10.0.0.Beta4 > > > Currently the internal marshaller is used for marshalling key/value/metadata in store implementations. This means that it is possible for internal classes to be marshalled to a user store, which can cause compatibility issues if an internal classes serialization format changes (due to marshaller changes or addition/removal of fields). > We should separate the internal and persistence marshaller, only exposing the latter to stores via the InitializationContext. The persistence marshaller should only be able to serialize user key/values and the metadata/version data. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10296) Support SKIP_LISTENER_NOTIFICATION in hotrod

by Katia Aresti (Jira)

[ https://issues.jboss.org/browse/ISPN-10296?page=com.atlassian.jira.plugin... ] Katia Aresti updated ISPN-10296: -------------------------------- Status: Open (was: New) > Support SKIP_LISTENER_NOTIFICATION in hotrod > -------------------------------------------- > > Key: ISPN-10296 > URL: https://issues.jboss.org/browse/ISPN-10296 > Project: Infinispan > Issue Type: Enhancement > Components: Hot Rod > Reporter: Katia Aresti > Assignee: Katia Aresti > Priority: Critical > > Implement the flag SKIP_LISTENER_NOTIFICATION in hotrod to be able to tell infinispan not to notify the client using the withFlags() method -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10296) Support SKIP_LISTENER_NOTIFICATION in hotrod

by Katia Aresti (Jira)

[ https://issues.jboss.org/browse/ISPN-10296?page=com.atlassian.jira.plugin... ] Work on ISPN-10296 started by Katia Aresti. ------------------------------------------- > Support SKIP_LISTENER_NOTIFICATION in hotrod > -------------------------------------------- > > Key: ISPN-10296 > URL: https://issues.jboss.org/browse/ISPN-10296 > Project: Infinispan > Issue Type: Enhancement > Components: Hot Rod > Reporter: Katia Aresti > Assignee: Katia Aresti > Priority: Critical > > Implement the flag SKIP_LISTENER_NOTIFICATION in hotrod to be able to tell infinispan not to notify the client using the withFlags() method -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10296) Support SKIP_LISTENER_NOTIFICATION in hotrod

by Katia Aresti (Jira)

[ https://issues.jboss.org/browse/ISPN-10296?page=com.atlassian.jira.plugin... ] Katia Aresti updated ISPN-10296: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/7031, https://github.com/infinispan/infinispan/pull/7032 > Support SKIP_LISTENER_NOTIFICATION in hotrod > -------------------------------------------- > > Key: ISPN-10296 > URL: https://issues.jboss.org/browse/ISPN-10296 > Project: Infinispan > Issue Type: Enhancement > Components: Hot Rod > Reporter: Katia Aresti > Assignee: Katia Aresti > Priority: Critical > > Implement the flag SKIP_LISTENER_NOTIFICATION in hotrod to be able to tell infinispan not to notify the client using the withFlags() method -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10296) Support SKIP_LISTENER_NOTIFICATION in hotrod

by Katia Aresti (Jira)

Katia Aresti created ISPN-10296: ----------------------------------- Summary: Support SKIP_LISTENER_NOTIFICATION in hotrod Key: ISPN-10296 URL: https://issues.jboss.org/browse/ISPN-10296 Project: Infinispan Issue Type: Enhancement Components: Hot Rod Reporter: Katia Aresti Implement the flag SKIP_LISTENER_NOTIFICATION in hotrod to be able to tell infinispan not to notify the client using the withFlags() method -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10296) Support SKIP_LISTENER_NOTIFICATION in hotrod

by Katia Aresti (Jira)

[ https://issues.jboss.org/browse/ISPN-10296?page=com.atlassian.jira.plugin... ] Katia Aresti reassigned ISPN-10296: ----------------------------------- Assignee: Katia Aresti > Support SKIP_LISTENER_NOTIFICATION in hotrod > -------------------------------------------- > > Key: ISPN-10296 > URL: https://issues.jboss.org/browse/ISPN-10296 > Project: Infinispan > Issue Type: Enhancement > Components: Hot Rod > Reporter: Katia Aresti > Assignee: Katia Aresti > Priority: Critical > > Implement the flag SKIP_LISTENER_NOTIFICATION in hotrod to be able to tell infinispan not to notify the client using the withFlags() method -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10295) Upgrade to JGroups 4.0.20.Final

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-10295?page=com.atlassian.jira.plugin... ] Dan Berindei updated ISPN-10295: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/7030 > Upgrade to JGroups 4.0.20.Final > ------------------------------- > > Key: ISPN-10295 > URL: https://issues.jboss.org/browse/ISPN-10295 > Project: Infinispan > Issue Type: Component Upgrade > Components: Dependency > Affects Versions: 9.4.14.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 9.4.15.Final > > > Includes fixes for JGRP-2350 (TCP: connection close can block when send() block on full TCP send-window) and for JGRP-2354 (ForkChannel does not receive SITE_UNREACHABLE events). -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10291) Upgrade to JGroups 4.1.1.Final

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-10291?page=com.atlassian.jira.plugin... ] Dan Berindei updated ISPN-10291: -------------------------------- Fix Version/s: (was: 9.4.15.Final) > Upgrade to JGroups 4.1.1.Final > ------------------------------ > > Key: ISPN-10291 > URL: https://issues.jboss.org/browse/ISPN-10291 > Project: Infinispan > Issue Type: Component Upgrade > Components: Dependency > Affects Versions: 10.0.0.Beta3, 9.4.14.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Beta4 > > > JGroups 4.1.0.Final has several improvements for running under Quarkus, plus should be better at using the same kind of IP address everywhere when not running with {{-Djava.net.preferIPv4Stack=true}}: > http://belaban.blogspot.com/2019/05/410-released.html > 4.1.1.Final adds a fix for JGRP-2350 (TCP: connection close can block when send() block on full TCP send-window) and for JGRP-2354 (ForkChannel does not receive SITE_UNREACHABLE events) -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2019