July 2020 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-12136) [9.4.x] Docs: Update deployment structure xml to access user classes

by Ryan Emerson (Jira)

[ https://issues.redhat.com/browse/ISPN-12136?page=com.atlassian.jira.plugi... ] Ryan Emerson resolved ISPN-12136. --------------------------------- Fix Version/s: 9.4.20.Final Resolution: Done > [9.4.x] Docs: Update deployment structure xml to access user classes > -------------------------------------------------------------------- > > Key: ISPN-12136 > URL: https://issues.redhat.com/browse/ISPN-12136 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Major > Fix For: 9.4.20.Final > > > Users must update jboss-deployment-structure.xml otherwise it is not possible to access user classes. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12136) [9.4.x] Docs: Update deployment structure xml to access user classes

by Ryan Emerson (Jira)

[ https://issues.redhat.com/browse/ISPN-12136?page=com.atlassian.jira.plugi... ] Ryan Emerson updated ISPN-12136: -------------------------------- Status: Open (was: New) > [9.4.x] Docs: Update deployment structure xml to access user classes > -------------------------------------------------------------------- > > Key: ISPN-12136 > URL: https://issues.redhat.com/browse/ISPN-12136 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Major > > Users must update jboss-deployment-structure.xml otherwise it is not possible to access user classes. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[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: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 12.0.0.Final (was: 11.0.2.Final) Resolution: Done > 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: 12.0.0.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)

4 years, 5 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: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 12.0.0.Dev01 (was: 11.0.2.Final) Resolution: Done > 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: 12.0.0.Dev01 > > > 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)

4 years, 5 months

1
0
0 / 0

[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: 12.0.0.Dev01 (was: 12.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: 12.0.0.Dev01 > > > 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)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12135) Upgrade Netty to 4.1.51.Final

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12135?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12135: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Upgrade Netty to 4.1.51.Final > ----------------------------- > > Key: ISPN-12135 > URL: https://issues.redhat.com/browse/ISPN-12135 > Project: Infinispan > Issue Type: Component Upgrade > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Major > Fix For: 9.4.20.Final, 11.0.2.Final, 12.0.0.Dev01 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11997) Remove jackson databind

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11997?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11997: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Remove jackson databind > ------------------------ > > Key: ISPN-11997 > URL: https://issues.redhat.com/browse/ISPN-11997 > Project: Infinispan > Issue Type: Enhancement > Components: REST > Affects Versions: 11.0.0.Final > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > Fix For: 12.0.0.Final > > > Jackson databind uses serialization and the native server needs rules to support it. Also it's desirable to reduce the number of dependencies in the REST server to avoid image respins due to CVEs -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12139) Cache.size() always returns 0 for invalidation caches

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/ISPN-12139?page=com.atlassian.jira.plugi... ] Paul Ferraro updated ISPN-12139: -------------------------------- Description: It seems that Cache.size() always returns 0 for an invalidation cache. See attached reproducer. Filing as a blocker as this is a regression since 10.1.x. was: It seems that Cache.size() always returns 0 for an invalidation cache. See attached reproducer. > Cache.size() always returns 0 for invalidation caches > ----------------------------------------------------- > > Key: ISPN-12139 > URL: https://issues.redhat.com/browse/ISPN-12139 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 11.0.1.Final > Reporter: Paul Ferraro > Priority: Blocker > Attachments: Test.java > > > It seems that Cache.size() always returns 0 for an invalidation cache. > See attached reproducer. > Filing as a blocker as this is a regression since 10.1.x. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12139) Cache.size() always returns 0 for invalidation caches

by Paul Ferraro (Jira)

Paul Ferraro created ISPN-12139: ----------------------------------- Summary: Cache.size() always returns 0 for invalidation caches Key: ISPN-12139 URL: https://issues.redhat.com/browse/ISPN-12139 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 11.0.1.Final Reporter: Paul Ferraro Attachments: Test.java It seems that Cache.size() always returns 0 for an invalidation cache. See attached reproducer. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12139) Cache.size() always returns 0 for invalidation caches

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/ISPN-12139?page=com.atlassian.jira.plugi... ] Paul Ferraro updated ISPN-12139: -------------------------------- Attachment: Test.java > Cache.size() always returns 0 for invalidation caches > ----------------------------------------------------- > > Key: ISPN-12139 > URL: https://issues.redhat.com/browse/ISPN-12139 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 11.0.1.Final > Reporter: Paul Ferraro > Priority: Blocker > Attachments: Test.java > > > It seems that Cache.size() always returns 0 for an invalidation cache. > See attached reproducer. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2020