External-Mirrors/keycloak
2
0
Fork 0
mirror of https://github.com/keycloak/keycloak.git synced 2026-01-10 15:32:05 -03:30
Code Issues Packages Projects Releases Wiki Activity

Update release notes docs for removed remote store

Browse Source 
Closes #39028

Signed-off-by: Alexander Schwartz <aschwart@redhat.com>
This commit is contained in:
Alexander Schwartz 2025-04-17 10:56:29 +02:00 committed by GitHub
parent c97a9563ef
commit 2be2958b8e
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
2 changed files with 13 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/documentation/release_notes/topics/26_3_0.adoc
View File

@ -1,7 +1,7 @@
= Usage of remote stores for embedded caches is restricted
Previously, usage of remote stores was discouraged and the experimental feature `cache-embedded-remote-store` needed to be enabled to run in this setup.
In this release, the experimental feature was removed and usage of remote stores was restricted.
In this release, the experimental feature was removed and usage of remote stores is restricted.
If you previously used the `cache-embedded-remote-store` feature, see the link:{upgradingguide_link}[{upgradingguide_name}] for migration steps.
= Asynchronous logging

17
docs/documentation/upgrading/topics/changes/changes-26_3_0.adoc
View File

@ -24,10 +24,17 @@ Notable changes where an internal behavior changed to prevent common misconfigur
=== Usage of remote stores embedded caches is restricted
The experimental feature `cache-embedded-remote-store` was removed in this release and usage of remote stores for embedded caches was restricted.
Consider the following cases and recommended migration steps.
The experimental feature `cache-embedded-remote-store` was removed in this release and usage of remote stores for embedded caches is now restricted.
. If you are using remote stores for running {project_name} in multiple data centers, follow link:{highavailabilityguide_link}[{highavailabilityguide_name}] for deploying {project_name}.
. If you are using remote stores to keep user sessions available after a {project_name} restart, use the `peristent-user-session` feature which is enabled by default since.
Consider one of the following cases and recommended migration steps:
* If you are using remote stores for running {project_name} in multiple data centers especially if they do not have a direct networking connection to allow all {project_name} nodes to form a cluster, follow the link:{highavailabilityguide_link}[{highavailabilityguide_name}] for deploying a multi-site {project_name} setup.
* If you are using remote stores to keep user sessions available after a {project_name} restart, use the `peristent-user-session` feature which is enabled by default.
[WARNING]
====
* {project_name} refuses to start if the `persistent-user-session` feature is disabled and remote store is configured for any of the user session caches.
* With the feature `persistent-user-session` feature enabled, the remote store configuration is ignored and {project_name} will print a warning.
====
WARNING: {project_name} will refuse to start if the `persistent-user-session` feature is disabled and remote store is configured for any of the user session caches.