33cae33ae4
Clustering is disabled with multi-site deployment and there is no JGroups thread pool to configure. Closes #34715 Signed-off-by: Pedro Ruivo <pruivo@redhat.com> Signed-off-by: Alexander Schwartz <aschwart@redhat.com> Co-authored-by: Alexander Schwartz <aschwart@redhat.com>
68 lines
No EOL
5.5 KiB
Text
68 lines
No EOL
5.5 KiB
Text
= Infinispan default XML configuration location
|
|
|
|
Previous releases ignored any change to `conf/cache-ispn.xml` if the `--cache-config-file` option was not provided.
|
|
|
|
Starting from this release, when `--cache-config-file` is not set, the default Infinispan XML configuration file is `conf/cache-ispn.xml` as this is both the expected behavior and the implied behavior given the docs of the current and previous releases.
|
|
|
|
= Embedded Infinispan: `work` cache must be replicated
|
|
|
|
The embedded `work` cache needs to be configured as a `replicated-cache` for cache invalidation to work as expected.
|
|
|
|
Starting from this release, {project_name} check this at startup and will fail to start if it is not configured as such.
|
|
|
|
= Deprecated APIs for JavaScript Authorization client
|
|
|
|
The following APIs for the JavaScript Authorization client are deprecated and will be removed in the next major release:
|
|
|
|
- The `ready` property on the `KeycloakAuthorization` instance.
|
|
- The `init()` method on the `KeycloakAuthorization` instance.
|
|
|
|
These APIs are no longer needed as initialization is done automatically on demand when calling methods on the `KeycloakAuthorization` instance. You can safely remove any code that depends on these APIs.
|
|
|
|
= Virtual Threads enabled for Infinispan and JGroups thread pools
|
|
|
|
Starting from this release, {project_name} automatically enables the virtual thread pool support in both the embedded Infinispan and JGroups when running on OpenJDK 21.
|
|
This removes the need to configure the JGroups thread pool, the need to align the JGroups thread pool with the HTTP worker thread pool, and reduces the overall memory footprint.
|
|
To disable the virtual threads, add one of the Java system properties combinations to your deployment:
|
|
|
|
* `-Dorg.infinispan.threads.virtual=false`: disables virtual thread in both Infinispan and JGroups.
|
|
* `-Djgroups.thread.virtual=false`: disables virtual threads only in JGroups.
|
|
* `-Dorg.infinispan.threads.virtual=false -Djgroups.thread.virtual=true`: disables virtual threads only in Infinispan.
|
|
|
|
= Default transport stack changed to JDBC_PING2 for distributed caches
|
|
|
|
Previous versions of {project_name} used as a default UDP multicast to discover other nodes to form a cluster and to synchronize the replicated caches of {project_name}.
|
|
This required multicast to be available and to be configured correctly, which is usually not the case in cloud environments.
|
|
|
|
Starting with this version, the default changes to a configuration of JDBC_PING2 which uses {project_name}'s database to discover other nodes.
|
|
As this removes the need for multicast network capabilities, this is a simplification and a drop-in replacement.
|
|
|
|
To enable the previous behavior, choose the transport stack `udp`.
|
|
|
|
The {project_name} Operator will continue to configure `kubernetes` as a transport stack.
|
|
|
|
= Deprecated transport stacks for distributed caches
|
|
|
|
The `azure`, `ec2` and `google` transport stacks have been deprecated. Users should use the TCP based `jdbc-ping`
|
|
stack as a direct replacement.
|
|
|
|
= Defining dependencies between provider factories
|
|
|
|
When developing extensions for {project_name}, developers can now specify dependencies between provider factories classes by implementing the method `dependsOn()` in the `ProviderFactory` interface.
|
|
See the Javadoc for a detailed description.
|
|
|
|
= Removal of robots.txt file
|
|
|
|
The `robots.txt` file, previously included by default, is now removed. The default `robots.txt` file blocked all crawling, which prevented the `noindex`/`nofollow` directives from being followed. The desired default behaviour is for {project_name} pages to not show up in search engine results and this is accomplished by the existing `X-Robots-Tag` header, which is set to `none` by default. The value of this header can be overidden per-realm if a different behaviour is needed.
|
|
|
|
= Offline access removes the associated online session if the `offline_scope` is requested in the initial exchange
|
|
|
|
Any offline session in {project_name} is created from another online session. When the `offline_access` scope is requested, the current online session is used to create the associated offline session for the client. Therefore any `offline_access` request finished, until now, with two sessions, one online and one offline.
|
|
|
|
Starting with this version, {project_name} removes the initial online session if the `offline_scope` is directly requested as the first interaction for the session. The client retrieves the offline token after the code to token exchange that is associated to the offline session, but the previous online session is removed. If the online session has been used before the `offline_scope` request, by the same or another client, the online session remains active as today. Although the new behavior makes sense because the client application is just asking for an offline token, it can affect some scenarios that rely on having the online session still active after the initial `offline_scope` token request.
|
|
|
|
= New client scope `service_account` for `client_credentials` grant mappers
|
|
|
|
{project_name} introduces a new client scope at the realm level called `service_account` which is in charge of adding the specific claims for `client_credentials` grant (`client_id`, `clientHost` and `clientAddress`) via protocol mappers. This scope will be automatically assigned to and unassigned from the client when the `serviceAccountsEnabled` option is set or unset in the client configuration.
|
|
|
|
Previously, the three mappers (`Client Id`, `Client Host` and `Client IP Address`) where added directly to the dedicated scope when the client was configured to enable service accounts, and they were never removed. |