Some time ago, an application of mine that is deployed in the Pivotal Cloudfoundry began throwing errors and crashed:
There have been no prior changes on the application or the setup.
Because the error occurred on a live application, I tried restarting it without looking too much into the cause of the problem. It was important to have this application live again as soon as possible. However, restarting failed with the same error.
In step two, I suspected Spring to not have enough resources, so I raised both “memory allocated” and “disk allowed”, without effect.
At that time, I began looking into the log in more detail. The failed connection / “connection refused” pointed to the database because it is the only service for that application. I thought that the health-check prevented startup of the application because the connection to the database could not be established fast enough. Raising the health-check timeout to 10 minutes also did not work.
At that point, it is worth mentioning that my application uses Liquibase. Googling for the multiple “Waiting for changelog lock” brought me to this article which suggested that Liquibase locked the database. Indeed, a
returned
Unlocking it with
brought the application back up.
Researching for the reason did not bring a specific and reproducible result. I found hints to the fact that when the application is stopped, Liquibase sometimes keeps the lock. However, that would not explain why the app was restarted in the first place.
I decided not to go into further research because this incident was the first problem with Liquibase and nothing really bad happened. Sadly, there are no build-in notifications for crashes like this in Cloudfoundry.
TL;DR
If you see “Waiting for changelog lock….” multiple times during startup of your Liquibase-using application, check if your database is unlocked.