commit
cc3e0197b3
6 changed files with 13 additions and 11 deletions
3
topics/cache/disable.adoc
vendored
3
topics/cache/disable.adoc
vendored
|
@ -24,3 +24,6 @@ Here's what the config looks like initially.
|
|||
|
||||
To disable the cache set the `enabled` field to false for the cache you want to disable. You must reboot your
|
||||
server for this change to take effect.
|
||||
|
||||
NOTE: You must also remove the line like `"provider": "default"` from the `realmCache` configuration. Otherwise disabling cache won't work.
|
||||
|
||||
|
|
|
@ -27,7 +27,7 @@ any black or white listing of IP addresses.
|
|||
Beyond the proxy itself, there are a few things you need to configure on the {{book.project.name}} side of things.
|
||||
If your proxy is forwarding requests via the HTTP protocol, then you need to configure {{book.project.name}} to pull the client's
|
||||
IP address from the `X-Forwarded-For` header rather than from the network packet.
|
||||
To do this, open up the profile configuration file (_standalone.xml, _standalone-ha.xml_, or _domain.xml_ depending on your
|
||||
To do this, open up the profile configuration file (_standalone.xml_, _standalone-ha.xml_, or _domain.xml_ depending on your
|
||||
<<fake/../../operating-mode.adoc#_operating-mode, operating mode>>) and look for the `"urn:jboss:domain:undertow:3.0` XML block.
|
||||
|
||||
.`X-Forwarded-For` HTTP Config
|
||||
|
@ -55,7 +55,7 @@ pull this information from the AJP packets.
|
|||
.`X-Forwarded-For` AJP Config
|
||||
[source,xml]
|
||||
----
|
||||
<<subsystem xmlns="urn:jboss:domain:undertow:3.0">
|
||||
<subsystem xmlns="urn:jboss:domain:undertow:3.0">
|
||||
<buffer-cache name="default"/>
|
||||
<server name="default-server">
|
||||
<ajp-listener name="ajp" socket-binding="ajp"/>
|
||||
|
@ -93,7 +93,7 @@ socket binding you also need to define.
|
|||
|
||||
Then add a new `socket-binding` element to the `socket-binding-group` element:
|
||||
|
||||
[source]
|
||||
[source,xml]
|
||||
----
|
||||
|
||||
<socket-binding-group name="standard-sockets" default-interface="public"
|
||||
|
|
|
@ -4,18 +4,17 @@
|
|||
|
||||
{{book.project.name}} cluster nodes are allowed to boot concurrenty.
|
||||
When {{book.project.name}} server instance boots up it may do some database migration, importing, or first time initializations.
|
||||
A DB lock is used to prevent start actions from conflicting ith one another when cluster nodes boot up concurrently.
|
||||
A DB lock is used to prevent start actions from conflicting with one another when cluster nodes boot up concurrently.
|
||||
|
||||
By default, the maximum timeout for this lock is 900 seconds. If a node is waiting on this lock for more than the timeout
|
||||
it will fail to boot. This lock is checked every 2 seconds by default.
|
||||
it will fail to boot.
|
||||
Typically you won't need to increase/decrease the default value, but just in case it's possible to configure it in `keycloak-server.json`:
|
||||
|
||||
[source,json]
|
||||
----
|
||||
"dblock": {
|
||||
"jpa": {
|
||||
"lockWaitTimeout": 900,
|
||||
"lockRecheckTime": 2
|
||||
"lockWaitTimeout": 900
|
||||
}
|
||||
}
|
||||
----
|
||||
|
|
|
@ -4,7 +4,7 @@
|
|||
{{book.project.name}} comes with its own embedded Java-based relational database called H2.
|
||||
This is the default database that {{book.project.name}} will use to persist data and really only exists so that you can run the authentication
|
||||
server out of the box. We highly recommend that you replace it with a more production ready external database. The H2 database
|
||||
is not very viable in high concurrency situations and cannot be used in a cluster either. The purpose of this chapter is to
|
||||
is not very viable in high concurrency situations and should not be used in a cluster either. The purpose of this chapter is to
|
||||
show you how to connect {{book.project.name}} to a more mature database.
|
||||
|
||||
{{book.project.name}} uses two layered technologies to persist its relational data. The bottom layered technology is JDBC. JDBC
|
||||
|
|
|
@ -4,13 +4,13 @@
|
|||
|
||||
In the upcoming chapters, you'll often be provided two options for applying application server configuration changes to your deployment. You'll be
|
||||
shown how to edit the _standalone.xml_ or _domain.xml_ directly. This must be done when the server (or servers) are offline.
|
||||
Additionally, you may be shown how to apply config changes on a running server using the app server's command line interface ({{books.appserver.name}} CLI). This chapter discusses
|
||||
Additionally, you may be shown how to apply config changes on a running server using the app server's command line interface ({{book.appserver.name}} CLI). This chapter discusses
|
||||
how you will do this.
|
||||
|
||||
|
||||
=== Start the {{book.appserver.name}} CLI
|
||||
|
||||
To start the {{books.appserver.name}} CLI, you need to run the `jboss-cli` script.
|
||||
To start the {{book.appserver.name}} CLI, you need to run the `jboss-cli` script.
|
||||
|
||||
.Linux/Unix
|
||||
[source]
|
||||
|
|
|
@ -19,7 +19,7 @@ $ standalone.sh -b 192.168.0.5
|
|||
The `-b` switch sets the IP bind address for any public interfaces.
|
||||
|
||||
Alternatively, if you don't want to set the bind address at the command line, you can edit the profile configuration of your deployment.
|
||||
Open up the profile configuration file (_standalone.xml or _domain.xml_ depending on your
|
||||
Open up the profile configuration file (_standalone.xml_ or _domain.xml_ depending on your
|
||||
<<fake/../../operating-mode.adoc#_operating-mode, operating mode>>) and look for the `interfaces` XML block.
|
||||
|
||||
[source,xml]
|
||||
|
|
Loading…
Reference in a new issue