microstream-one
Azure Files: StorageExceptionConsistency
Environment Details
- MicroStream Version: 07.01.00-MS-GA
- JDK version: 17
- OS: Linux
- Used frameworks: Vaadin 23.2.6 with Spring Boot 2.7.4
Describe the bug
We have deployed a Vaadin App on Azure App Services that is configured to work with Microstream in the following way:
We mounted a Azure Files Storage Account in to the App Service's container (e.g at /data/microstream) so we can read and write to the storage using Local File System. All is working fine until we update the container with a new version of our Vaadin application (deployed as .war on tomcat). Mostly it works as intended and Microstream picks up the existing storage correctly, but sometimes (we unfortunately cant figure out why it happens) the storage gets corrupted and we can only see the following error message:
Why is this happening and is there a way to prevent/fix this ?
To Reproduce
- create Azure Account
- create App Service on Azure and deploy Sample Vaadin App with Storage pointing to /data/microstream/storage
- create Storage Account on Azure and add a File Share named "microstream"
- in App Services navigate to Configuration -> Path Mapping, select the Storage Account and File Share and map it to /data/microstream
- redeploy app multiple times until the error happens
Expected behavior
That microstream can successfully initiate using the existing database that is stored inside the Azure Files Storage mounted to the App Service
Hello, From the exception, it seems that a write operation to the second channel was not done.
As this exception is thrown at startup after the deployment it may be possible that there was an exception during the shutdown of the “old” storage. Maybe you can check you logs for other Microstream exception. (For logging Microstream please see https://docs.microstream.one/manual/misc/logging/index.html)
Another cause for the problem may be another storage process trying to access the storage files while a storage is still active. You may check is if the “old” process has really stopped the storage before the newly deployed app tries to access the storage. The best way to shut down a storage is calling the ‘StorageManager.shutdown()’ method and waiting until that method returns.
