anchor.diff:  |azure|TCP|AZURE_PING
   |===
   
  -For the cloud vendor specific stacks to work, you have to provide additional dependencies to Keycloak. You can find more information, including Links to repositories providing the additional dependencies, in the https://infinispan.org/docs/dev/titles/embedding/embedding.html#jgroups-cloud-discovery-protocols_cluster-transport[official Infinispan documentation].
  +Cloud vendor specific stacks have additional dependencies for Keycloak.
  +For more information and links to repositories with these dependencies, see the https://infinispan.org/docs/dev/titles/embedding/embedding.html#jgroups-cloud-discovery-protocols_cluster-transport[Infinispan documentation].
   
  -To provide the dependencies to Keycloak, put the respective JAR in the `providers` directory and `build` Keycloak afterwards, using
  +To provide the dependencies to Keycloak, put the respective JAR in the `providers` directory and `build` Keycloak by entering this command:
   
   <@kc.build parameters="--cache-stack=<ec2|google|azure>"/>
   
   === Securing cache communication
  -The current Infinispan cache implementation should be secured by various security measures such as RBAC, ACLs and Transport stack encryption. Please refer to the https://infinispan.org/docs/dev/titles/security/security.html#[Infinispan security guide] for more information about securing cache communication.
  +The current Infinispan cache implementation should be secured by various security measures such as RBAC, ACLs, and Transport stack encryption. For more information about securing cache communication, see the https://infinispan.org/docs/dev/titles/security/security.html#[Infinispan security guide].
   
   </@tmpl.guide>
  
positive.code: |actionTokens|Distributed|Caches action Tokens
  |====
  
  Local caches for realms, users and authorization are configured to have 10000 entries per default. The local key cache can hold up to 1000 entries per default and defaults to expire every 1h, so keys are forced to be periodically downloaded from external clients or identity providers.
  
  All distributed caches are set to have 2 owners per default, meaning 2 nodes having a copy of the specific cache entries. Non-owner nodes query the owners of a specific cache to obtain data. When both owner nodes are offline, all data gets lost. This usually leads to users being logged out at the next request and having to login again.
  
  === Specify your own cache configuration file
  
  To specify your own cache configuration file, use:
  
  <@kc.build parameters="--cache-config-file=my-cache-file.xml"/>
  
  == Transport stacks
  Transport stacks ensure that distributed cache nodes in a cluster communicate in a reliable fashion. Keycloak supports a wide range of transport stacks:
  
  <@opts.expectedValues option="cache-stack"/>
  
  To apply a specific cache stack, use:
  
  <@kc.build parameters="--cache-stack=<stack>"/>
  
  
negative.code: |===
  
  === Additional transport stacks
  The following table shows transport stacks that are supported by Keycloak, but need some extra steps to work.
  Note that _none_  of these stacks are Kubernetes / OpenShift stacks, so no need exists to enable the "google" stack if you want to run Keycloak on top of the Google Kubernetes engine.
  In that case, use the `kubernetes` stack.
  Instead, when you have a distributed cache setup running on AWS EC2 instances, you would need to set the stack to `ec2`, because ec2 does not support a default discovery mechanism such as `UDP`.
  
  |===
  |Stack name|Transport protocol|Discovery
  