Request for including timeout info in registerSyncEnabledGeodatabase docs

[ReedHunter]

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

[Ting]

Hi Reed, thanks for reaching out. I understand the frustration to debug network issues. 

Here are a few things…

• Please don't hesitate to ask here on Esri Community, when you encounter a roadblock or want help on troubleshooting. Our engineers are constantly monitoring customer requests and aim to provide timely response.
  • For example, you can simply ask "my geodatabase sync job timeouts unexpectedly, can you help me to narrow down the problem", and we may have someone to help with your specific issue. It can potentially save you a lot of time.
• Currently, ArcGIS Runtime SDK for iOS version 100.15 is in long-term support release (LTS),  focused exclusively on bug fixes and minor updates. So we probably won't make changes unless there is an issue with the API itself.
  • ArcGIS Maps SDK for Swift version 200 is the new evolution of the API. Feel free to checkout it on the ArcGIS Developer website.
• In version 200, the equivalent to setting AGSRequestConfiguration.timeoutInterval is as follow

ArcGISEnvironment.urlSession = ArcGISURLSession {
    let defaultConfig = URLSessionConfiguration.default
    defaultConfig.timeoutIntervalForRequest = 100
    return defaultConfig
}

•  In version 200, we improved our API design by better following Apple's Swift API Design Guidelines. Which means to reduce using custom types that are equivalent to existing Apple types.
  • Hence in ArcGISURLSession doc, you'll find the configuration is using Apple's native URLSessionConfiguration.timeoutIntervalForRequest type. The doc mentions the default value is 60 (seconds).
  • It makes it easier to click into Apple's native doc in Xcode and inspect the details of a type.

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.

[Nicholas-Furness]

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.

[ReedHunter]

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.

[Nicholas-Furness]

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).