January 2020 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-11126) Health check fails when authz is enabled and cache is not yet started

by Tristan Tarrant (Jira)

Tristan Tarrant created ISPN-11126: -------------------------------------- Summary: Health check fails when authz is enabled and cache is not yet started Key: ISPN-11126 URL: https://issues.redhat.com/browse/ISPN-11126 Project: Infinispan Issue Type: Bug Components: JMX, reporting and management, REST Affects Versions: 10.1.0.Final Reporter: Tristan Tarrant Assignee: Tristan Tarrant Fix For: 10.1.1.Final When using predefined caches on a container with authorization, and the caches have not been started, the health handler for the cachemanager resource fails with an authorization error. The call should be wrapped in a SecurityAction. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11116) Invalidation commands should not load the previous value from the store

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-11116?page=com.atlassian.jira.plugi... ] Pedro Ruivo updated ISPN-11116: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.3.7.Final 9.4.18.Final Resolution: Done > Invalidation commands should not load the previous value from the store > ----------------------------------------------------------------------- > > Key: ISPN-11116 > URL: https://issues.redhat.com/browse/ISPN-11116 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.3.6.Final, 9.4.17.Final, 10.0.1.Final, 10.1.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 9.3.7.Final, 11.0.0.Final, 9.4.18.Final, 10.1.1.Final > > > {{CacheLoaderInterceptor.visitInvalidateCommand()}} loads the previous value from the store, just in case there is a {{CacheEntryInvalidated}} listener that needs the previous value. This makes invalidation mode with a shared store very costly: for every write, every node receives an invalidation command, every node reads the value from the store, and then discards it. > But {{InvalidateCommand}} only removes entries from memory, it never removes entry from stores (either shared or private). If we don't load the previous value in the data container, there is nothing for the {{InvalidateCommand}} to do. No invalidated entry means no listener notifications, so we don't need to load the previous value or to change the behaviour of {{CacheEntryInvalidatedEvent}}. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11115) Infinispan BOM should only have dependency management for its own artifacts

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11115?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11115: ----------------------------------- Fix Version/s: 10.1.1.Final > Infinispan BOM should only have dependency management for its own artifacts > --------------------------------------------------------------------------- > > Key: ISPN-11115 > URL: https://issues.redhat.com/browse/ISPN-11115 > Project: Infinispan > Issue Type: Bug > Components: Build > Affects Versions: 10.1.0.Final > Reporter: Stéphane Nicoll > Assignee: Pedro Ruivo > Priority: Major > Fix For: 10.1.1.Final > > > A BOM should usually have dependency management for the artifacts of the project. Any attempt to provide dependency management for third party artifacts can lead to clashes and warnings in Maven when two boms compete for the same artifact. > Could you please consider removing dependency management for the transaction and cache API please? -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11115) Infinispan BOM should only have dependency management for its own artifacts

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11115?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11115: ----------------------------------- Status: Open (was: New) > Infinispan BOM should only have dependency management for its own artifacts > --------------------------------------------------------------------------- > > Key: ISPN-11115 > URL: https://issues.redhat.com/browse/ISPN-11115 > Project: Infinispan > Issue Type: Bug > Components: Build > Affects Versions: 10.1.0.Final > Reporter: Stéphane Nicoll > Assignee: Pedro Ruivo > Priority: Major > Fix For: 10.1.1.Final > > > A BOM should usually have dependency management for the artifacts of the project. Any attempt to provide dependency management for third party artifacts can lead to clashes and warnings in Maven when two boms compete for the same artifact. > Could you please consider removing dependency management for the transaction and cache API please? -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11115) Infinispan BOM should only have dependency management for its own artifacts

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11115?page=com.atlassian.jira.plugi... ] Tristan Tarrant reassigned ISPN-11115: -------------------------------------- Assignee: Pedro Ruivo > Infinispan BOM should only have dependency management for its own artifacts > --------------------------------------------------------------------------- > > Key: ISPN-11115 > URL: https://issues.redhat.com/browse/ISPN-11115 > Project: Infinispan > Issue Type: Bug > Components: Build > Affects Versions: 10.1.0.Final > Reporter: Stéphane Nicoll > Assignee: Pedro Ruivo > Priority: Major > Fix For: 10.1.1.Final > > > A BOM should usually have dependency management for the artifacts of the project. Any attempt to provide dependency management for third party artifacts can lead to clashes and warnings in Maven when two boms compete for the same artifact. > Could you please consider removing dependency management for the transaction and cache API please? -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11117) In a distributed cache stale entries are not removed from the store

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-11117?page=com.atlassian.jira.plugi... ] Dan Berindei commented on ISPN-11117: ------------------------------------- Turns out our documentation already says that invalidations remove the value from local stores: https://infinispan.org/docs/stable/titles/configuring/configuring.html#in... > In a distributed cache stale entries are not removed from the store > ------------------------------------------------------------------- > > Key: ISPN-11117 > URL: https://issues.redhat.com/browse/ISPN-11117 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 9.3.6.Final, 9.4.17.Final, 10.0.1.Final, 10.1.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 11.0.0.Final > > > This is a follow-up on ISPN-11116. It's wrong for invalidation commands to load the previous value from the store, but we also have the opposite problem: in a distributed cache, when a node loses some segments and the store is not segmented, we use an {{InvalidateCommand}} to remove stale entries, and it doesn't actually remove any entries from the store. > Instead of keeping {{InvalidateCommand}} as is and finding another solution for removing stale segments, we could change {{InvalidateCommand}} to also remove entries from private stores. > Invalidation mode is very unlikely to be used with private stores, but we don't actually prohibit it, so it's better for invalidation mode as well if {{InvalidateCommand}} removed entries from the private stores and ignored the shared stores. The only problem remaining is to actually optimize {{CacheLoaderInterceptor}} so that it doesn't load the previous value unless there is a listener. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11119) Invalidation put should load previous value from stores

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-11119?page=com.atlassian.jira.plugi... ] Dan Berindei updated ISPN-11119: -------------------------------- Status: Open (was: New) > Invalidation put should load previous value from stores > ------------------------------------------------------- > > Key: ISPN-11119 > URL: https://issues.redhat.com/browse/ISPN-11119 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.3.6.Final, 9.4.17.Final, 10.0.1.Final, 10.1.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 11.0.0.Final > > > A {{cache.put(key, value)}} without the {{IGNORE_RETURN_VALUES}} flag should load the previous value from the store(s) and return it. > Currently the previous value is loaded only if the originator of the put is the primary owner of the key (see {{ClusteredCacheLoaderInterceptor.skipLoadForWriteCommand()}}). -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11122) CacheMode.INVALIDATION_SYNC is being replicated

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-11122?page=com.atlassian.jira.plugi... ] Dan Berindei resolved ISPN-11122. --------------------------------- Resolution: Explained [~glira] you forgot to mention that the cache is backed by a shared JDBC store. The entries inserted on {{cache1}} go into the shared store, where they can be seen by both {{cache1}} and {{cache2}}. And even in invalidation mode, {{cache.size()}} includes both the entries in memory and the entries in the shared store. > CacheMode.INVALIDATION_SYNC is being replicated > ----------------------------------------------- > > Key: ISPN-11122 > URL: https://issues.redhat.com/browse/ISPN-11122 > Project: Infinispan > Issue Type: Bug > Affects Versions: 10.1.0.Final > Reporter: Gustavo Lira e Silva > Priority: Major > > Configuring two remote caches with hotrod and CacheMode.INVALIDATION_SYNC using InfinispanServerRule, populate cache1, cache2 should contain size=0, but all cache1 is being replicated to cache2. > {code:java} > RemoteCache<String, String> cache1 = SERVER_TEST.hotrod().withServerConfiguration(builder).withClientConfiguration(clientBuilder1).create(); > RemoteCache<String, String> cache2 = SERVER_TEST.hotrod().withServerConfiguration(builder).withClientConfiguration(clientBuilder2).create(); > cache1.put("key", "value"); > assertEquals("value", cache1.get("key")); > assertEquals(1, cache1.size()); > assertEquals(0, cache2.size()); // is failling > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11125) Convert L1 to be non blocking

by Will Burns (Jira)

Will Burns created ISPN-11125: --------------------------------- Summary: Convert L1 to be non blocking Key: ISPN-11125 URL: https://issues.redhat.com/browse/ISPN-11125 Project: Infinispan Issue Type: Sub-task Components: L1 Reporter: Will Burns L1 currently uses a blocking synchronizer construct to handle concurrent requests. We should instead use an orderer based on CompletionStage and make sure all methods are non blocking. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11124) REPL get optimiztion isn't applied for all calls

by Will Burns (Jira)

Will Burns created ISPN-11124: --------------------------------- Summary: REPL get optimiztion isn't applied for all calls Key: ISPN-11124 URL: https://issues.redhat.com/browse/ISPN-11124 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 10.0.0.Final Reporter: Will Burns ISPN-5451 added in some optimizations for REPL reads to not use the interceptor stack. Unfortunately this doesn't work as we now always invoke `getCacheEntryAsync` for hotrod. We need to make sure the optimized code path is used in all cases. We also should be using non blocking methods when possible as things like expiration can block unexpectedly. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2020