Problem with liveness probe

[Knut-Håvard Aksnes]

We do have discovered a problem with the liveness probe in wildfly 36.Due to a bug in our code we were able to trigger a weakness in hibernate. The consequence of this was that jpa initialization sometimes failed leading to fa8lure in ear startup. Our deployment is a single jar deployment. The problem being that health reports this as a readiness problem not a liveness problem. This problem isn't of a transient nature and I expected it to be reported as a liveness problem.

[Scott Marlow]

Shouldn't the readiness problem go away when the application deployment completes?

On Mon, Aug 25, 2025 at 5:19 AM Knut-Håvard Aksnes <khak...@gmail.com> wrote:

We do have discovered a problem with the liveness probe in wildfly 36.Due to a bug in our code we were able to trigger a weakness in hibernate. The consequence of this was that jpa initialization sometimes failed leading to fa8lure in ear startup. Our deployment is a single jar deployment. The problem being that health reports this as a readiness problem not a liveness problem. This problem isn't of a transient nature and I expected it to be reported as a liveness problem.

--
You received this message because you are subscribed to the Google Groups "WildFly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/wildfly/CAJuwR1WnirqcTJwjJhr25xJBU_UDLXd9DBM1rb_3XVXs3rYLWw%40mail.gmail.com.

[Knut-Håvard Aksnes]

The problem is that when deployment fails health reports the system to be live but not ready, this could possibly  be right in case the deployment would automatically retry or similar but defeats the purpose of the health check when using them for liveness and readiness probes in kubernetes. An OK example of reporting live but not ready would be a temporary loss of connection to a datasource where the application can automatically recover when connection to the database is reestablished. In our case we want a pod restart when deployment fails. We can achieve  this in a roundabout way by adding a startup probe in kubernetes using /health/ready but that is a hack.

[Scott Marlow]

On Wed, Aug 27, 2025 at 4:57 AM Knut-Håvard Aksnes <khak...@gmail.com> wrote:

The problem is that when deployment fails health reports the system to be live but not ready, this could possibly  be right in case the deployment would automatically retry or similar but defeats the purpose of the health check when using them for liveness and readiness probes in kubernetes. An OK example of reporting live but not ready would be a temporary loss of connection to a datasource where the application can automatically recover when connection to the database is reestablished. In our case we want a pod restart when deployment fails. We can achieve  this in a roundabout way by adding a startup probe in kubernetes using /health/ready but that is a hack.

Try specifying the Hibernate ORM dialect in each persistence unit definition as I think that might help avoid the need to connect to the database during deployment.  The persistence unit property name would be "hibernate.dialect" and the value would be the actual dialect name to use.

There is some guidance in https://github.com/hibernate/hibernate-orm/blob/main/hibernate-core/src/main/java/org/hibernate/cfg/JdbcSettings.java#L214 that recommends letting Hibernate figure out the dialect but that requires getting the (JDBC) database metadata which is not going to work during deployment if the database is not available.

 

On Tuesday, August 26, 2025 at 8:44:31 PM UTC+2 Scott Marlow wrote:

Shouldn't the readiness problem go away when the application deployment completes?

On Mon, Aug 25, 2025 at 5:19 AM Knut-Håvard Aksnes <khak...@gmail.com> wrote:

We do have discovered a problem with the liveness probe in wildfly 36.Due to a bug in our code we were able to trigger a weakness in hibernate. The consequence of this was that jpa initialization sometimes failed leading to fa8lure in ear startup. Our deployment is a single jar deployment. The problem being that health reports this as a readiness problem not a liveness problem. This problem isn't of a transient nature and I expected it to be reported as a liveness problem.

--
You received this message because you are subscribed to the Google Groups "WildFly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/wildfly/CAJuwR1WnirqcTJwjJhr25xJBU_UDLXd9DBM1rb_3XVXs3rYLWw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "WildFly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/wildfly/aa4702aa-45c0-4ed4-a357-bed5e4fbe3afn%40googlegroups.com.