June 2020 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-11304) Allow scaling up without state transfer

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11304?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11304: ----------------------------------- Fix Version/s: 11.0.1.Final (was: 11.0.0.Final) > Allow scaling up without state transfer > --------------------------------------- > > Key: ISPN-11304 > URL: https://issues.redhat.com/browse/ISPN-11304 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 10.1.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 11.0.1.Final > > > We should allow a cache to scale up without performing any state transfer, but without losing the data. > To simplify things, the initial version will support a single owner, and will assume that only one node is being added at a time. > The cache must be accessible remotely, but since information about the location of the keys is not accessible from the client, the client is expected to ignore ownership and use a round-robin access strategy. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11913) Docs: Add search and improve index pages

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11913?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11913: ----------------------------------- Fix Version/s: 11.0.1.Final (was: 11.0.0.Final) > Docs: Add search and improve index pages > ---------------------------------------- > > Key: ISPN-11913 > URL: https://issues.redhat.com/browse/ISPN-11913 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Minor > Fix For: 11.0.1.Final > > > Add search and improve organization and high-level retrievability on index page. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11981) Stale immortal entry metadata

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11981?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11981: ----------------------------------- Fix Version/s: 11.0.1.Final (was: 11.0.0.Final) > Stale immortal entry metadata > ----------------------------- > > Key: ISPN-11981 > URL: https://issues.redhat.com/browse/ISPN-11981 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 11.0.0.CR1, 10.1.8.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 11.0.1.Final > > > When an entry is updated, {{InternalEntryFactoryImpl}} tries to reuse the existing {{InternalCacheEntry}} instance instead of creating a new one. The condition is that both the new and the old entry have the same implementation implementation: immortal, immortal w/ external metadata, transient, transient w/ metadata etc. > Because {{MetadataImmortalCacheEntry}} extends {{ImmortalCacheEntry}}, that logic is broken: when an immortal entry with external metadata is replaced with a new entry without external metadata, the external metadata is not removed. > This impacts the anchored keys module, which I am changing to store the key location in the metadata (currently it is stored as a value, and it is broken with BINARY/OFF_HEAP storage). When a node leaves and an entry located on the leaver is updated, the key is written on the newest joiner. The joiner already has a local entry with {{RemoteMetadata}}, and is trying to write a value without any metadata. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11946) Deprecate JBossUserMarshaller and associated classes

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11946?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11946: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Deprecate JBossUserMarshaller and associated classes > ---------------------------------------------------- > > Key: ISPN-11946 > URL: https://issues.redhat.com/browse/ISPN-11946 > Project: Infinispan > Issue Type: Sub-task > Affects Versions: 11.0.0.CR1 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 11.0.0.Final > > > We should deprecate the {{JBossUserMarshaller}} and mark it for removal in Infinispan 14. Users who still require jboss-marshalling should utilise the {{GenericJBossMarshaller}}. This does not support {{org.infinispan.commons.marshall.Externalizer}} implementations, but similar behaviour can be achieved by using {{org.jboss.marshalling.Externalizer}} implementations. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11910) Server should see application/octet-stream as protostream

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11910?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11910: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Server should see application/octet-stream as protostream > --------------------------------------------------------- > > Key: ISPN-11910 > URL: https://issues.redhat.com/browse/ISPN-11910 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Affects Versions: 11.0.0.CR1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 11.0.0.Final > > > The server, and Infinispan in general, should use the user marshaller to read {{application/octet-stream}} and {{application/unknown}} data. > ISPN-10433 added a hack in the server (for backwards compatibility, I assume): if {{jboss-marshalling}} is on the classpath, {{org.infinispan.server.core.LifecycleCallbacks.cacheManagerStarting()}} changes the marshaller for {{application/unknown}} (but not for {{application/octet-stream}}) to {{GenericJBossMarshaller}}. > This means that {{server/core}}, {{server/hotrod}}, and {{client/hotrod-client}} tests see {{application/unknown}} as protostream, but the server distribution in {{server/runtime}} always includes {{jboss-marshalling}}, so the server distribution sees {{application/unknown}} as {{GenericJBossMarshaller}} data. > It would be much better if the server always used the user marshaller for {{application/unknown}}, and when a user needs backwards compatibility between a new server and an old client, they should configure {{GenericJBossMarshaller}} in the server. > In addition, new clients should not use {{application/unknown}} unless the marshaller does not implement {{getMediaType()}}: they know the marshaller's media type, and they should send it to the server. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11873) Add report failure for RxJava Undelivered Errors

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11873?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11873: ----------------------------------- Fix Version/s: 11.0.1.Final (was: 11.0.0.Final) > Add report failure for RxJava Undelivered Errors > ------------------------------------------------ > > Key: ISPN-11873 > URL: https://issues.redhat.com/browse/ISPN-11873 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 11.0.1.Final > > > We should install an error handler into RxJava during the test suite so that if we get any undelivered exceptions they will be reported, similar to uncaught exception handler that was added. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11789) Update Query Guide

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11789?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11789: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Update Query Guide > ------------------ > > Key: ISPN-11789 > URL: https://issues.redhat.com/browse/ISPN-11789 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying, Remote Querying > Affects Versions: 11.0.0.Dev05 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > Labels: query-ispn11 > Fix For: 11.0.0.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11857) AbstractInfinispanTest.eventually() default poll interval is too long

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11857?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11857: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > AbstractInfinispanTest.eventually() default poll interval is too long > --------------------------------------------------------------------- > > Key: ISPN-11857 > URL: https://issues.redhat.com/browse/ISPN-11857 > Project: Infinispan > Issue Type: Task > Components: Core, Test Suite > Affects Versions: 11.0.0.Dev05, 10.1.8.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 11.0.0.Final > > > Some of the {{AbstractInfinispanTest.eventually()}} overloads use a poll interval of 500ms, which is too long. > The overloads that use a message supplier, and {{eventuallyEquals()}}, use a dynamic polling interval, starting at 65ms by default. All the overloads should use the same strategy, and the overloads that use an explicit polling interval should be removed. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11717) Deprecate ConsistentHashFactory customization

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11717?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11717: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Deprecate ConsistentHashFactory customization > --------------------------------------------- > > Key: ISPN-11717 > URL: https://issues.redhat.com/browse/ISPN-11717 > Project: Infinispan > Issue Type: Task > Components: Configuration, Core > Affects Versions: 11.0.0.Dev04 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 11.0.0.Final > > > There aren't any good reasons to use a {{ConsistentHashFactory}} implementation different than the default selected by {{StateTransferManagerImpl#pickConsistentHashFactory}}. > The configuration attribute made sense when the default was {{DefaultConsistentHashFactory}}, but {{SyncConsistentHashFactory}} is much better nowadays, and it's pretty much impossible to come up with an implementation that works in more than one cache mode with the current API. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11851) FD_SOCK should use the same bind address as TCP

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11851?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11851: ----------------------------------- Fix Version/s: 11.0.1.Final (was: 11.0.0.Final) > FD_SOCK should use the same bind address as TCP > ----------------------------------------------- > > Key: ISPN-11851 > URL: https://issues.redhat.com/browse/ISPN-11851 > Project: Infinispan > Issue Type: Bug > Components: Configuration, Core > Affects Versions: 11.0.0.Dev05, 10.1.8.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 11.0.1.Final > > > In the JGroups configuration files we ship, we use a different default for {{TCP.bind_addr}} and {{UDP.bind_addr}} than JGroups does. > {code:xml} > <TCP bind_addr="${jgroups.bind.address,jgroups.tcp.address:SITE_LOCAL}"/> > <UDP bind_addr="${jgroups.bind.address,jgroups.udp.address:SITE_LOCAL}"/> > {code} > However, we didn't change the default for {{FD_SOCK}}, so it uses the JGroups default: -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 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 June 2020