January 2017 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-7412) Expand usage of MarshallUtil for marshalling collections internally

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-7412: -------------------------------------- Summary: Expand usage of MarshallUtil for marshalling collections internally Key: ISPN-7412 URL: https://issues.jboss.org/browse/ISPN-7412 Project: Infinispan Issue Type: Task Components: Core, Marshalling Reporter: Galder Zamarreño Some externalizers might still rely on calling writeObject() when trying to marshall collections. Make sure they use MarshallUtil instead to avoid extra cost. Ideally, this should enable us to get rid of collection based externalizers in our internal externalizer collection. Although this might only achievable once user marshaller is in place (ISPN-7409) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7411) Demonstrate how Infinispan users could version their own data

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-7411: -------------------------------------- Summary: Demonstrate how Infinispan users could version their own data Key: ISPN-7411 URL: https://issues.jboss.org/browse/ISPN-7411 Project: Infinispan Issue Type: Task Components: Demos and Tutorials, Marshalling Reporter: Galder Zamarreño Another problem of our current marshalling architecture is that we don’t provide any help to users to version their own data. So, that means users have to version their own data manually, and often users will remember to do this when the time to do a data upgrade arises. So, we should improve our externalizers to offer easier ways to users to version their data. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7410) Demonstrate Infinispan upgrade experience

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-7410: -------------------------------------- Summary: Demonstrate Infinispan upgrade experience Key: ISPN-7410 URL: https://issues.jboss.org/browse/ISPN-7410 Project: Infinispan Issue Type: Task Components: Demos and Tutorials Reporter: Galder Zamarreño Once ISPN-7409 is implemented and we have internal vs user marshaller separation, upgrading Infinispan version should be easy to achieve since user data would be marshalled independently of Infinispan itself. Create a demo (or preferably integration/unit test) where data stored in persistent store remains accessible as Infinispan versions are upgraded. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5961) Upgrade scala plugin version

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5961?page=com.atlassian.jira.plugin.... ] Tristan Tarrant closed ISPN-5961. --------------------------------- Resolution: Out of Date > Upgrade scala plugin version > ---------------------------- > > Key: ISPN-5961 > URL: https://issues.jboss.org/browse/ISPN-5961 > Project: Infinispan > Issue Type: Enhancement > Reporter: Sebastian Łaskawiec > > This fix is needed for supporting symbolic links in paths: https://github.com/davidB/scala-maven-plugin/commit/0eff8a88b1c26cfab69ce... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 3 months

1
0
0 / 0

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

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-7409: -------------------------------------- Summary: 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 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.2.3#72005)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2133) Provide a context for object de-serialization

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2133?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-2133: ----------------------------------- Component/s: Marshalling > Provide a context for object de-serialization > --------------------------------------------- > > Key: ISPN-2133 > URL: https://issues.jboss.org/browse/ISPN-2133 > Project: Infinispan > Issue Type: Feature Request > Components: Core, Marshalling > Reporter: Sanne Grinovero > Labels: SLOWING_OGM, for_OGM > > See proposal description at > http://lists.jboss.org/pipermail/infinispan-dev/2012-June/010925.html -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7408) Make JBoss Marshalling dependency optional

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-7408?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-7408: ----------------------------------- Component/s: Core Marshalling > Make JBoss Marshalling dependency optional > ------------------------------------------ > > Key: ISPN-7408 > URL: https://issues.jboss.org/browse/ISPN-7408 > Project: Infinispan > Issue Type: Task > Components: Core, Marshalling > Reporter: Galder Zamarreño > > Ever since ISPN-6906 was implemented, users don't need to strictly depend on JBoss Marshalling. If the types marshalled are primitives or custom types for which Infinispan Externalizers have been installed, JBoss Marshalling dependency won't be needed. Hence, JBoss Marshalling dependency should be now optional. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7408) Make JBoss Marshalling dependency optional

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-7408: -------------------------------------- Summary: Make JBoss Marshalling dependency optional Key: ISPN-7408 URL: https://issues.jboss.org/browse/ISPN-7408 Project: Infinispan Issue Type: Task Reporter: Galder Zamarreño Ever since ISPN-6906 was implemented, users don't need to strictly depend on JBoss Marshalling. If the types marshalled are primitives or custom types for which Infinispan Externalizers have been installed, JBoss Marshalling dependency won't be needed. Hence, JBoss Marshalling dependency should be now optional. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5357) Hot Rod protocol 3.0

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5357?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5357: ---------------------------------- Fix Version/s: 9.1.0.Final (was: 9.0.0.Final) > Hot Rod protocol 3.0 > -------------------- > > Key: ISPN-5357 > URL: https://issues.jboss.org/browse/ISPN-5357 > Project: Infinispan > Issue Type: Enhancement > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 9.1.0.Final > > > *UPDATE (6/10/2015)*: Hot Rod 3.0 could become a HTTP REST protocol taking advantage of existing infrastructure to deal with HTTP requests efficiently, and if it was based on HTTP 2.0, we could have binary data inside of it. Performance should be on par. Text mode could be available for debug or demos. This essentially would mean REST and Hot Rod would merge into one. > A binary protocol rethink is needed to take better advantage of CPUs and buffering. This is based on the ideas of Martin Thompson's Simple Binary Encoding [blog post|http://mechanical-sympathy.blogspot.cz/2014/05/simple-binary-encoding.html] > In essence, we need to move Hot Rod protocol towards having mostly fixed size fields, hence getting rid of `vInt` and `vLong` formats which although safe some bytes, they hinder long stream reading patterns. > An optional part here would be whether to consider using SBE directly, but this JIRA should be mostly oriented at making sure we have a protocol that can be read fast and efficiently. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7407) Investigate flow control performance

by Dan Berindei (JIRA)

Dan Berindei created ISPN-7407: ---------------------------------- Summary: Investigate flow control performance Key: ISPN-7407 URL: https://issues.jboss.org/browse/ISPN-7407 Project: Infinispan Issue Type: Task Components: Core Affects Versions: 9.0.0.Beta2 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 9.0.0.CR1 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2017