ROS only syncs once for read-only realms about realm-object-server HOT 16 CLOSED

Apologies for the confusion! The underlying issue is that we do not support "read-only" Realms yet and we need to make this explicit in the documentation.

The reason on why this is limited today, is that by default, when you open a Realm in the client SDK for the first time, it creates the Realm file locally, writing the schema to it. The writing of the schema is an operation that is then synced when the connection to the server is established. The problem though is that the server is assuming the client is read-only so it breaks the connections because incoming writes are not allowed.

To work around this for now, you should just use read/write permissions.

There is a more obscure way to work around it by opening a Realm in "dynamic" mode which skips writing the schema, but it is a private API. In addition, when using a dynamic Realm, you have to use string-based methods versus the type-safe ones. We use this in the Realm Browser, but have not promoted it publicly.

from realm-object-server.

Hi @nickharbin,

Could you provide the server logs, when you reproduce this issue? In addition, could you clarify which version of CentOS you are using? 6 or 7? Thanks

from realm-object-server.

Just a note, creating Realms with an admin user doesn't register them in the __admin Realm currently. I don't think that is causing the issue but wanted to point out.

from realm-object-server.

Hi @teotwaki,

I blew away the entire installation and started from scratch with logging set to 'all' and that log is attached. When I originally posted this issue yesterday I was using a CentOS 6 install in OpenVZ. I rebuilt the install with CentOS 7 to see if that made a difference. It did not.

The attached logs are from the CentOS 7 install. The only activity is starting the server and then running through the scenario outlined in my initial post.

The attached log is from /var/log/realm-object-server.log. Let me know if there is anything else you would need.

realm-object-server.txt

from realm-object-server.

Hello @nickharbin,

There are multiple things happening in the logs, but I noticed the following:
The admin token is the one ending in '...Of/aexc94pJDfuBMOuLo7S8fBm+w=='.
Some of the connections open 2 sessions, one for their own path "/~/realmName" and a second one for "/rundlc". Only that the token used to access "/rundlc" is not the admin token(line 57 in the logs). Could you please share the code used to create the two realms?

Thank you!

from realm-object-server.

Hi @radu-tutueanu ,

I am creating the /rundlc realm by signing in to my app as the server admin, using the username and password I created when installing the ROS, the first time I run the app. This also creates the /~/realmName for the admin user (all code is posted below)

I then delete the app and rerun it signing in as a standard user. The same code runs where the standard user connects to the /rundlc realm and also connects to, and thus creates, his own /~/realmName file.

All connections should open two sessions, one to /rundlc and one to /~/realmName, except for when the Realm Object Browser is the one connecting. I connect with that to test whether changes made are making it down to the iOS client.

This code creates/accesses the realm files:
Note: the RealmManager.shared.user is the SyncUser from when the user authenticated or the user existing at SyncUser.all().first (which has only ever contained one user)

   func defaultRealm(with notificationBlock: @escaping NotificationBlock) -> (realm: Realm, token: NotificationToken)
    {
       // baseConnectionURL() points to /rundlc
        let config = Realm.Configuration(syncConfiguration: (RealmManager.shared.user!, Settings.baseConnectionURL()), objectTypes: [Song.self, Score.self])

        let realm = try! Realm(configuration: config)

        let token = realm.addNotificationBlock(notificationBlock)

        return (realm: realm, token: token)
    }

    func userRealm(with notificationBlock: @escaping NotificationBlock) -> (realm: Realm, token: NotificationToken)
    {
        // userConnectionURL() points to /~/realmName
        let config = Realm.Configuration(syncConfiguration: (RealmManager.shared.user!, Settings.userConnectionURL()), objectTypes: [Song.self, Score.self])

        let realm = try! Realm(configuration: config)

        let token = realm.addNotificationBlock(notificationBlock)

        return (realm: realm, token: token)
    }

This code runs in the viewDidLoad method of the view controller presented after a successful login.

Thanks for looking into this for me and let me know if you need anything else.

from realm-object-server.

I did some tests over this weekend and I was able to reproduce this behavior with the iOS demo app included in the macOS download.

I modified the demo app to point to my centOS 7 install of the ROS and then changed the line below:

static let syncServerURL = NSURL(string: "realm://\(syncHost):9080/\(syncRealmPath)")

Notice I changed the demo app to point to a realm file in / instead of /~/.

I then started the app and logged in as my server admin and created a couple tasks.

I deleted the app and reinstalled, this time signing in as a standard user. The same behavior outlined above occurred. Changes to the realm were only communicated when the app was first opened and then the connection was closed. Once I made the standard user a server admin the app behaved as intended.

I thought I'd let you know since this is a much easier way to reproduce this issue. Let me know if you need any more information.

from realm-object-server.

Thank you a lot for taking the trouble to reproduce this using the RealmTasks app.
There is indeed a bug into how read-only realms( in / for regular users) sync. We will be working on fixing it.

from realm-object-server.

@nickharbin,

Could you confirm that the latest version of the SDK doesn't have this issue anymore?

Thanks

from realm-object-server.

Closing due to inactivity.

from realm-object-server.

Please can this item be re-opened.

I am experiencing this issue.

I had previously been experiencing this issue on a platform that had been through several upgrades. Seeing as I was only "playing" I thought I'd burn the server and start over.

What I did not expect was the same behaviour after installing everything from scratch using the new v1 release (Ubuntu 16 / Swift 2.3.0 / Server 1.0.0).

The behaviour is that data is synced on first connection to the ROS - but no further syncs occur. Only restarting the app causes another - and only 1 - sync.

I have attached a segment of log from just before to just after the issue occurring.
ROS Log ros.domain.com.txt

from realm-object-server.

Thanks @bigfish24 - this is important information and is going to throw a spanner at my project. But I appreciate this is really early days so I blame myself for not realising sooner.

I've looked in the issues list for a T:Feature that I can follow to keep an eye on this. But I can't see one. Can one be added?

Of course I'm going to have to ask..... when? But I'll wait to ask in the right place. ;)

from realm-object-server.

@ianbradbury-bizzibody I am truly sorry this is coming up now. I can't commit to a timeline right now, but will hopefully be able to have more details later in the week/early next week. We know this is a major issue and we will be fixing it. What is your timeline on when you need it fixed?

from realm-object-server.

Fortunately it's just a hobby project. I figure I can continue working away and not worry about his for a while. If it could be delivered some time in the next 3 months that would be really really great. (But I recognise the pressure you are all under)

from realm-object-server.

@ianbradbury-bizzibody I think that is a pretty reasonable assumption, definitely is a requested feature since dev teams want to control errant write access, even in just development.

from realm-object-server.

This has been fixed in realm/realm-swift#4910.

Note that if a sync user ever has the possibility of only having read access to a Realm, the only safe way to access that Realm is through the asyncOpen API. This is because the synchronous API provides access to the Realm immediately (yay offline-first!), which eagerly writes some metadata information to the Realm (e.g. schema), which then fails if the server rejects the changes due to insufficient permissions.

from realm-object-server.