I have an input that polls an ArcGIS Server for features that takes longer than 30 seconds, and it appears that GeoEvent is timing out and never processing the input. Is there a way to increase a default timeout on a particular input? I don't see any options in the GeoEvent admin interface.
Hi @ChrisCarter3 - GeoEvent Server is a client application that consumes from feature services. The timeout setting you're looking for is often going to be found server side (i.e. where the feature service resides); not client side.
Put another way, ArcGIS Server is where you'll be able to control the service timeout thresholds for any particular service. I'd check out the following documentation. It seems that you can adjust the timeout threshold on services via ArcGIS Server Manager > navigating to the service in question > explore the "pooling" tab.
Alternatively, if you know the average response time of the service is 45 seconds for the type of query you're trying to perform, you can adjust GeoEvent Server's input to poll (read: query) every 45+ seconds so that GeoEvent Server isn't asking for records faster than ArcGIS Server can return them. This is just an example by the way - hopefully the query response time isn't that latent. If it is, there are other strategies that can be employed to improve the query response time if you don't want to increase the timeout threshold.
Hi @GregoryChristakos - Thank you for the reply. The input is indeed a Feature Service, and if I run the query through the REST endpoint, it takes about 1 minute 15 seconds to return all the data. The service timeout on the feature service is 600 seconds so I don't think that's the problem.
@EricIronside mentioned a possible "GeoEvent input timeout" setting in this thread: https://community.esri.com/t5/arcgis-geoevent-server-questions/connecting-geoevent-to-a-postgresql-v...
Hi @ChrisCarter3 - Understood! The "Poll an ArcGIS Server for Features" input connector that is available out of the box does not have a property that controls the timeout. This is primarily because the "FeatureService" transport that the aforementioned connector uses doesn't have that property as something you can expose. This is true even if you created your own custom copy of the connector via Manager > Site > Connectors, and then tried to tweak the settings.
I'm assuming my colleague @EricIronside was either referring to 1) increasing the polling interval, or 2) using a custom connector whose transport is not "FeatureService", but instead a different transport that exposes a property for influencing the client side timeout.
If you're interested in the latter scenario, you could create your own custom connector via GeoEvent Manager that pairs the JSON adaptor with the HTTP transport (rather than the FeatureServer transport). It's a bit of an unorthodox workflow, but you should be able to make a query against your feature service with a bit more effort. Most importantly, the HTTP transport does expose the HTTPtimeoutvalue property.
I tested this on my end (manager > site > connectors > create new connector). I set the type to "input", the adapter to "JSON", and the transport to "HTTP". You can configure whichever properties you want shown/hidden, but the key thing to note in the list of options is that there's a "HTTP Timeout (in seconds)" property now. I called my custom connector "Poll a Feature Service for Esri Feature JSON" but you can call yours whatever you'd like. Once you finish creating this connector, go through the process of adding it as a new input for configuration & use.
The reason I said this is an unorthodox workflow & requires a bit more effort is because you'll need to provide the URL to the feature service you want to query along with the full query string, token, and whatever else might be needed. For example, this is part of what I provided in the URL parameter: "https://<my_geoevent_server>:6443/arcgis/rest/services/SampleWorldCities/MapServer/0/query?where=1%3D1&text=&objectIds=&time=&timeRelation=... ... ...etc etc". A good way to obtain this URL is to perform the query yourself at REST, ensuring that the format returned is set to JSON. Copy the full encoded URL and provide that in the URL parameter. I also needed to specify the acceptable MIME type as "application/JSON". Your URL, parameters, and more, will vary.
The FeatureService and HTTP transports both allow you to make a HTTP request to a feature service, but where the FeatureService transport is specifically geared for navigating ArcGIS server's and querying services natively with little effort, the HTTP transport is more general for querying any sort of REST endpoint / API and so it requires more leg work to use with feature service queries.
Thank you for the detailed info. I haven't been able to get my custom connector to receive any data yet, but I'll keep working on it.
For anyone looking at this, I should add that different transports expose different properties for handling timeouts. Transports are just one half of what makes up an input or output connector; with the other half being the adaptor.
For example, the "Poll an ArcGIS Server for Features" input connector pairs the JSON adaptor with the Feature Server transport. The Feature Server transport does not contain a property for handling timeouts hence my response above. I am assuming that the timeout in question is a server timeout which is where the feature service would need to be changed in ArcGIS Server.
In contrast, the "Push Text to an External TCP Socket" output connector pairs the Text adaptor with the TCP transport. The TCP transport does contain a property, "Connection Timeout" for handling timeouts server side (GeoEvent).
All of this is to say the answer to the above question is largely contingent on the type of connector in question when thinking about GeoEvent Server. Its important to consider this; and whether a timeout is client side or server side.