This is not a bug.
It’s just that I’ve noticed CB Lite is very slow detecting the client going offline.
[Environment is C#, Mac and iOS]
In my limited tests… if there is no active syncing going on and I pull the plug, it takes more than 4-5 minutes for the client to generate offline status callback. When the network is reconnected it notices quickly.
If I generate a change to force some syncing traffic, it still takes 1.5-2 minutes before generating an offline status callback. Again, I quickly get the “syncing” callback when the connection is restored.
Lite is very slow to notice network drops, although it is operating correctly.
In comparison - on the Mac, dropbox always reacts instantly to network status changes.
Is there some setting or timeout value I can change to speed this up the response?
Thx.
Paul
Its not expected. Could you please provide more information on the CBL library(CouchbaseLiteSwift, CouchbaseLite)? which version of CBL using? simulator or device. More details on the iOS version? Also is this consistently happening?
Execution/Dev environment on the Mac is:
C#, Mac (10.15.6), CBL 2.7.1, Latest stable Visual Studio.
It does seem very consistent. Our QA guy raised it on his mac (mac mini 10.15.6).
I confirmed this on my mac (MBP 10.15.6) earlier this week. Overnight my mac updated to 10.15.7,
so I retested and its still happening.
It does not occur on our iOS app which reacts very quickly to airplane mode. Apologies, didn’t mean to list that.
The native Mac (Obj-C or Swift) CBL should detect this immediately. The .NET version has the extra complexity of having to implement offline checking for multiple platforms, and it may not be doing it the same way. Any ideas, @Sandy_Chuang or @borrrden ?
@jens is right, .Net CBL has offline checking depends on how each platform response to the network disconnection. Before replication reporting offline, CBL will first check if the platform offline error is transient or permanent. If the offline error is transient, CBL will report replication offline.
Additional note, the upcoming 2.8 release, which will be out around mid or end of Oct, has made some improvement on that area. Please feel free to check it out when it’s out.
Just a note: I’ve been experimenting with System.Net.NetworkInformation:
NetworkChange.NetworkAvailabilityChanged += (object sender, NetworkAvailabilityEventArgs e) =>
{
if (!e.IsAvailable)
UpdateSyncStatus(SyncStatus.Error, "Network is not available");
};
It sometimes responds very quickly to network status changes on the mac, and sometimes not at all.
Xamarin.Essentials has a connectivity class - but you can’t use it because it requires “xam.plugin.connectivity”.
Using “Xam.Plugin.Connectivity” directly works very well. The final result is:
CrossConnectivity.Current.ConnectivityChanged += (object sender, Plugin.Connectivity.Abstractions.ConnectivityChangedEventArgs args) =>
{
if (!args.IsConnected)
UpdateSyncStatus(SyncStatus.Error, "Network is not available");
else {
lastStatus = SyncStatus.Idle;
UpdateSyncStatus(SyncStatus.Idle, "Idle");
}
};
Last thing: my little “lastStatus” hack above is because there is a small inconsistency (I think) in CBL’s use of the Idle status. The sequence of calls to Sync status callback when syncing is:
in progress
in progress
idle
So it appears that idle represents a status.
However the sequence of calls when there is a password failure or network failure is:
error
idle
In reality - the idle here just means its given up. The connection is still in an error state.
So you need to keep the last state whenever “idle” arrives to know what that idle actually means - i.e. have I completed a sync operation or have I given up and am still in an error state?