microstream-one / microstream

High-Performance Java-Native-Persistence. Store and load any Java Object Graph or Subgraphs partially, Relieved of Heavy-weight JPA. Microsecond Response Time. Ultra-High Throughput. Minimum of Latencies. Create Ultra-Fast In-Memory Database Applications & Microservices.
https://microstream.one/
Eclipse Public License 2.0
560 stars 44 forks source link

Azure Files: StorageExceptionConsistency #468

Open JustinVoitel opened 1 year ago

JustinVoitel commented 1 year ago

Environment Details

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

Why is this happening and is there a way to prevent/fix this ?

To Reproduce

Expected behavior

That microstream can successfully initiate using the existing database that is stored inside the Azure Files Storage mounted to the App Service

hg-ms commented 1 year ago

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.