WildFly-Deployment-Timeout erhöhen und Schema-Update steuern

Ziel ist, lange Startphasen während des Deployments der ece.ear in WildFly stabil abzufangen und das Verhalten des Datenbank-Schema-Updates gezielt zu steuern. Hierfür gibt es zwei Stellhebel:

Deployment-Timeout im Deployment-Scanner anheben, damit langlaufende Initialisierungen nicht abbrechen.
Hibernate DDL-Aktion über eine System-Property steuern (none/validate/update/create/create-drop).

Wann braucht man das?

Typische Symptome bei zu niedrigem Timeout oder unpassender DDL-Einstellung:

WildFly-Log enthält Meldung WFLYDS0022 (Deployment-Operation überschreitet Timeout).
Die Anwendung meldet ece.ear.failed nach dem Startversuch.
Sehr lange Datenbankmigrationen/Initialisierungen (z. B. bei Erstinstallation oder großen Updates).

Lösung A: Deployment-Timeout im Deployment-Scanner erhöhen

In der WildFly-Konfiguration (standalone.xml) kann für den Deployment-Scanner ein größeres Timeout gesetzt werden. Beispiel mit 1200 Sekunden:

XML

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

Parameter-Erklärung:

Deployment-timeout: Maximale Wartezeit in Sekunden, bis ein Deployment-Vorgang als fehlgeschlagen gilt. Erhöhen bei langen Start-/Migrationsphasen.
Scan-Interval: Intervall in Millisekunden, in dem der Scanner das Verzeichnis auf neue/aktualisierte Deployments prüft.
Runtime-Failure-Causes-Rollback: Steuert, ob bei Laufzeitfehlern ein Rollback des Deployments erfolgt.

Praxiswert: 1200 Sekunden (20 Minuten) hat sich für Umgebungen mit langsamen Datenbank-Operationen bewährt.

Lösung B: DB-Update-Verhalten beim Start steuern (updateDB / hibernate.hbm2ddl.auto)

Das Verhalten der Schemaaktualisierung wird über die Hibernate-Eigenschaft hibernate.hbm2ddl.auto gesteuert. In der persistence.xml ist sie an eine System-Property gebunden:

XML

<!-- none, validate, update, create, create-drop -->
<property name="hibernate.hbm2ddl.auto" value="${updateDB}"/>

Die System-Property wird in standalone.xml gesetzt:

XML

<system-properties>
  <property name="resteasy.preferJacksonOverJsonB" value="true"/>
  <property name="jboss.as.management.blocking.timeout" value="3600"/>
  <!-- used for hibernate.hbm2ddl.auto in ece.ear\ece-services.jar\META-INF\persistence.xml -->
  <property name="updateDB" value="update"/>
</system-properties>

Erlaubte Werte und Wirkung:

Wert	Beschreibung	Empfohlen für
none	Keine Schemaaktion. Existiert die DB-Struktur nicht, schlägt der Start später an anderer Stelle fehl.	Sonderfälle/Manuell gemanagte Schemas
validate	Validiert das Schema gegen die Entitäten. Bei Abweichungen FEHLER und Deployment-Abbruch.	Große Datenbanken, bei denen der Neustart von Wildfly mit update zu lange dauert.
update	Aktualisiert das Schema nicht-destruktiv (Tabellen/Spalten anlegen/ändern, soweit möglich).	Default für Erstinstallation und reguläre Updates
create / create-drop	Erzeugt das Schema neu (optional mit Drop am Ende). Datenverlust möglich!	Nur in Test-/Entwicklungsumgebungen

Empfohlene Defaults: Update für Erstinstallation und normale Updates. Validate kann temporär für Fehlersuche genutzt werden; es lässt das Deployment bewusst fehlschlagen, wenn das Schema nicht passt.

Beispiel für einen typischen Validierungsfehler (verkürzt): fehlende Spalte optlock in Tabelle ECE_DAEMONCONFIG – das Deployment bricht ab, solange updateDB=validate gesetzt ist.

Schritt-für-Schritt-Anleitung

WildFly stoppen.
In standalone.xml den deployment-scanner-Abschnitt anpassen und ein ausreichendes deployment-timeout setzen (z. B. 1200).
Im Block <system-properties> die Property updateDB auf den gewünschten Modus setzen (empfohlen: update).
WildFly starten und Logs beobachten. Bei sehr langen Starts das Timeout ggf. weiter erhöhen.
Bei Schemafehlern unter validate auf update wechseln oder Schema manuell anpassen.

Security und Best-Practices

Änderungen an standalone.xml versionskontrolliert dokumentieren und mit Change-Request freigeben.
Rollback-Plan bereithalten (Backup der ursprünglichen Konfiguration, DB-Backup vor größeren Änderungen).
Produktivwerte zunächst in Staging testen und mit realistischen Datenvolumina verifizieren.