nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Updating GeoEvent Services causes GeoEvent Definitions to disappear

ThibautDelaere1

Working with GeoEvent Extension for ArcGIS 10.3.1 I notice that GeoEvent Definitions of the output connectors disappear when I update and republish a certain GeoEvent Service.

My guess is that the Geotagger Processor (used in that GeoEvent Service) is causing this, as this is the last processor used just before the output connector. I don't have the issue in other GeoEvent Services (that don't use Geotagger processor).

Does anyone know what's going on and how to solve/avoid this?

Thanks in advance,

Thibaut

Najděte více příspěvků označených jako

Accepted answers

RJSunderman

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.

All comments

RJSunderman

Hello Thibaut -

The behavior you are seeing is by design. Please take a look at a blog I just posted: Understanding GeoEvent Definitions. It seems there have been a few questions in this area lately.

The GeoTagger processor is one of the processors which will add a field to the event it is processing. Adding or removing fields from an event changes the event's structure, requiring the processor making the change to construct a new GeoEvent Definition. I tend to refer to these as "managed" GeoEvent Definitions since they are owned by the processor and will be deleted when changes are made to the GeoEvent Service and the service is republished.

The location of the processor within the GeoEvent Service does not matter. It could be located immediately before an output (as you indicate your GeoTagger is) or further "upstream" closer to the input node. The processor owns the GeoEvent Definition it creates and the processor will delete its GeoEvent Definition if it believes it to be stale and will wait to receive an event before creating a new GeoEvent Definition.

Hope this information helps -

ThibautDelaere1

Thanks for the answer, this explains a lot.

So I understand that a processor may edit or delete a GeoEvent Definition it owns, BUT (in my opinion) it shouldn't delete GeoEvent Definitions it doesn't own.

Some details about the setup:

There's no name set for a GeoEvent Definition in the GeoTagger processor. It doesn't create a new one, because the field used for the GeoTags is already available in the incoming GeoEvent Definition. I create GeoEvent definitions for my output connectors, which are (owned) copies of the incoming GeoEvent Definition.

When I edit the GeoEvent Service (make some changes upstream) the created and owned GeoEvent Definitions for the output connectors often disappear. So it seems the GeoTagger processor doesn't take into account the owner of the GeoEvent Definition.

I can fix the GeoEvent Service by recreating/importing the missing definitions, but it is really annoying having to recreate them every time.

CarmenAmodei

Sir, Good afternoon. This is happening to me also and I am actually discussing this with ESRI. They have been stumped on this since I called them. Nobody, seems to know what is going on. in the next few days a second tier analyst from ESRI is supposed to help figure it out. We'll see. I will post their findings in another reply. I have noticed they not only reappear after a day but they only disappear when I use the input for tcp-ip.

RJSunderman

Hello Carmen / Thibaut -

Working through the issue's reproduction steps it is fairly easy to reproduce. I conducted my tests using the 10.3.1 product release.

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

- 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.

ThibautDelaere1

Thank you very much for the reply. This is exactly what happens.

I'll try the workflow you're suggesting.

Regards,

Thibaut

TimothyStiles

Changes made for the 10.4 release to the GeoTagger processor prevent it from deleting GeoEvent Definitions that it did not create.

Připojte se ke konverzaci

Přihlášení členové mohou přispívat, sledovat aktualizace a další. Jste tu noví? Zaregistrujte si bezplatný účet.

Rychlé odkazy

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.