"Timeout exceeded" When Change Hosted Feature Layer Settings

[cle444]

Call for Enterprise / Portal experts!

Use Case:
10.9.0 Enterprise. A hosted feature layer that contains 59 empty layers, no editing tracking fields. Under [Settings] on Portal, I am trying to add the option of "Keep track of who created and last updated features".

Issue:
Got error message "Timeout exceeded" on Portal.

From my obversation, by adding and saving the option in the portal item settings, it triggers an HTTP POST call to: 

/<webapdter>/rest/admin/services/Hosted/Property_Data_Master_Timeout6/FeatureServer/updateDefinition

After 60 seconds, the Portal page shows the error message "Timeout exceeded" as shown above. However, there is no response from the HTTP call from the dev tool. According to the "updateDefinition" in this ArcGIS documentation, I am expecting a response either succeeds or fails.

BUG-000135047 from ESRI shows a similar issue for a hosted feature service with 60+ layers, but in my case, it is 59. I suspect it is the same issue with an inaccurate bug description.

Publishing the same service onto ArcGIS Online has no issues. Note there are more GET requests after the initial POST call to query if the operation is completed.

To understand how changing portal item settings (updateDefinition) works, my questions are:

1. Adding this "Keep track of who created and last updated features", what happens behind the scenes, e.g. creating those editing-related attributes layer by layer? 

2. Where are settings that control this Portal 60 seconds "timeout exceeded" behaviour?

3. When comparing the Enterprise with AGOL, it looks like AOL keeps sending GET requests after the initial updateDefinition POST request to keep the Portal from timeout. Is it expected on Enterprise, or is there a setting for that?

Any insight is appreciated.

Thanks,
Hua

[DavidColey]

If it were me, I would go into Pro, enable editor tracking on all the feature classes that participate in this feature layer collection, add global ids, and perform an overwrite weblayer.  Or, if you have custom settings on the current feature layer collection, publish a new web feature layer collection and copy over any custom popup settings that you can.   

Otherwise, yes the 'enable editing . . . ' from the settings page, (1) portal is trying to add the editor tracking fields feature by feature.   (2) There is no timeout setting that can be adjusted for hosted feature layers and (3) yes as far as I have experienced that is expected.

[cle444]

@DavidColey  Thanks. Yes, I agree with you. I am aware of a few workarounds including what you suggested, break the big dataset for smaller sets and publish as separate services, or just use plain HTTP call to the REST end point to bypass the Portal item settings page.

However, I like to know more about this Portal setting page and how it works. If there is no timeout settings so the 60second timeout is hard-coded? Is it the same bug BUG-000135047 ? Is it going to be addressed in 10.9.1 so it behaves similar to AGOL? 

Thanks.
Hua

[DavidColey]

@cle444 , this has nothing to do with portal.  The 60 second timeout setting is the maximum time a client will wait to get a service when called from ArcGIS Server.  So if the operation you are trying to do is timing out on you after 60 seconds, that means portal is not accessing the feature layer collection.  You can change that setting in the ArcGIS Server Admin directory for a Hosted feature layer (i.e https://yourDNSName:6443/arcgis/admin/services/Hosted/YourFeatureService.FeatureServer)

but I really, really recommend against doing that - because again if you have a timeout after 60 seconds, then you likely have other issues.

[cle444]

OK, the 60 seconds timeout is fine, we are not seeking to change that and probably shouldn't. The problem is around the mechanism of handling the "updateDefinition" process.

When comparing Enterprise 10.9.0 to AGOL as of today, they have an identical updateDefinition HTTP request to

/rest/admin/services/Hosted/<FeatureServiceName>/FeatureServer/updateDefinition

However, AGOL keeps sending subsequent requests to check if the promise has been resolved to avoid timeout. Enterprise doesn't have this behaviour. So if the promise is not resolved within 60 seconds, users will see the timeout error.

Can the ESRI team advise if this bug has been addressed in the latest 10.9.1 release?