[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, 11 months
[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, 11 months
[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, 11 months
[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, 11 months
[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, 11 months
[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, 11 months
[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, 11 months
[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, 11 months
[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, 11 months
[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, 11 months