Please update the docs for the registerSyncEnabledGeodatabase to mention that timeouts for that command can be fixed by adjusting the timeoutInterval property of AGSRequestConfiguration. The default is 60 seconds, and much time was lost determining whether the timeout was coming from the OS, the server, or the Runtime SDK. Increasing the timeoutInterval property allows for a more forgiving client when a field crew is on a slow network, or once the organization's feature service becomes big enough to start slowing down. Any mention in the docs of controlling registerSyncEnabledGeodatabase through AGSRequestConfiguration would have saved us a lot of time.
The registerSyncEnabledGeodatabase command is a client-side wrapper around a call to the ArcGIS Server "createReplica" command, one of the functions of a sync-enabled feature service. I confirmed through REST endpoint tests after watching web traffic through a Fiddler proxy that the createReplica service itself was well past 70 seconds response time, and that the response content was successful and valid.
This can affect any organization that uses the preplanned disconnected editing workflow once their geodatabase, feature service, and number of users reaches high enough maturity to slow down registration past the default timeout of 60 seconds. For reference, my organization has ~1000 field data collection devices, just over 100 feature classes, an enterprise geodatabase that has been around for about a year, about 500,000 features, and just over 5000 replicas. We support nightly automatic creation of the latest preplanned offline geodatabase for download, and we typically see about one to two thousand syncs per week. When we first deployed, offline geodatabase registration never reached 60 seconds, though it would be an issue from some field offices with slow network connections. Current speed of the createReplica command for our production service is about 80 seconds.
Thank you
-Reed
Hi Reed, thanks for reaching out. I understand the frustration to debug network issues.
Here are a few things…
ArcGISEnvironment.urlSession = ArcGISURLSession {
let defaultConfig = URLSessionConfiguration.default
defaultConfig.timeoutIntervalForRequest = 100
return defaultConfig
}
Because the timeout setting is an Apple type (TimeInterval) now, we won't be able to add doc to it. However, we'll take note of your suggestion, and improve our documentation in the new API.
We'll probably add an article on the developer website, or in API reference doc, to explain the considerations on configuring the network requests in ArcGIS.
Hi @ReedHunter.
Which version of Runtime are you using? As of 100.13 we should be resilient to long register operations on the server and I'm surprised you're seeing timeouts there.
Hi Nicholas,
I'm uncertain now which version since I'm no longer the GIS developer on that project, but I know that it's older than 100.13. What was nice to discover was that even with that older version it was possible to make it more flexible with AGSRequestConfiguration.
My colleague in charge of the project will be upgrading to 100.15 in the next release.
Aha. Ok. I expect that at 100.15 you will not need any additional config on AGSRequestConfiguration because at 100.13 we changed how we register a replica behind the scenes.
The service supports two methods of registration. A direct HTTP request to register which doesn't respond until the registration has completed (this is what 100.12 and earlier did), and a job-based approach where the initial request just starts a job and returns immediately, and then we poll the job until it completes or errors (this is what 100.13 and later do). We do all that job monitoring behind the scenes using the same API (i.e. your code wouldn't change). So while the Runtime API call to register might not return for a long time, as of 100.13 it's not making just one long HTTP call, but lots of very lightweight and quick-to-respond status request calls. See the async property in the REST API doc.
We made this change for precisely the reason you describe (registering can require back-end database locks which can lead to unpredictable registration times, so the job approach is the only reliable one).