Standalone.xml

Zuletzt geändert von Form-Solutions GmbH am 18.01.2024

Um sicher zustellen, dass der WildFly Server korrekt funktioniert, sollten noch Änderungen an der Konfigurationsdatei

/opt/wildfly/standalone/configuration/standalone.xml

vorgenommen werden.

HTTP-Listener

Der default http-listener muss so konfiguriert werden, dass bei Proxy-Aufrufen die Adressen weitergeleitet werden. Zusätzlich kann die max-post-size und die max-parameters nach Ihren Bedürfnissen eingestellt werden. Folgendes Beispiel bildet unsere aktuellen Empfehlungen ab:

<http-listener
name="default"
proxy-address-forwarding="true"
socket-binding="http"
redirect-socket="https"
max-post-size="157286400"
max-parameters="1500"
></http-listener>

Deployment Timeout

Da der Start des voll bestückten WildFly Servers länger als eine Minute dauern kann, muss ein entsprechender Timeout im Element <deployment-scanner> eingefügt werden, z. B. so:

<deployment-scanner
path="deployments"
relative-to="jboss.server.base.dir"
scan-interval="5000"
deployment-timeout="6000"
runtime-failure-causes-rollback="${jboss.deployment.scanner.rollback.on.failure:false}"
></deployment-scanner>

und die <system-properties> entsprechend erweitern:

<system-properties>
<property name="jboss.as.management.blocking.timeout" value="6000"></property>
</system-properties>

Security

Die sichere Ausführung von Regeln benötigt eine Erweiterung im Subsystem security-manager. Das Element deployment-permissions muss um ein minimum-set erweitert werden, sodass der gesamte Subsystem-Block folgendermaßen aussehen muss:

Vermeidung von Information-Disclosure

Zur unnötigen Ausgabe des Servernamens bzw. der Versionsnummer müssen unterhalb des Subsystem undertow:3.1 entfernt werden. Die zu löschenden Zeilen sind:

<filter-ref name="server-header"></filter-ref>
<filter-ref name="x-powered-by-header"></filter-ref>

sowie der Abschnitt

Generelles setzen von security-Flags (secure und http-only)

Zur generellen Setzung der security-Flags secure und http-only kann folgender Eintrag innerhalb des Subsystems undertow:3.1 innerhalb des Elements servlet-container ergänzt werden:

<session-cookie http-only="true" secure="true"></session-cookie>

Servertuning

Es ist möglich WildFly - falls physisch vorhanden - mehr Speicher zuzuteilen. Hierzu kann man die Datei

/opt/wildfly/bin/standalone.conf

öffnen und die Variable JAVA_OPTS entsprechend den Speicheranforderungen ändern. Standardmäßig sollte hier

if [ "x$JAVA_OPTS" = "x" ]; then
JAVA_OPTS="-server -Xms4g -Xmx10g -XX:MaxMetaspaceSize=4g
-Djava.net.preferIPv4Stack=true"
...
fi

ausreichen. Allerdings kann es je nach Anzahl der Kunden, die auf dem Server gehostet werden, nötig werden den initialen Heapspace (Parameter -Xms), den maximalen Heapspace (Parameter -Xmx) , den Metadaten-Speicher (-XX:MaxMetaspaceSize) und/oder die maximale Stack-Größe (-Xss) zu erhöhen bzw. zu verringern. Als Vergleichswert kann die Konfiguration unseres Produktivsystems mit

-Xms4g -Xmx10g -XX:MaxMetaspaceSize=4g

dienen.

Zusätzlich kann bei der Verwendung von open9j noch das Teilen von Klassen verwendet werden. Hierzu ergänzen Sie die obere Zeile um die folgenden Einträge: -Xshareclasses -Xscmx256M

Zusätzlich kann die Speicherverwaltung mit folgenden Parametern optimiert werden (angepasst für unsere Produktivwerte):

#Optimierung Speicherverteilung
JAVA_OPTS="$JAVA_OPTS -XX:ReservedCodeCacheSize=256m -XX:NewRatio=6"
#Optimierung GarbageCollection
JAVA_OPTS="$JAVA_OPTS -XX:+UseConcMarkSweepGC -XX:-UseCodeCacheFlushing"

Diese sind am Ende der Datei zu ergänzen.

Tags: