"Resetting" incident detection

[MarkCollins]

What causes the incident detection to be "reset"? Current I have to create new input data that would be detected as a new incident every time I want to test my service. How can I reset the detection?  I've tried resetting my input and GeoEvent service, neither seem to have any effect.

[RJSunderman]

Hello Mark -

If an Incident Detector processor has been configured to create "continuous" incidents, the management of the incidents is not handled by the individual processors in a GeoEvent Service. It is handled by an "incident manager" at the product level.

So, once an Incident Detector processor has created an incident in response to a received event which satisfies the processor's opening condition, the only certain way to "reset" is to stop and restart the GeoEvent Processor - as you observed, cycling the GeoEvent Service which contains the processor is not sufficient.

An ongoing, open, incident will only be closed if:  1) the processor"?s closing condition is satisfied by a received event; 2) the incident expires without update (depends on the Incident Detector processor"?s expiry time setting).

The number of "open"� and "closed"� incidents the cache is allowed to contain is configurable. You would need to update the com.esri.ges.incidents.cfg file in the "�\GeoEventProcessor\etc product folder and restart GeoEvent Processor to do this. Reducing the allowable number of "open"� and "closed"� incidents does not "reset"� incident detection, but for testing and development, if you knew exactly how many unique incidents a given test would create, you might use this to force GEP to purge its cache between tests or test iterations.

You also might find it helpful to use the administrative REST endpoint to look and see which incidents are currently in the product"?s cache, which are "open"� and which are "closed"�. Navigate to https://<server>:<port>/geoevent/admin/incidents in a browser window to view a snapshot of the incident cache.

Also, please be aware that we recently identified a bug in which ongoing incidents, created by an Incident Detector processor, are orphaned when any property of any node in the GeoEvent Service containing the processor is changed and the GeoEvent Service is republished. The fault will manifest itself when the orphaned incidents expire; if the GeoEvent Service has an Incident Detector processor with the same name as the processor which originally created the incident, the "new"� instance of the processor (created when the service was republished) will be notified. The result is that an active, ongoing incident with the orphaned incident"?s TRACK_ID will be updated as closed, then updated again when a new event is received "� so you might see a "blip"� as the Geometry associated with the expired incident asserts itself if you are observing the incident Geometries on a map. We"?re working to address this with the 10.3 product release.

Please let me know if you have any questions with the information above.

Thanks -
RJ

[NathanKemphues]

Was this bug addressed at 10.3? I can't find it listed in the release notes, but it could explain why I get duplicate cumulative incidents for a TrackId when I am altering a service with an Incident Detector in 10.3.1.

[MarkCollins]

RJ,

Thanks for the excellent reply. I appreciate all the thorough details!

-Mark