December 2020 - infinispan-issues

[Red Hat JIRA] (ISPN-12506) Console should work even if there is less permission for the user

by Katia Aresti (Jira)

[ https://issues.redhat.com/browse/ISPN-12506?page=com.atlassian.jira.plugi... ] Katia Aresti reassigned ISPN-12506: ----------------------------------- Assignee: Katia Aresti > Console should work even if there is less permission for the user > ----------------------------------------------------------------- > > Key: ISPN-12506 > URL: https://issues.redhat.com/browse/ISPN-12506 > Project: Infinispan > Issue Type: Bug > Reporter: Wolf-Dieter Fink > Assignee: Katia Aresti > Priority: Major > > Console should always show a page with some information or a message that the user can not access it because of permissions. > If a minor permission is missed the field or cache can be removed from the view, or button can be disabled. > But it should not end in blank pages as there is no hint what is going wrong. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12544) Add REST/CLI support for cache topology manipulation

by Dan Berindei (Jira)

Dan Berindei created ISPN-12544: ----------------------------------- Summary: Add REST/CLI support for cache topology manipulation Key: ISPN-12544 URL: https://issues.redhat.com/browse/ISPN-12544 Project: Infinispan Issue Type: Feature Request Components: CLI, REST Affects Versions: 12.0.0.Dev07 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 12.0.0.Final The REST endpoint and the CLI should allow the admin to view and manipulate the topology information: * get list of cache members * get topology details: topology id, rebalancing phase, number of segments owned for read/write by each node, number of segments to transfer to each node, maybe in the future number of segments already transferred, number of read/write owners for each segment (maybe the CLI could use histograms to condense the ownership information?) * get global topology summary: either all the per cache information in a single JSON, or maybe a simplified version that doesn't include or summarizes per-node and per-segment information. * get/set automatic rebalancing status globally and per cache * force rebalancing for a cache * cancel rebalancing for a cache (not yet implemented in core) * get/set the availability status of a cache -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 5 months

1
0
0 / 0

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

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11024?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11024: ----------------------------------- Fix Version/s: 11.0.7.Final (was: 11.0.6.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.7.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)

3 years, 5 months

1
0
0 / 0

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

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12022?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12022: ----------------------------------- Fix Version/s: 11.0.7.Final (was: 11.0.6.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.7.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)

3 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12548) Replicated cache get ignores value in zero-capacity nodes

by Dan Berindei (Jira)

Dan Berindei created ISPN-12548: ----------------------------------- Summary: Replicated cache get ignores value in zero-capacity nodes Key: ISPN-12548 URL: https://issues.redhat.com/browse/ISPN-12548 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 12.0.0.Dev07 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 12.0.0.CR1 In replicated caches that meet several other conditions, {{cache.get(key)}} is optimized to skip the interceptor chain and to read the entry directly from the data container. This optimization assumes that the local cache has all the values, and the assumption fails when the local node has a zero capacity factor. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12430) AsyncNonBlockingStore can have many more modifications than modification queue size

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12430?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12430: ----------------------------------- Fix Version/s: 12.0.0.CR1 (was: 12.0.0.Dev07) > AsyncNonBlockingStore can have many more modifications than modification queue size > ----------------------------------------------------------------------------------- > > Key: ISPN-12430 > URL: https://issues.redhat.com/browse/ISPN-12430 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 12.0.0.CR1 > > > The AsyncNonBlockingStore is known to allow for concurrent writes more than modification queue size. Unfortunately, due to how synchronized Publisher works it can be much much more if a given thread is delayed as other threads can sneak in. For example in the stress test with 1024 modification queue size I could get 6K entries in a given queue. The problem is that the concurrent publisher would add the value to its own queue which was only processed on the first thread, which means many could sneak in as no changes were actually populated in the map. https://github.com/ReactiveX/RxJava/blob/3.x/src/main/java/io/reactivex/r... > > We should change this to be a bit more strict and limit the writes to only queue + # of threads with concurrent modifications. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12489) Non-transactional INVALIDATION_SYNC cache deadlock

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12489?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12489: ----------------------------------- Fix Version/s: 12.0.0.CR1 (was: 12.0.0.Dev07) > Non-transactional INVALIDATION_SYNC cache deadlock > -------------------------------------------------- > > Key: ISPN-12489 > URL: https://issues.redhat.com/browse/ISPN-12489 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 10.1.8.Final, 11.0.5.Final, 12.0.0.Dev06 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 12.0.0.Final, 12.0.0.CR1 > > > Non-transactional invalidation caches use the old locking scheme from Infinispan 4.x, which is prone to deadlocks: > # {{put(k, v1)}} is invoked on node A and acquires lock {{k}} > # {{put(k, v2)}} is invoked on node B and acquires lock {{k}} > # {{A}} sends an {{InvalidateCommand(k)}} RPC to {{B}} > # {{B}} sends an {{InvalidateCommand(k)}} RPC to {{A}} > # The {{InvalidateCommand(k)}} from {{A}} and tries to acquire lock {{k}} on {{B}} > # The {{InvalidateCommand(k)}} from {{B}} and tries to acquire lock {{k}} on {{A}} > # Both {{InvalidateCommand(k)}} lock acquisitions eventually time out and release lock {{k}} on their originators. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 5 months

1
0
0 / 0

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

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11279?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11279: ----------------------------------- Fix Version/s: 11.0.7.Final (was: 11.0.6.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.7.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)

3 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12379) Named Query parameters don't work with full text queries

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12379?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12379: ----------------------------------- Fix Version/s: 12.0.0.CR1 (was: 12.0.0.Dev07) > Named Query parameters don't work with full text queries > -------------------------------------------------------- > > Key: ISPN-12379 > URL: https://issues.redhat.com/browse/ISPN-12379 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 11.0.3.Final, 12.0.0.Dev04 > Reporter: Gustavo Fernandes > Assignee: Nistor Adrian > Priority: Major > Fix For: 12.0.0.CR1 > > > Original query: {{FROM Entity WHERE description : "word word2 word4"}} > Introducing a parameter, e.g., "param" will not cause a replacement > {{FROM Entity WHERE description : ":param"}} -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12500) Possibility to separate the subdirectories under server-root

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12500?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12500: ----------------------------------- Fix Version/s: 11.0.7.Final (was: 11.0.6.Final) > Possibility to separate the subdirectories under server-root > ------------------------------------------------------------ > > Key: ISPN-12500 > URL: https://issues.redhat.com/browse/ISPN-12500 > Project: Infinispan > Issue Type: Feature Request > Affects Versions: 11.0.5.Final, 12.0.0.Dev06 > Reporter: Wolf-Dieter Fink > Assignee: Tristan Tarrant > Priority: Major > Fix For: 12.0.0.Dev07, 11.0.7.Final > > > For administration purpose it should be possible to set different locations for server/conf server/data server/lib and server/log instead of keeping all together with server-root setting. > Additionally the lib directory should be scanned recursively, resolving symlinks and supporting bare files (e.g. property files) as well as Jar files. It should also be possible to specify multiple lib directories. > -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 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 December 2020