January 2021 - infinispan-issues - Jboss List Archives

[Red Hat JIRA] (ISPN-12051) REST Client URI support

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12051?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12051: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > REST Client URI support > ----------------------- > > Key: ISPN-12051 > URL: https://issues.redhat.com/browse/ISPN-12051 > Project: Infinispan > Issue Type: Enhancement > Components: REST > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 12.1.0.Final > > > This should be as close as possible to ISPN-11960 -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12115) CacheContainerAdmin should allow defining configurations

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12115?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12115: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > CacheContainerAdmin should allow defining configurations > -------------------------------------------------------- > > Key: ISPN-12115 > URL: https://issues.redhat.com/browse/ISPN-12115 > Project: Infinispan > Issue Type: Feature Request > Components: Core, Hot Rod, Server > Affects Versions: 11.0.1.Final > Reporter: Dan Berindei > Priority: Major > Fix For: 12.1.0.Final > > > {{EmbeddedCacheManagerAdmin}} and {{RemoteCacheManagerAdmin}} allow creating a cache with a complete configuration or with an existing configuration template. > It should be possible to define a configuration (template?) without a cache, so users/applications can define a common configuration and then reference it by name. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12048) Improve Cross-Site statistics

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12048?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12048: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > Improve Cross-Site statistics > ----------------------------- > > Key: ISPN-12048 > URL: https://issues.redhat.com/browse/ISPN-12048 > Project: Infinispan > Issue Type: Enhancement > Affects Versions: 11.0.0.Final > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Major > Fix For: 12.1.0.Final > > > Improve the cross-site statistics by adding a per-cache/site pair. Example: > * sender site > ** Cache_A > *** Site_b (min/avg/max rtt, nr_requests_sent) > ** Cache_B > *** Site_b (min/avg/max rtt, nr_requests_sent) > *** Site_c (min/avg/max rtt, nr_requests_sent) > * Receiver site > ** Cache_C > *** Site_a (nr_requests_received) > *** Site_c (nr_requests_received) -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-11993) Allow automatic registration of Protobuf schemas and marshallers

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11993?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11993: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > Allow automatic registration of Protobuf schemas and marshallers > ---------------------------------------------------------------- > > Key: ISPN-11993 > URL: https://issues.redhat.com/browse/ISPN-11993 > Project: Infinispan > Issue Type: Feature Request > Components: Hot Rod, Marshalling > Affects Versions: 11.0.0.CR1 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 12.1.0.Final > > > Currently it's necessary for users to automatically add {{SerializationContextIntializer}} instances to the client via {{addContextInitializers}} and for .proto files to be registered like so: > {code:java} > Path proto = Paths.get(Query.class.getClassLoader().getResource("proto/sheep.proto").toURI()); > cacheManager.getCache(ProtobufMetadataManagerConstants.PROTOBUF_METADATA_CACHE_NAME).put("sheep.proto", Files.readString(proto)); > {code} > Instead we should allow users to configure the client so that: > # {{SerializationContextInitalizer}} services are automatically registerd if {{builder.autoAddAllContextInitializers()}} is configured. > # {{*.proto}} files on the classpath and in available {{SerializationContextInitializers}} are automatically registered with the server if {{.autoRegisterSchemas()}} is configured. > ProtoStreams {{AutoProtoSchemaBuilder}} already provides a `service` attribute to generate the service files for {{SerializationContextInitiailizer}}, however this is false by default. We should update this to true so that users have one less knob to confgure. > NOTE: {{autoRegisterSchemas()}} will fail if authorization is enabled and the client does not have the ___schema_manager role. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12050) Docs: Apply consistent terminology and make improvements to Search API

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12050?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12050: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > Docs: Apply consistent terminology and make improvements to Search API > ---------------------------------------------------------------------- > > Key: ISPN-12050 > URL: https://issues.redhat.com/browse/ISPN-12050 > Project: Infinispan > Issue Type: Enhancement > Affects Versions: 11.0.0.Final > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Major > Fix For: 12.1.0.Final > > > Need to update Javadocs for org.infinispan.query.Search to reflect changes from deprecations and removals in 11. > [https://docs.jboss.org/infinispan/11.0/apidocs/org/infinispan/query/Searc...] > Also clarify terminology and align with doc changes. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12024) Preloading does not report unmarshalling errors

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12024?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12024: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > Preloading does not report unmarshalling errors > ----------------------------------------------- > > Key: ISPN-12024 > URL: https://issues.redhat.com/browse/ISPN-12024 > Project: Infinispan > Issue Type: Bug > Components: Core, Loaders and Stores > Affects Versions: 11.0.0.Final, 10.1.8.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 12.1.0.Final > > > When cache preloading hits an unmarshalling error, it stops in order to preserve the consistency of the cache. However, the thrown exception and the log won't contain the key with the problem, just a generic {{Unable to preload!}} message. > We should at the very least include the key in the exception message. But we could also provide a configuration option to ignore unmarshalling errors and only log a summary with the keys that could not be loaded at the end. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

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

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12005?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12005: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.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.1.0.Final, 11.0.10.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 (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12011) Investigate CompactionFilter for purging expired entries in RocksDB

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12011?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12011: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > Investigate CompactionFilter for purging expired entries in RocksDB > ------------------------------------------------------------------- > > Key: ISPN-12011 > URL: https://issues.redhat.com/browse/ISPN-12011 > Project: Infinispan > Issue Type: Sub-task > Components: Loaders and Stores > Reporter: Dan Berindei > Priority: Major > Fix For: 12.1.0.Final > > > RocksDB allows the application to process/delete entries during compaction, and we could use this [CompactionFilter|https://github.com/facebook/rocksdb/blob/master/include/...] callback to implement the purging of expired entries. > It's not straightforward, through: {{CompactionFilter}} must be implemented in a native (C++) library. {{rocksdb-jni}} allows using a native implementation from Java, but it does not allow defining it in Java (like it does for comparators). > Potential solutions: > # Write a native library implementing {{CompactionFilter}} for our current storage format > # Change the value format to match the Cassandra storage format and use the predefined {{CassandraCompactionFilter}} > # Revive the now-removed [LuaCompactionFilter|https://github.com/facebook/rocksdb/wiki/Lua-Compacti...] and write our filter implementation in Lua > # Contribute an adapter for Java CompactionFilter implementations to the RocksDB project, inspired by the existing AbstractComparator -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12151) Add error count metric

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12151?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12151: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > Add error count metric > ---------------------- > > Key: ISPN-12151 > URL: https://issues.redhat.com/browse/ISPN-12151 > Project: Infinispan > Issue Type: Feature Request > Components: Analytics > Affects Versions: 11.0.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 12.1.0.Final > > > {{CacheMgmtInterceptor}} has metrics for the different kind of key operations, but errors are not tracked. We should add a metric to count errors, and perhaps a histogram for the duration of failed invocations as well. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12128) Remote read during state transfer should store entry in data container

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12128?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12128: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > Remote read during state transfer should store entry in data container > ---------------------------------------------------------------------- > > Key: ISPN-12128 > URL: https://issues.redhat.com/browse/ISPN-12128 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 11.0.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Minor > Fix For: 12.1.0.Final > > > A cache with {{await-initial-transfer="false"}} will execute cache operations while it is receiving state, during rebalance phase {{READ_OLD_WRITE_ALL}}. State transfer can take a long time, and during that time, it is not a read owner for any segments, it is only a write owner for the segments it is receiving. > That means {{cache.get(k)}} will perform a remote lookup every time, even AFTER the node received entry {{k=v}} via transfer, as long as not all the nodes have confirmed the end of state transfer and the coordinator hasn't changed the rebalance phase to {{READ_ALL_WRITE_ALL}}. > The extra remote lookups can have a negative impact on application performance. Especially in a replicated cache, the application would expect reads to be very fast, and the repeated remote lookups would break that assumption. > In order to encourage {{await-initial-transfer="false"}} and eventually make it the default (ISPN-9112), we should limit the number of remote lookups performed by a node while is is a write-only owner of a key: > * Remote reads should write the entry in the data container, the same way state transfer would (i.e. skipping the write if a write operation already changed the entry). > * Reads should first look up the key in the local data container before going remotely. If the key exists locally, the value can be returned directly. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 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 January 2021