October 2018 - infinispan-issues - Jboss List Archives

[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: ------------------------------- Parent: ISPN-9620 Issue Type: Sub-task (was: Enhancement) > 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.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.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9620) Rolling Upgrade Marshaller Changes

by Ryan Emerson (Jira)

Ryan Emerson created ISPN-9620: ---------------------------------- Summary: Rolling Upgrade Marshaller Changes Key: ISPN-9620 URL: https://issues.jboss.org/browse/ISPN-9620 Project: Infinispan Issue Type: Enhancement Components: Core, Loaders and Stores Affects Versions: 9.4.0.Final Reporter: Ryan Emerson Assignee: Ryan Emerson Fix For: 10.0.0.Alpha1 In order to allow for compatibility between infinispan versions it is necessary for us to utilise a marshalling implementation at both the cluster (internal node-to-node communication) and persistence layer that is strictly defined but allows for future changes. This is necessary in order to facilitate both rolling and start/stop upgrades. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8535) Rest API redesign

by Gustavo Fernandes (Jira)

[ https://issues.jboss.org/browse/ISPN-8535?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes commented on ISPN-8535: ----------------------------------------- The REST endpoint should expose the cache manager as a resource, as opposed as being tied to a single one like it is currently > Rest API redesign > ----------------- > > Key: ISPN-8535 > URL: https://issues.jboss.org/browse/ISPN-8535 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Affects Versions: 9.2.0.Final > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > Fix For: 10.0.0.Final > > > Infinispan REST API deals with only one resource, (the cache) and maps all operations on the cache using HTTP verbs and request parameters. The API assumes the URI is related to the cache making it hard to add new kinds of resources without causing ambiguous references. > Since we now have other types of entities, such as counters, scripts, templates, etc, and each one of them can involve different operations, we should make the API more "Restful" by using more than one resource and collections of resources, plus HTTP verbs and operations on them. Examples: > * Create a cache: POST /rest/caches > * Delete a cache: DELETE /rest/caches/myCache > * Create a template: POST /rest/templates > * Delete a template: DELETE /rest/templates/myTemplate > * Create an entry: POST /rest/caches/myCache/1 > * Create a counter: POST /rest/counters > * Get a counter value: GET /rest/counters/mycounter > * Increment a counter: GET /rest/counters/mycounter?action=increment > * Search a cache: GET /rest/caches/myCache?action=search > * Create a script: POST /rest/scripts/ > * Get a script source: GET /rest/scritps/myScript > * Execute a script: GET /rest/scripts/myScript?action=execute&param1=foo > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9618) Overlay for Java 10 could be Java 9

by tommaso borgato (Jira)

[ https://issues.jboss.org/browse/ISPN-9618?page=com.atlassian.jira.plugin.... ] tommaso borgato updated ISPN-9618: ---------------------------------- Description: The following classes are in overlay for Java 10: - commons/src/main/java10/org/infinispan/commons/jdkspecific/CallerId.java - commons/src/main/java10/org/infinispan/commons/jdkspecific/ProcessorInfo.java CallerId uses StackWalker that is available since Java 9. ProcessorInfo uses Runtime.getRuntime().availableProcessors() that was fixed in java 9 (https://bugs.java.com/view_bug.do?bug_id=6515172) Question: can those classes be in overlay for Java 9 instead of Java 10 ? was: The following classes are in overlay for Java 10: commons/src/main/java10/org/infinispan/commons/jdkspecific/CallerId.java commons/src/main/java10/org/infinispan/commons/jdkspecific/ProcessorInfo.java CallerId uses StackWalker that is available since Java 9. ProcessorInfo uses Runtime.getRuntime().availableProcessors() that was fixed in java 9 (https://bugs.java.com/view_bug.do?bug_id=6515172) Question: can those classes be in overlay for Java 9 instead of Java 10 ? > Overlay for Java 10 could be Java 9 > ----------------------------------- > > Key: ISPN-9618 > URL: https://issues.jboss.org/browse/ISPN-9618 > Project: Infinispan > Issue Type: Bug > Components: Build > Affects Versions: 9.4.0.Final > Reporter: tommaso borgato > Priority: Major > > The following classes are in overlay for Java 10: > - commons/src/main/java10/org/infinispan/commons/jdkspecific/CallerId.java > - commons/src/main/java10/org/infinispan/commons/jdkspecific/ProcessorInfo.java > CallerId uses StackWalker that is available since Java 9. > ProcessorInfo uses Runtime.getRuntime().availableProcessors() that was fixed in java 9 (https://bugs.java.com/view_bug.do?bug_id=6515172) > Question: can those classes be in overlay for Java 9 instead of Java 10 ? -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9618) Overlay for Java 10 could be Java 9

by tommaso borgato (Jira)

tommaso borgato created ISPN-9618: ------------------------------------- Summary: Overlay for Java 10 could be Java 9 Key: ISPN-9618 URL: https://issues.jboss.org/browse/ISPN-9618 Project: Infinispan Issue Type: Bug Components: Build Affects Versions: 9.4.0.Final Reporter: tommaso borgato The following classes are in overlay for Java 10: commons/src/main/java10/org/infinispan/commons/jdkspecific/CallerId.java commons/src/main/java10/org/infinispan/commons/jdkspecific/ProcessorInfo.java CallerId uses StackWalker that is available since Java 9. ProcessorInfo uses Runtime.getRuntime().availableProcessors() that was fixed in java 9 (https://bugs.java.com/view_bug.do?bug_id=6515172) Question: can those classes be in overlay for Java 9 instead of Java 10 ? -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9614) Convert listeners to work with async interceptor stack

by William Burns (Jira)

[ https://issues.jboss.org/browse/ISPN-9614?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-9614: -------------------------------- Summary: Convert listeners to work with async interceptor stack (was: Convert listners to work with async interceptor stack) > Convert listeners to work with async interceptor stack > ------------------------------------------------------ > > Key: ISPN-9614 > URL: https://issues.jboss.org/browse/ISPN-9614 > Project: Infinispan > Issue Type: Enhancement > Components: Listeners > Reporter: William Burns > Assignee: William Burns > Priority: Major > Fix For: 10.0.0.Final > > > Currently a sync listener will block the thread that is notifying it. It should return a _CompletableFuture_ to integrate properly with the async stack to be notified upon completion. > Also we should not invoke "alien" listeners on the same thread as they could block. We should allow listener to make itself async in some manner (ie. return type is CompletableFuture<Void>). -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9617) Create remote multimap simple example

by Katia Aresti (Jira)

[ https://issues.jboss.org/browse/ISPN-9617?page=com.atlassian.jira.plugin.... ] Katia Aresti updated ISPN-9617: ------------------------------- Description: Showcase remote multimap simple tutorial > Create remote multimap simple example > ------------------------------------- > > Key: ISPN-9617 > URL: https://issues.jboss.org/browse/ISPN-9617 > Project: Infinispan > Issue Type: Feature Request > Affects Versions: 9.4.0.Final > Reporter: Katia Aresti > Assignee: Katia Aresti > Priority: Major > > Showcase remote multimap simple tutorial -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9617) Create remote multimap simple example

by Katia Aresti (Jira)

[ https://issues.jboss.org/browse/ISPN-9617?page=com.atlassian.jira.plugin.... ] Katia Aresti updated ISPN-9617: ------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan-simple-tutorials/pull/58 > Create remote multimap simple example > ------------------------------------- > > Key: ISPN-9617 > URL: https://issues.jboss.org/browse/ISPN-9617 > Project: Infinispan > Issue Type: Feature Request > Affects Versions: 9.4.0.Final > Reporter: Katia Aresti > Assignee: Katia Aresti > Priority: Major > > Showcase remote multimap simple tutorial -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9616) Server does not include multimap

by Katia Aresti (Jira)

[ https://issues.jboss.org/browse/ISPN-9616?page=com.atlassian.jira.plugin.... ] Katia Aresti updated ISPN-9616: ------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/6341 > Server does not include multimap > -------------------------------- > > Key: ISPN-9616 > URL: https://issues.jboss.org/browse/ISPN-9616 > Project: Infinispan > Issue Type: Bug > Components: Server > Reporter: Katia Aresti > Assignee: Katia Aresti > Priority: Major > > Using multimap remote > INFO: ISPN004021: Infinispan version: 9.4.0.Final > Oct 18, 2018 11:27:10 AM org.infinispan.client.hotrod.impl.protocol.Codec20 checkForErrorsInResponseStatus > WARN: ISPN004005: Error received from the server: java.lang.NoClassDefFoundError: org/infinispan/multimap/impl/EmbeddedMultimapCache -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9617) Create remote multimap simple example

by Katia Aresti (Jira)

Katia Aresti created ISPN-9617: ---------------------------------- Summary: Create remote multimap simple example Key: ISPN-9617 URL: https://issues.jboss.org/browse/ISPN-9617 Project: Infinispan Issue Type: Feature Request Affects Versions: 9.4.0.Final Reporter: Katia Aresti Assignee: Katia Aresti -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 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 October 2018