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.