Realm file persistence on azure asp.net


#1

@nirinchev
Do you know where or how realm files are persisted when syncing on an asp.net app on azure?
I’m trying to confirm that we’re not doing a full realms transfer on every connection from azure, but only deltas. At least as often as we can.

see https://github.com/projectkudu/kudu/wiki/File-structure-on-azure


#2

I’ll need some more info to be able to give you accurate guidance here.

  1. Is your asp.net app using Realm purely as a client - i.e. it uses just the Realm package and not Realm.Server?
  2. How are you opening Realms? I’m guessing ROS is hosted somewhere on cloud.realm.io and you log in as an admin user, open a Realm file, read/write data, then dispose the Realm file?
  3. How are you hosting your asp.net app - are you using a VM or some of the myriad of hosting services?

And just as a general guidance - as long as there’s a persistent volume (that survives a container restart/service redeployment) and you store the Realm files there, you should never need to redownload the Realm. You can check config.DatabasePath to see where the local Realm will be stored - if the default location turns out to be on a transient volume, you can override that by specifying the optionalPath argument in the SyncConfiguration constructor.


#3

@nirinchev

  1. Yes.
  2. Yes, but I don’t do anything specific to dispose of the underlying realm file. Not that I know of. Hence my question.
  3. On a Standard Service Plan on Azure, S1: https://azure.microsoft.com/en-us/pricing/details/app-service/windows/

You can check config.DatabasePath to see where the local Realm will be stored - if the default location turns out to be on a transient volume, you can override that by specifying the optionalPath argument in the SyncConfiguration constructor.

Got it!


#4

Judging by the docs, you should be good as long as you store the Realm files inside a persisted folder (i.e. some folder under wwwroot). As for disposing - I meant disposing the managed Realm instance - I recommend doing that (if you aren’t already) after you’re done with it, otherwise you risk some unwanted file size growth.


#5

I am. Now I know why :slight_smile: Again, thank you for your support!


#6

You’re most welcome :raised_hands:


#7

@nirinchev
I’m getting this asp.net core MKDIR error on LoginAdminAsync :
2018-07-05 20:47:31.338 +00:00 [ERR] Unable to login as TodoApp admin

Realms.Exceptions.RealmException: make_dir() failed: Permission denied
at Realms.NativeException.ThrowIfNecessary(Func2 overrider) at Realms.Sync.SharedRealmHandleExtensions.ConfigureFileSystem(Nullable1 userPersistenceMode, Byte[] encryptionKey, Boolean resetMetadataOnError, String basePath)
at Realms.Sync.SharedRealmHandleExtensions.DoInitialFileSystemConfiguration()

in this DoInitialFileSystemConfiguration - and therefore only the first time after publish. Any ideas? Theres no optionalPath I can configure for this.

With SyncConfiguration however, I managed to specify a valid path and I can see the folder populated by files. I only see:

  • default.realm
  • default.lock
  • default.realm.management folder

even though I’ve successfully synced with another realm on in the realm cloud. Is this as it should be?


#8

Unfortunately, the FileSystem configuration error is legitimate one and should be addressed. I’ll expose a configuration option and send you the prerelease package that will hopefully resolve it. I hope to have something in a few hours.

For your second question - it’s surprising that you don’t see the other Realm in that folder though - can you share the code that you use to open the non-default Realm?


#9

Here are the packages that include the API changes that will allow you to specify the base folder:

Realm.nupkg
Realm.Database.nupkg

Once you install them in your app, you’ll need to add this call before you interact with any other Realm API:

User.ConfigurePersistence(UserPersistenceMode.NotEncrypted, basePath: "path-to-wwwroot/data/realm");

#10

We’ve moved to ubuntu on Digital Ocean. The price performance difference is big!