October 2019 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (IPROTO-119) Introduce a customizable TypeId mapper to support changing type ids (and names) for schema evolution

by Ryan Emerson (Jira)

[ https://issues.jboss.org/browse/IPROTO-119?page=com.atlassian.jira.plugin... ] Ryan Emerson commented on IPROTO-119: ------------------------------------- I'm happy for {{mapTypeName}} to be removed, as like you say type names should never be changed as per protobuf conventions. However, as TypeId is a protostream construct I think we should try and provide a mechanism for mapping. We could add methods to ProtobufUtil that have a boolean param, which if true indicates that the legacy Ids should be used. Something like {{ProtobufUtil.toWrappedStream(ImmutableSerializationContext ctx, OutputStream out, Object t, boolean legacyTypeIds)}} and the same for the corresponding read method(s). In Infinispan, we then set this boolean to true if an old client is used. > Introduce a customizable TypeId mapper to support changing type ids (and names) for schema evolution > ---------------------------------------------------------------------------------------------------- > > Key: IPROTO-119 > URL: https://issues.jboss.org/browse/IPROTO-119 > Project: Infinispan ProtoStream > Issue Type: Enhancement > Reporter: Nistor Adrian > Assignee: Nistor Adrian > Priority: Major > Fix For: 4.3.0.Alpha13 > > > This should be a simple interface for mapping type ids in and out. Should be specified in Configuration -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10685) File stores locations do not respect the Global State persistent location

by Ryan Emerson (Jira)

[ https://issues.jboss.org/browse/ISPN-10685?page=com.atlassian.jira.plugin... ] Ryan Emerson resolved ISPN-10685. --------------------------------- Resolution: Done > File stores locations do not respect the Global State persistent location > -------------------------------------------------------------------------- > > Key: ISPN-10685 > URL: https://issues.jboss.org/browse/ISPN-10685 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 10.0.0.CR2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 10.0.0.CR3 > > > The file stores (Single, SoftIndex, RocksDB) should create files relative to the GlobalState persistent location unless specified. > Additionally each of the file stores differs in the filesystem layout: > * The SoftIndex store does not use the name of the cache in the file path, preventing sharing of directories between multiple caches. > * The RocksDB store allows configuring data and expired locations to point to the same directory, which will result in data corruption -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10669) MurmurHash3 should have a special case for WrappedBytes

by Nistor Adrian (Jira)

[ https://issues.jboss.org/browse/ISPN-10669?page=com.atlassian.jira.plugin... ] Nistor Adrian commented on ISPN-10669: -------------------------------------- True, but I would still fix it for the general case if possible. Current code works but in a non-obvious way with great potential for generating confusion. > MurmurHash3 should have a special case for WrappedBytes > ------------------------------------------------------- > > Key: ISPN-10669 > URL: https://issues.jboss.org/browse/ISPN-10669 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 10.0.0.CR2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.CR3 > > > {{MurmurHash3.hashCode(Object)}} has a special case for {{WrappedBytesArray}}, but not for other implementations of {{WrappedBytes}} like {{ProtobufValueWrapper}}. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10692) WildFly 18.0.0.Beta1

by Pedro Ruivo (Jira)

[ https://issues.jboss.org/browse/ISPN-10692?page=com.atlassian.jira.plugin... ] Pedro Ruivo updated ISPN-10692: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > WildFly 18.0.0.Beta1 > -------------------- > > Key: ISPN-10692 > URL: https://issues.jboss.org/browse/ISPN-10692 > Project: Infinispan > Issue Type: Component Upgrade > Components: Build, WildFly modules > Affects Versions: 10.0.0.CR2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 10.0.0.CR3 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10627) Community Site: Update docs with all titles

by Donald Naro (Jira)

[ https://issues.jboss.org/browse/ISPN-10627?page=com.atlassian.jira.plugin... ] Donald Naro updated ISPN-10627: ------------------------------- Sprint: DataGrid Sprint #35 (was: DataGrid Sprint #34) > Community Site: Update docs with all titles > ------------------------------------------- > > Key: ISPN-10627 > URL: https://issues.jboss.org/browse/ISPN-10627 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation-Core, Website > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Major > > make sure all titles are available and no 404s. the titles on infinispan.org/documentation should match index.html -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-119) Introduce a customizable TypeId mapper to support changing type ids (and names) for schema evolution

by Nistor Adrian (Jira)

[ https://issues.jboss.org/browse/IPROTO-119?page=com.atlassian.jira.plugin... ] Nistor Adrian commented on IPROTO-119: -------------------------------------- This is fixed now, but I have second thoughts about it. Since we do not maintain any state in the WrappedMessageTypeMapper callback we cannot know if we are invoked by an old client that needs TypeId translation or not. Also, we need to introduce an option to discard the TypeId. A possible solution would be to return a negative value from WrappedMessageTypeMapper.mapTypeId. I also have second thought about WrappedMessageTypeMapper.mapTypeName. Type names should never change during schema evolution. We could allow that for more flexibility, but I'd rather remove that and keep things as simple as possible. > Introduce a customizable TypeId mapper to support changing type ids (and names) for schema evolution > ---------------------------------------------------------------------------------------------------- > > Key: IPROTO-119 > URL: https://issues.jboss.org/browse/IPROTO-119 > Project: Infinispan ProtoStream > Issue Type: Enhancement > Reporter: Nistor Adrian > Assignee: Nistor Adrian > Priority: Major > Fix For: 4.3.0.Alpha13 > > > This should be a simple interface for mapping type ids in and out. Should be specified in Configuration -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10657) Handle async-xsite in parallel

by Pedro Ruivo (Jira)

[ https://issues.jboss.org/browse/ISPN-10657?page=com.atlassian.jira.plugin... ] Pedro Ruivo updated ISPN-10657: ------------------------------- Fix Version/s: 10.0.0.CR3 9.4.17.Final > Handle async-xsite in parallel > ------------------------------ > > Key: ISPN-10657 > URL: https://issues.jboss.org/browse/ISPN-10657 > Project: Infinispan > Issue Type: Enhancement > Components: Cross-Site Replication > Affects Versions: 10.0.0.CR2 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Major > Fix For: 10.0.0.CR3, 9.4.17.Final > > > Asynchronous cross-site replication relies on the ordering of the write operation to ensure data consistency. This ordering is provided by JGroups; it only delivers the next request after the first one is completed. > This order contains updates for multiple caches and keys. What is proposed here is to handle different keys/cache updates in parallel. > It should improve the response time, however, there is no free lunch. The following is expected: > * An increase of CPU utilization: it may spawn new threads to handle different keys update in parallel > * An increase in memory: it chains the updates (queue) -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10657) Handle async-xsite in parallel

by Pedro Ruivo (Jira)

[ https://issues.jboss.org/browse/ISPN-10657?page=com.atlassian.jira.plugin... ] Pedro Ruivo updated ISPN-10657: ------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/7379 > Handle async-xsite in parallel > ------------------------------ > > Key: ISPN-10657 > URL: https://issues.jboss.org/browse/ISPN-10657 > Project: Infinispan > Issue Type: Enhancement > Components: Cross-Site Replication > Affects Versions: 10.0.0.CR2 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Major > Fix For: 10.0.0.CR3, 9.4.17.Final > > > Asynchronous cross-site replication relies on the ordering of the write operation to ensure data consistency. This ordering is provided by JGroups; it only delivers the next request after the first one is completed. > This order contains updates for multiple caches and keys. What is proposed here is to handle different keys/cache updates in parallel. > It should improve the response time, however, there is no free lunch. The following is expected: > * An increase of CPU utilization: it may spawn new threads to handle different keys update in parallel > * An increase in memory: it chains the updates (queue) -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10697) Expiration reaper should be able to handle a huge number of expired entries

by Wolf-Dieter Fink (Jira)

[ https://issues.jboss.org/browse/ISPN-10697?page=com.atlassian.jira.plugin... ] Wolf-Dieter Fink updated ISPN-10697: ------------------------------------ Security: (was: Red Hat Internal) > Expiration reaper should be able to handle a huge number of expired entries > --------------------------------------------------------------------------- > > Key: ISPN-10697 > URL: https://issues.jboss.org/browse/ISPN-10697 > Project: Infinispan > Issue Type: Enhancement > Affects Versions: 10.0.0.CR2 > Reporter: Wolf-Dieter Fink > Assignee: Will Burns > Priority: Critical > > A use case where a huge number of entries are added and expire in a short period the reaper is not able to handle that and will have increasing backlog which cause OOM error. > The TRACE messages within the logfiles are > TRACE [org.infinispan.expiration.impl.ClusterExpirationManager] (pool-9-thread-1) Purging data container of expired entries > TRACE [org.infinispan.expiration.impl.ClusterExpirationManager] (pool-9-thread-1) Submitting expiration removal for key WrappedByteArray{...} which had lifespan of 480000 > ..... 1,900,000 more > TRACE [org.infinispan.expiration.impl.ClusterExpirationManager] (pool-9-thread-1) Purging data container completed in 15.45 minutes > As shown the reaper run for >15 minutes but the lifespan is set to 480sec==8min so there is a massive overlap and the reaper is not able to delete the entries fast enough from the cache -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10697) Expiration reaper should be able to handle a huge number of expired entries

by Wolf-Dieter Fink (Jira)

[ https://issues.jboss.org/browse/ISPN-10697?page=com.atlassian.jira.plugin... ] Wolf-Dieter Fink updated ISPN-10697: ------------------------------------ Priority: Major (was: Critical) > Expiration reaper should be able to handle a huge number of expired entries > --------------------------------------------------------------------------- > > Key: ISPN-10697 > URL: https://issues.jboss.org/browse/ISPN-10697 > Project: Infinispan > Issue Type: Enhancement > Affects Versions: 10.0.0.CR2 > Reporter: Wolf-Dieter Fink > Assignee: Will Burns > Priority: Major > > A use case where a huge number of entries are added and expire in a short period the reaper is not able to handle that and will have increasing backlog which cause OOM error. > The TRACE messages within the logfiles are > TRACE [org.infinispan.expiration.impl.ClusterExpirationManager] (pool-9-thread-1) Purging data container of expired entries > TRACE [org.infinispan.expiration.impl.ClusterExpirationManager] (pool-9-thread-1) Submitting expiration removal for key WrappedByteArray{...} which had lifespan of 480000 > ..... 1,900,000 more > TRACE [org.infinispan.expiration.impl.ClusterExpirationManager] (pool-9-thread-1) Purging data container completed in 15.45 minutes > As shown the reaper run for >15 minutes but the lifespan is set to 480sec==8min so there is a massive overlap and the reaper is not able to delete the entries fast enough from the cache -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2019