Latest Contributions by RJSunderman

Hello Jay - My apologies that this reply is coming to you so late - hopefully it is still useful. Yes, the 'Update a Feature' output should default to add a new feature to a target feature class if an existing feature cannot be found whose 'Unique Feature Identifier Field' matches the received event's TRACK_ID. The process at the 10.3 / 10.3.1 product releases goes something like this: An event whose GeoEvent Definition has a field tagged TRACK_ID arrives at an 'Update a Feature' output The output checks an internal cache to see if it has an OID (row identifier) mapped for the event's TRACK_ID If so, the output attempts to use that OID to update the specific feature If it doesn't have an OID, it queries the feature layer to try and discover which feature should be updated If GeoEvent queries for the OID needed to update a feature and discovers that no feature exists in the feature class whose 'Unique Feature Identifier Field' value matches the current event's TRACK_ID ... then it will assume that a new feature needs to be created. Basically we're making requests on three different endpoints of the targeted feature service: .../arcgis/rest/services/service-name/FeatureServer/layer-index/query .../arcgis/rest/services/service-name/FeatureServer/layer-index/addFeatures .../arcgis/rest/services/service-name/FeatureServer/layer-index/updateFeatures You can request GeoEvent log the REST requests it is making by turning DEBUG logging on for the Feature Service outbound transport: com.esri.ges.transport.featureService.FeatureServiceOutboundTransport This will enable you to see the actual JSON included with each REST request and follow the transactions GeoEvent is making with your feature service. You might find additional information in my blog 'Debugging the Add a Feature / Update a Feature Output Connectors' helpful. Best Regards - RJ ... View more

Hello Rob - If I understand your question, no, I don't think you will be able to easily configure the GeoEvent Extension (GEx) to discover that two sensors (or in your case two reporting vehicles) have the same identifier. Every event is made up of attributes. Any attribute (String, Date, Double, Geometry, Boolean, etc.) can be tagged as the TRACK_ID. This tells the GeoEvent Extension that the event is associated with a given source (a reporting vehicle or sensor). If a fraudulent reporter or poorly configured sensor were reporting events with a TRACK_ID assigned to another vehicle or sensor ... how would you tell just by looking at two event which one was the impostor? I would be complicated, but in the vehicle tracking scenario, if you assume that a vehicle with a given TRACK_ID cannot be in two places at the same time, you could use a spatial processor to buffer the vehicle's position and send the polygon buffers out a stream service. You could then configure a GeoFence synchronization rule to update the extension's catalog of GeoFences as events are received from the stream service. You would have to be careful to enrich each vehicle's report with a timestamp of when the event was received and calculate a fairly short time range (so that each buffer had a TIME_START and a TIME_END) before it was broadcast out the stream service. That way the GeoFence synchronization would have the information it needed to expire a GeoFence which was out-of-date and the GeoEvent Extension could purge the "old" GeoFences. You then might use a GeoEvent Service to check if a given vehicle report's buffer is DISJOINT with a previous buffer for the same TRACK_ID. Two vehicles reporting on opposite sides of the city would be the trigger you would use to send an event to an alerting output (such as email, or SMS text). This would not be a simple configuration to set-up ... but it is one idea ... off the top of my head. Hope this information is helpful - RJ ... View more

Hello Ben - Thanks for the question. There is no hard-coded limit or expiry rule for the number of track identifiers a Track Gap Processor will cache. Perhaps there should be. As you suggest, a track identifier that is at some point received will remain in the processor's cache consuming system resources even if that track identifier will never reasonably be seen again. I asked one of the developers for a code review and tested what he told me to verify. It appears that the Track Gap Processor not only caches the identifier for every TRACK_ID it encounters, it also spawns a thread and associates the thread with the cached TRACK_ID. So, at the 10.3 / 10.3.1 release, you can expect  that a GeoEvent Service which incorporates a Track Gap Detector will remember every TRACK_ID it encounters and the number of threads associated with the JVM's java.exe process will increase until a system resource is exhausted -- unless you alter the GeoEvent Service and publish your changes (or cycle the GeoEvent Windows Service). Spawning so many threads strikes me as unnecessary and we will probably change the threading model in the future to not spawn so many threads. You likely would not notice, however, unless you were monitoring that particular system resource. If you encounter any problems with the 10.3 / 10.3.1 release, please submit a product enhancement request with Esri Technical Support. That will help ensure that an issue is logged against the product for the development team to address. Hope this information helps - RJ ... View more

Hello Carmen / Thibaut - I did some digging and discovered an issue, logged against the 10.3 product release which appears to match the behavior you describe above. For your reference, the issue is BUG-000087381 in the Esri Technical Support queue. Working through the issue's reproduction steps it is fairly easy to reproduce. I conducted my tests using the 10.3.1 product release. I first create a GeoEvent input to poll a feature service for features, configuring the input to use a GeoEvent Definition I created and own. I then create a GeoEvent output to display event data received and publish a GeoEvent Service with the input and output to verify event flow. I then edit the GeoEvent Service to include a GeoTagger, configuring the GeoTagger to write its information to a field which already exists in the GeoEvent Definition being used by the running input. Interestingly, when I publish the changes to the GeoEvent Service, my output continues to display event data being received by the GeoEvent Service. The displayed event data, however, is not being enriched with the names of GeoFences which satisfy the GeoTagger's configured spatial expression. Checking the GeoEvent's log I see errors resembling the following: com.esri.ges.messaging.jms.MessagingImpl null java.lang.reflect.UndeclaredThrowableException com.esri.ges.core.geoevent.FieldException: Cannot set field on a immutable GeoEvent If I remove the GeoTagger from the GeoEvent Service's event processing flow and republish the GeoEvent Service, the event data which was being displayed by my output stops. A quick check reveals that the GeoEvent Definition which was being used by the input - the GeoEvent Definition I created and own - has been deleted. This is a bug; the GeoTagger should not be deleting a GeoEvent Definition it did not create. The attempted workflow, however, is flawed. A GeoTagger is more like a Field Enricher than a Field Calculator. By that I mean that the GeoTagger is expecting to be able to enrich an event with information:  the name and optionally the category of GeoFences which satisfy the GeoTagger's spatial expression. Event enrichment assumes that the field or fields into which the processor will write its information do not already exist. You should expect some sort of exception to be logged by both the GeoTagger and the Field Enricher if they are configured to write information to fields which exist in the event structure received by the processor. We will work to address this issue in an upcoming release of the product, but I would advise for now that you take care to configure a GeoTagger to write to a field which does not exist in the event structure received, guaranteeing that the processor will create a "managed" GeoEvent Definition which the processor owns and has the right to delete. - RJ 10.4 Product Update The issue described above was tested and marked as resolved in the 10.4 product release. 10.4 should be publicly available February 2016. ... View more