Increase the WildFly deployment timeout and control schema updates

The goal is to reliably handle long startup phases during the deployment of ece.ear in WildFly and to specifically control the behavior of the database schema update. There are two levers for this:

Increase deployment timeout in the deployment scanner to prevent long-running initializations from being aborted.
Control Hibernate DDL action via a system property (none/validate/update/create/create-drop).

When is it needed?

Typical symptoms of too low timeout or inappropriate DDL setting:

WildFly log contains message WFLYDS0022 (Deployment operation exceeds timeout).
The application reports ece.ear.failed after the startup attempt.
Very long database migrations/initializations (e.g., during first installation or major updates).

Solution A: Increase Deployment Timeout in Deployment Scanner

In the WildFly configuration (standalone.xml), a longer timeout can be set for the deployment scanner. Example with 1200 seconds:

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 explanation:

Deployment timeout: Maximum waiting time in seconds until a deployment process is considered failed. Increase for long startup/migration phases.
Scan interval: Interval in milliseconds at which the scanner checks the directory for new/updated deployments.
Runtime failure causes rollback: Controls whether a rollback of the deployment occurs in case of runtime errors.

Practical value: 1200 seconds (20 minutes) has proven effective for environments with slow database operations.

Solution B: Control DB Update Behavior at Startup (updateDB / hibernate.hbm2ddl.auto)

The schema update behavior is controlled via the Hibernate property hibernate.hbm2ddl.auto. In the persistence.xml it is bound to a system property:

XML

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

The system property is set in standalone.xml:

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>

Allowed values and effect:

Value	Description	Recommended for
none	No schema action. If the DB structure does not exist, startup will fail later elsewhere.	Special cases/manually managed schemas
validate	Validates the schema against the entities. On discrepancies, ERROR and deployment abort.	WildFly
update	Updates the schema non-destructively (create/alter tables/columns as far as possible).	Default for initial installation and regular updates
create / create-drop	Recreates the schema (optionally with a drop at the end). Data loss possible!	Only in test/development environments

Recommended defaults: Update for initial installation and normal updates. Validate can be temporarily used for troubleshooting; it deliberately causes deployment to fail if the schema does not match.

Example of a typical validation error (shortened): missing column optlock in table ECE_DAEMONCONFIG – deployment aborts as long as updateDB=validate is set.

Step-by-Step Guide

Stop WildFly.
In standalone.xml adjust the deployment-scanner section and set a sufficient deployment-timeout (e.g., 1200).
In the block <system-properties> set the property updateDB to the desired mode (recommended: update).
Start WildFly and monitor logs. If startup takes very long, increase the timeout if necessary.
For schema errors under validate switch to update or adjust the schema manually.

Security and Best Practices

Document changes to standalone.xml under version control and approve with a change request.
Have a rollback plan ready (backup of the original configuration, database backup before major changes).
First test production values in staging and verify with realistic data volumes.