Retry deployment in case of missing/failed dependencies
124 views
Skip to first unread message
Mario-Luca Hoffmann
Apr 9, 2024, 10:51:34 AM4/9/24
to WildFly
Hi there!
I basically asked the same question already on serverfault.com, but that was, unfortunately, not successful yet.
The problem is the following:
One of our customers has scheduled restarts and updates for their servers. This includes their SQL server and our server hosting WildFly (currently: 29.0.0.Final).
When these restarts happen, our server is faster to reboot than the SQL server is leading to a deployment error for our software:
2024-03-26 01:51:00,009 INFO [org.jboss.as.server] (ServerService Thread Pool -- 46) WFLYSRV0010: Deployed "no.war" (runtime-name : "no.war") 2024-03-26 01:51:00,013 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report WFLYCTL0186: Services which failed to start: service jboss.persistenceunit."no.war#xxxPU": jakarta.persistence.PersistenceException: [PersistenceUnit: xxxPU] Unable to build Hibernate SessionFactory WFLYCTL0448: 170 additional services are down due to their dependencies being missing or failed
However, the server doesn't recover from this state until I manually redeploy or restart WildFly. Is there any way to avoid this outcome to have the server itself retrying the deployment?
I might be just searching with the wrong keywords or maybe even at the wrong place. Any help would be much appreciated!
- Mario
I basically asked the same question already on serverfault.com, but that was, unfortunately, not successful yet.
The problem is the following:
One of our customers has scheduled restarts and updates for their servers. This includes their SQL server and our server hosting WildFly (currently: 29.0.0.Final).
When these restarts happen, our server is faster to reboot than the SQL server is leading to a deployment error for our software:
2024-03-26 01:51:00,009 INFO [org.jboss.as.server] (ServerService Thread Pool -- 46) WFLYSRV0010: Deployed "no.war" (runtime-name : "no.war") 2024-03-26 01:51:00,013 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report WFLYCTL0186: Services which failed to start: service jboss.persistenceunit."no.war#xxxPU": jakarta.persistence.PersistenceException: [PersistenceUnit: xxxPU] Unable to build Hibernate SessionFactory WFLYCTL0448: 170 additional services are down due to their dependencies being missing or failed
However, the server doesn't recover from this state until I manually redeploy or restart WildFly. Is there any way to avoid this outcome to have the server itself retrying the deployment?
I might be just searching with the wrong keywords or maybe even at the wrong place. Any help would be much appreciated!
- Mario
Bartosz Baranowski
Apr 11, 2024, 3:57:28 AM4/11/24
to WildFly
Well. For starter - you might consider filing and working on RFE to bring such functionality into WFLY.
Meanwhile, you can check https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html#%5BUnit%5D%20Section%20Options
Either create dependency or provide custom script to for instance - restart WFLY after SQL boots up
Meanwhile, you can check https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html#%5BUnit%5D%20Section%20Options
Either create dependency or provide custom script to for instance - restart WFLY after SQL boots up
Bartosz Baranowski
Apr 11, 2024, 4:05:35 AM4/11/24
to WildFly
https://www.mastertheboss.com/jbossas/jboss-deploy/how-to-deploy-applications-on-wildfly/
When running in auto-deploy mode, the scanner will directly monitor the deployment content, automatically deploying new content and redeploying content whose timestamp has changed. This is similar to the behavior of previous JBoss AS releases, except that the deployment scanner will not monitor any more changes in deployment descriptors, since Java EE 6/7 applications do not require deployment descriptors.
Also DU.failed witll contain info( AFAIR) so you can monitor it and act upon ie SQL boot is done.
When running in auto-deploy mode, the scanner will directly monitor the deployment content, automatically deploying new content and redeploying content whose timestamp has changed. This is similar to the behavior of previous JBoss AS releases, except that the deployment scanner will not monitor any more changes in deployment descriptors, since Java EE 6/7 applications do not require deployment descriptors.
Also DU.failed witll contain info( AFAIR) so you can monitor it and act upon ie SQL boot is done.
Reply all
Reply to author
Forward
0 new messages