August 2020 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-12005) Store purge should ignore errors

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-12005?page=com.atlassian.jira.plugi... ] Pedro Ruivo updated ISPN-12005: ------------------------------- Fix Version/s: 11.0.3.Final (was: 11.0.2.Final) > Store purge should ignore errors > -------------------------------- > > Key: ISPN-12005 > URL: https://issues.redhat.com/browse/ISPN-12005 > Project: Infinispan > Issue Type: Bug > Components: Core, Loaders and Stores > Affects Versions: 10.1.5.Final, 11.0.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 12.0.0.Final, 11.0.3.Final > > > Purging of expired entries from stores is a pretty involved process, especially with {{RocksDBStore}}. When there's a problem unmarshalling the expired bucket or deleting an expired key, the purge task bails out immediately, without processing the remaining keys. To make matters worse, the exception it not logged anywhere. The only sign that something is wrong is a growing store (in the case of {{RocksDBStore}}, a growing number of SST files). -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12015) NPE if DefaultCacheManager created with InputStream and `xi:include` required

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-12015?page=com.atlassian.jira.plugi... ] Pedro Ruivo updated ISPN-12015: ------------------------------- Fix Version/s: 11.0.3.Final (was: 11.0.2.Final) > NPE if DefaultCacheManager created with InputStream and `xi:include` required > ----------------------------------------------------------------------------- > > Key: ISPN-12015 > URL: https://issues.redhat.com/browse/ISPN-12015 > Project: Infinispan > Issue Type: Bug > Components: Configuration, Core > Affects Versions: 11.0.0.Final > Reporter: Ryan Emerson > Assignee: Tristan Tarrant > Priority: Major > Fix For: 11.0.3.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12022) Provide a REST command to reset microprofile metrics

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-12022?page=com.atlassian.jira.plugi... ] Pedro Ruivo updated ISPN-12022: ------------------------------- Fix Version/s: 11.0.3.Final (was: 11.0.2.Final) > Provide a REST command to reset microprofile metrics > ---------------------------------------------------- > > Key: ISPN-12022 > URL: https://issues.redhat.com/browse/ISPN-12022 > Project: Infinispan > Issue Type: Enhancement > Components: JMX, reporting and management > Affects Versions: 10.1.0.Final > Reporter: Nistor Adrian > Assignee: Nistor Adrian > Priority: Major > Fix For: 11.0.3.Final > > > The microprofile metrics API does not provide a standard way to reset metrics. > We'll need to add one REST handler for this, if possible. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12029) Replace Blocking Executor with an EnhancedQueueExecutor

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-12029?page=com.atlassian.jira.plugi... ] Pedro Ruivo updated ISPN-12029: ------------------------------- Fix Version/s: 11.0.3.Final (was: 11.0.2.Final) > Replace Blocking Executor with an EnhancedQueueExecutor > ------------------------------------------------------- > > Key: ISPN-12029 > URL: https://issues.redhat.com/browse/ISPN-12029 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 12.0.0.Final, 11.0.3.Final > > > The blocking executor today uses a simple ThreadPoolExecutor. Unfortunately, this means that we will eventually start all configured threads (since core = max and we require a queue). Setting core size to less than max is not desirable as well as it will enqueue additional tasks rather than spawn a thread. > > The EnhancedQueueExecutor does exactly what we want and also has some additional features. We should utilize this which will keep our blocking thread pool size down during times of less activity. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11024) Unable to use binary memory eviction with protobuf

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-11024?page=com.atlassian.jira.plugi... ] Pedro Ruivo updated ISPN-11024: ------------------------------- Fix Version/s: 11.0.3.Final (was: 11.0.2.Final) > Unable to use binary memory eviction with protobuf > -------------------------------------------------- > > Key: ISPN-11024 > URL: https://issues.redhat.com/browse/ISPN-11024 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 10.0.1.Final > Reporter: Jens Reimann > Assignee: Will Burns > Priority: Critical > Fix For: 11.0.3.Final > > > Enabling binary eviction, e.g.: > {code:xml} > <memory> > <binary strategy="REMOVE" size="134217728" eviction="MEMORY"/> > </memory> > {code} > When storing protobuf based types, throws the following exception: > {code} > 15:36:29,859 ERROR [org.infinispan.interceptors.impl.InvocationContextInterceptor] (async-thread--p2-t18) ISPN000136: Error executing command PrepareCommand on Cache 'devices', writing keys []: java.lang.IllegalArgumentException: Size of Class class org.infinispan.query.remote.impl.indexing.ProtobufValueWrapper cannot be determined using given entry size calculator :class org.infinispan.container.entries.PrimitiveEntrySizeCalculator > {code} > As protobuf produces a binary representation of the data, it is possible to calculate a size for that object. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11189) Modules query and query-core have overlapping logging id ranges

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-11189?page=com.atlassian.jira.plugi... ] Pedro Ruivo updated ISPN-11189: ------------------------------- Fix Version/s: 11.0.3.Final (was: 11.0.2.Final) > Modules query and query-core have overlapping logging id ranges > --------------------------------------------------------------- > > Key: ISPN-11189 > URL: https://issues.redhat.com/browse/ISPN-11189 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 10.1.0.Final > Reporter: Nistor Adrian > Assignee: Nistor Adrian > Priority: Major > Labels: SearchNG > Fix For: 11.0.3.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11279) Replace UUID.randomUUID() with Util.threadLocalRandomUUID()

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-11279?page=com.atlassian.jira.plugi... ] Pedro Ruivo updated ISPN-11279: ------------------------------- Fix Version/s: 11.0.3.Final (was: 11.0.2.Final) > Replace UUID.randomUUID() with Util.threadLocalRandomUUID() > ----------------------------------------------------------- > > Key: ISPN-11279 > URL: https://issues.redhat.com/browse/ISPN-11279 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 10.1.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 11.0.3.Final > > > {{UUID.randomUUID()}} is pretty expensive, because it uses {{SecureRandom}}. > We don't need cryptographically strong UUIDs, so we can generate all our UUIDs with {{Util.threadLocalRandomUUID()}} instead. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11585) Use JavaSerializationMarshaller in jcache TCK modules

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-11585?page=com.atlassian.jira.plugi... ] Pedro Ruivo updated ISPN-11585: ------------------------------- Fix Version/s: 11.0.3.Final (was: 11.0.2.Final) > Use JavaSerializationMarshaller in jcache TCK modules > ----------------------------------------------------- > > Key: ISPN-11585 > URL: https://issues.redhat.com/browse/ISPN-11585 > Project: Infinispan > Issue Type: Task > Components: JCache > Affects Versions: 11.0.0.Dev03 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 11.0.3.Final > > > We should run the JSR-107 TCK with the java serialization marshaller, not with the protostream marshaller, to ensure that Infinispan is usable as a JCache implementation with minimal application code changes. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12097) Invalidation Cache with a shared store doesn't work properly after new SPI changes

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-12097?page=com.atlassian.jira.plugi... ] Pedro Ruivo updated ISPN-12097: ------------------------------- Fix Version/s: 11.0.3.Final (was: 11.0.2.Final) > Invalidation Cache with a shared store doesn't work properly after new SPI changes > ---------------------------------------------------------------------------------- > > Key: ISPN-12097 > URL: https://issues.redhat.com/browse/ISPN-12097 > Project: Infinispan > Issue Type: Bug > Components: Core, Loaders and Stores > Affects Versions: 11.0.1.Final > Reporter: Paul Ferraro > Assignee: Will Burns > Priority: Blocker > Fix For: 12.0.0.Final, 11.0.3.Final > > Attachments: Test.java > > > There seems to be something amiss with the new NonBlockingStore changes. When a transactional invalidation cache is used with a shared cache store, I've observed the entries published to the removePublisher of the NonBlockStore.batch(...) which should have targeted the writePublisher. This seems to happen when a batch only contains writes, but no removes. > See the attached test to reproduce the issue, which executes two simple cache operations against a transactional vs non-transactional cache using a shared write-through store. The transactional version fails due to unexpected removals triggered by the batch(...) method (which, in the case of the JDBC store delegates to the deleteBatch(...) and bulkUpdate(...) methods. TRACE logging indicates that entries are unexpectedly published to the removePublisher of batch(...) when transactions are enabled causing entries to be removed unexpectedly from the store (as the result of a Cache.put(...)). When tx are disabled, the batch(...) method is, of course, not in play, and everything works correctly via the individual write/delete methods. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10466) StateConsumerImpl.removeStaleData takes too long with unsegmented stores

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-10466?page=com.atlassian.jira.plugi... ] Pedro Ruivo updated ISPN-10466: ------------------------------- Fix Version/s: 9.4.21.Final (was: 9.4.20.Final) > StateConsumerImpl.removeStaleData takes too long with unsegmented stores > ------------------------------------------------------------------------ > > Key: ISPN-10466 > URL: https://issues.redhat.com/browse/ISPN-10466 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 9.4.16.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 9.4.21.Final > > > With a segmented data container, {{removeStaleData}} is very fast. But the product doesn't use segmented data containers yet, so it's still important to make {{removeStaleData}} faster with unsegmented data containers. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 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 August 2020