I have built geocode services in ArcGIS Server (AGS) 10.5.1 with suggestions enabled to be used in AGOL apps. For the most part the geocode services are working fine, but I am getting "Wait timeout exceeded" severe warnings in AGS Manager. I do not believe I received these types of warning on geocode services with suggestions enabled in AGS 10.3.1.
Has anyone encountered these types of warnings on geocode services, especially ones where suggestions have been enabled?
If so, were you able to solve this issue?
Michael what style did you use to create the address locator you published as a geocode service? If it was single field I would suggest using the General - Gazetteer style. Check out BUG-000104922 on the support site.
Michael can you access BUG-000104922: The geocode service published to ArcGIS GIS Server w.. ? I was suggesting the Gazetteer style based on the limited information I had, but remembered that there was a suggestion memory leak and some other issues for the Single Field style based locator when published as a service.
So I could solve this in 2 ways:
1.) Keep current style and remove suggestion functionality which is the root cause of memory leak (not desirable as suggestions are a key component of address locator)
2,) Switch to Gazateer style that SHOULD solve the memory leak problem that creates the wait timeout errors
We have not seen the memory leak with the Gazetteer style locator and it is the recommended style to workaround the bug with the Single Field style. Let me know how the Gazetteer style works out for you. Whatever field was used to map to the Keyfield in the Single Field style, map it to the Place Name field in the Gazetteer style.
I've never used the Gazetteer style locator, but it sounds like it is very similar to the Single Field address locator style. As such, why would someone choose the Gazetteer style locator over the Single field style locator if there was no memory leak issue with the Single field style locator?
Would the Single House style locator also work as a substitute for the Single Field style locator?
The General - Single Field style is designed to be used to search for unique names or string values such as census tracts, parcel id numbers, place names, meter numbers to name a few. The type of search that is performed is an exact look up of what is in the reference data for the mapped Single Key field. General - Single Field style
The General - Gazetteer style uses search logic that will take into account spelling instead of an exact search, so if the reference data has "Carmel by the sea" in Californi as the city or place name, you could search for 'Carmel' California and get a match or candidates returned, whereas the Single Field locator would be expecting an exact input of "Carmel by the sea". The Gazetteer style can be used to search for the same unique features that you would use the Single Field locator, but it handles suggestions better than Single Field. General - Gazetteer style
Have you tried the Gazetteer style yet with suggestions in your application/workflow?
Are you using the Single Field style to search for addresses? It's not recommended style to use for searching for addresses if your reference data is point or polygon geometry. The US Address - Single House style is the style that should be used when you have point or polygon (parcels, tax lots) geometry that you want to use as the reference data for the locator.
When my org was at 10.3.1 we wanted to use the US Address - Single House address locator, but we encountered BUG-000105837 : The ArcGIS Server/ArcGIS Enterprise documentation page on geocode services makes no mention of the Suggest limitation. So ESRI tech. support told us to go with the Single Field address locator which we did and it did not have a memory leak.
10.5.1 has introduced a memory leak for the Single Field address locator, but now that we are investigating the US Address - Single House address locator (as per your advice) we seem to be hitting a similar bug to BUG-000105837 where we get erroneous results when using the geocode service in AGOL. Would you know if BUG-000105837 still exists in 10.5.1 as it was present in 10.3.1, but never fixed in 10.3.1?