Poll an ArcGIS Server for Features - what's in the query cache?

265
5
Jump to solution
02-13-2019 08:51 AM
Highlighted
New Contributor II

Hello!

We have configured GeoEvent to poll a feature service for incremental updates based on a timestamp.  Through some trial and error - realized this was best based on editor tracking fields and wound up needing to change the date field the input connector was configured with.

However, we are not seeing new records come through the connector and I suspect it's basing its query on a future date --- is there a way to figure out what that query is that the input connector is using?

Thanks for any guidance you can offer!

jess

Reply
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Occasional Contributor III

Hi Jess,

Yes, there is a way to figure this out - I highly recommend you review this helpful blog post: https://community.esri.com/community/gis/enterprise-gis/geoevent/blog/2015/05/21/debugging-geoevent-... 

Basically, you'll want to turn on DEBUG level logging on com.esri.ges.transport.featureService.FeatureServiceInboundTransport

With that, you will see this in the Manager UI (or you can review the log files themselves):

log

In this example, the timestamp being used is 2018-11-05 18:57:46

If you went a bit too far ahead in time in your testing, you can reset the cache by restarting GeoEvent. Hope this helps!

View solution in original post

5 Replies
Highlighted
Occasional Contributor III

Hi Jess,

Yes, there is a way to figure this out - I highly recommend you review this helpful blog post: https://community.esri.com/community/gis/enterprise-gis/geoevent/blog/2015/05/21/debugging-geoevent-... 

Basically, you'll want to turn on DEBUG level logging on com.esri.ges.transport.featureService.FeatureServiceInboundTransport

With that, you will see this in the Manager UI (or you can review the log files themselves):

log

In this example, the timestamp being used is 2018-11-05 18:57:46

If you went a bit too far ahead in time in your testing, you can reset the cache by restarting GeoEvent. Hope this helps!

View solution in original post

Highlighted
New Contributor II

Thank you for the reference, Earl!

Reply
0 Kudos
Highlighted
New Contributor II

I have a quick follow up to this one --

We have configured editor tracking to store dates in our local time zone (mountain) so as to not cause confusion when users see the raw data. The feature service that's being polled is also configured for dates in MTN time.

Looking at the debugger messages, it seems that the cache time is being converted to UTC (7 hours ahead) -- so any new data that comes in during the next 7 hours window is missed --

I'm wondering if there's a way to reinforce the time zone through GeoEvent -- either through the input connector to cache the local time or to convert the time in the new records to UTC before evaluating the filter?

Reply
0 Kudos
Highlighted
Occasional Contributor III

Without digging too deep, I believe your configuration should work fine. UTC/GMT is just the logging format used by Apache Karaf and I don't think this should cause any issues. I'm not aware of an out-of-the-box way to change the log time format.

Reply
0 Kudos
Highlighted
New Contributor II

Thanks, Earl -- I think i'll submit something to technical support because it seems like it's not quite working as expected.

Reply
0 Kudos