CoreHost FeatureClass.Search '3 minute timeout' on Federated FeatureService

[AndersVolue]

I have a CoreHost application that caches a lot of data from UN feature services through our WebAdapter.

The application reads Device, Junction and Assembly just fine before getting an exception while creating a RowCursor on the Line FeatureClass.

It appears that the problem I have reading Lines is tied to the time it takes for the response. As soon as the response time exceed 3 minutes I get an exception. 

Using Fiddler I can tell that the response hasn't arrived yet at the time of the exception. And I can also tell that it does arrive a minute or so later. 
Furthermore, it appears in Fiddler that the request has been aborted.

Does ArcGIS Pro SDK abort long running requests when they exceed 3 minutes? 

Any ideas would be appreciated.

[RichRuh]

Pro (not just the SDK) does have a timeout that defaults to 3 minutes. I suggest working with tech support to figure out why the queries are taking that long- sounds like something could be wrong there.

--Rich

[AndersVolue]

Thank you Rich!

It's a very large spatial filter fetching thousands of features. And for this application that's just a test case. In production it must be able to handle even larger requests. 
So while speeding up resonse time is always nice, it will not be a guarantee that we won't end up hitting this timeout in production.

I'm happy to hear that Pro actually has a timeout like this. Now I have something to look for. If possible, do you recall what the timeout is called and where it can be changed?

Thanks again Rich. 

[RichRuh · Accepted solution]

Anders,

I've been researching this, and cannot find any way to change the client timeout. 

Some things to consider:

1. Are all the tables properly indexed?
2. Can you break the query into multiple pieces? (If it's a spatial filter, could you break up the extent into multiple parts and query each part separately?)
3. Can you fetch a subset of the fields in this feature class?

At the REST API level, there is a mechanism to limit the number of rows that are returned at a time. I can enhance the Pro SDK to provide access to that mechanism, but it would have to be something added at a future release (post-3.0).

Sorry I cannot be of more help,

--Rich

[AndersVolue]

It's actually a big help. Now I know where the issue is.

I will implement your second suggestion, breaking the query into pieces. We use a spatial filter and it is a Multipart polygon, so it is easily broken up into smaller geometries. It's not ideal but I think we can make it work 🙂

I don't see how  limiting the number of returned rows will help. Unless we can be sure that we receive the lowest ObjectID's (which I don't expect). But in that case we could repeat the query with an updated where clause each time ("oid > lastMaxoid"). Still I would have to be able to predict how many row could be read before the timeout, so I won't be requesting this sort of update to the Pro SDK.

If this timeout can't be made configurable then I would suggest looking into the error message in the exception. Currently the exception says "Must be owner to do this operation". If it could say "Internal ArcGIS Pro timeout exceeded" or something like that, it would be a big help. (I know this is easier said than done)

Thanks again!

[RussellBrennan]

Hi @AndersVolue do you have any code I could use to try to reproduce this error message with my own data?

[AndersVolue]

Sure. It's really simple. I'm surprised it hasn't come up many times earlier.

You will naturally have to find a feature service that will take more than 3 minutes to respond. 

        private static void reproduceIsuse(string user, string pass)
        {
            Uri PortalUri = new Uri("https://servername.com/portal");
            Uri FederatedFeatureServiceUri = new Uri("https://servername.com/server/rest/services/UNupdater/DeltaService/FeatureServer");

            //License
            ArcGIS.Core.Hosting.Host.Initialize();

            //Portal
            string referer, token;
            if (!ArcGISSignOn.Instance.IsSignedOn(PortalUri))
                ArcGISSignOn.Instance.SignInWithCredentials(PortalUri, user, pass, out referer, out token);

            //Feture Service
            ServiceConnectionProperties federatedArcGISServer = new ServiceConnectionProperties(FederatedFeatureServiceUri);
            Geodatabase Geodatabase = new Geodatabase(federatedArcGISServer);

            //Feature Layer
            FeatureClass federatedServiceFeatureClass = Geodatabase.OpenDataset<FeatureClass>("L3Electric_network_Line");

            //Reproduce Issue
            DateTime timeBeforeSearch = DateTime.Now;
            try
            {
                federatedServiceFeatureClass.Search(null, false); //Crash after 3 minutes
            }
            catch (GeodatabaseGeneralException gdbGeneralException)
            {
                var timeSpan = DateTime.Now.Subtract(timeBeforeSearch);
                Console.WriteLine("Exception raised after: " + timeSpan.Minutes + " minutes " + timeSpan.Seconds + " seconds");
            }
        }

Just in case it matters, we are using Portal for ArcGIS 10.9.1 and ArcGIS Web Adapter (IIS) 10.9.1. And on our clients executing the CoreHost application we have ArcGIS Pro 2.9.1.

---