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; } } }

GeoEvent 10.5.1 stuck at "Please wait while the field is edited..."

VladimirStrinski

I am trying to update an attribute and assign a tag to it (in this case TRACK_ID). As soon as I click Save I get the screen "Please wait while the field is edited..." and it has been stuck on it for over half an hour.

Tried different browsers but there was no difference.

What am I missing?

There are times when this just works in seconds, and sometimes I hit this. This is at least the 3rd time it happens - the previous times I ended up completely deleting all input and output adapters and all definitions and ended up rebooting the server, but this should not be the solution...

Screen with "Please wait while the field is edited..." message

Finde mehr Beiträge mit dem Tag

Accepted answers

RJSunderman

Daniel Cota Chris Beyett‌ Vladimir Strinski‌

This issue is being tracked by Esri Tech Support as BUG-000107723

The GeoEvent Server product team has accepted the bug an is looking at a possible fix for the 10.6.1 product release.

The issue does not appear directly related to the JSON adapter's Learning Mode. It is interesting that the issue's behavior changes in different browser clients with regard to the number of fields beneath a parent. Thank you for that information.

As a work around, for 10.5.1 and likely 10.6, please consider manually creating a GeoEvent Definition which is flat (e.g. no Group elements). You should be able to apply your GeoEvent Tags to this flattened structure and/or change a field's data type to specify, for example, that a value ingested as Double can be handled as a Long integer. Note that you should be using flattened event structures with add/update feature as well as stream service outputs -- both outbound adapters in these cases translate an expected flat event structure into Esri Feature JSON (which is hierarchical) as part of their event record dissemination.

It may also be possible, though much less palatable, to export the GeoEvent Definition which the GeoEvent Manager web application is not allowing a user to edit, use a text editor to edit the XML, delete the original GeoEvent Definition, and import the changes from the altered XML. I would expect anyone interesting in trying this to work with Esri Tech Support as accidentally changing the XML structure will prevent successful XML import and GeoEvent Definition recovery.

- RJ

All comments

VladimirStrinski

Probably a related observation - this most often happens on auto-generated definitions. I don't remember seeing it happen on a definition that I've created manually.

6.png

ChrisBeyett

Vladimir,

I've noticed that it occurs on auto-generated definitions, however not all of them. I've noticed mostly it on nested (grouped) JSON. I'm working on narrowing it down to a reproducible pattern and reporting it to Esri Tech Support. However if you have a reproducible case please let us know as we believe it's a bug that wasn't present in the earlier versions.

- Chris

VladimirStrinski

Hi Chris - thanks for the quick reply! And yes, I can reproduce it on demand.

You are correct that it happens on 1) auto-generated definitions that have 2) nested (groupped) JSON.

My JSON has two groups - geometry and attributes. When creating the definition I can tell it to look at just the "attributes" group (by putting the name - "attributes" in "JSON Object Name:") and then it doesn't create a nested definition. When it is not nested everything works (but I lose the geometry).

To reproduce it - consume a JSON by subscribing to a web socket. If the incoming JSON has nested attributes I hit this issue.

Regards,

Vladimir

VladimirStrinski

I just did another test - I manually created a nested definition and everything worked.

However with auto-generated ones the issue reappears.

VladimirStrinski

Another update - as soon as any field is auto-discovered I hit the issue.

I can tell if I will have the issue when I go to the nested attribute details - e.g. the URL would be like "https://geoevent.host.local:6143/geoevent/manager/attributefield.html?guid=394aa517-f7e8-412a-9c8a-90b3e25c32ad".

If that page displays all sub-attribute then everything works fine. In the cases when I hit the issue that page displays a blank list of sub-attributes.

In my test I manually created a definition with sub-attributes and everything worked fine until I activated "learning mode" in the input service and it added a few more sub-attributes.

I also see a few error messages in the log that look like:

com.esri.ges.messaging.jms.GeoEventImplSerializer

An unexpected error occurred while attempting to serialize the GeoEvent to a Byte Array. Error: Index: 80, Size: 19.

preceeded by:

com.esri.ges.messaging.jms.GeoEventImplSerializer

Index: 80, Size: 19 java.lang.IndexOutOfBoundsException: Index: 80, Size: 19 at java.util.ArrayList.rangeCheck(ArrayList.java:653)[:1.8.0_121] at java.util.ArrayList.get(ArrayList.java:429)[:1.8.0_121] at com.esotericsoftware.kryo.util.MapReferenceResolver.getReadObject(MapReferenceResolver.java:60)[389:com.esotericsoftware.kryo:3.0.3] at com.esotericsoftware.kryo.Kryo.readReferenceOrNull(Kryo.java:834)[389:com.esotericsoftware.kryo:3.0.3] at com.esotericsoftware.kryo.Kryo.readObjectOrNull(Kryo.java:728)[389:com.esotericsoftware.kryo:3.0.3] at com.esri.ges.messaging.jms.GeoEventImplSerializer.readField(GeoEventImplSerializer.java:182)[112:com.esri.ges.framework.messaging.jms-messaging:10.5.1] at com.esri.ges.messaging.jms.GeoEventImplSerializer.read(GeoEventImplSerializer.java:159)[112:com.esri.ges.framework.messaging.jms-messaging:10.5.1] at com.esri.ges.messaging.jms.GeoEventImplSerializer.readFieldGroup(GeoEventImplSerializer.java:213)[112:com.esri.ges.framework.messaging.jms-messaging:10.5.1] at com.esri.ges.messaging.jms.GeoEventImplSerializer.readField(GeoEventImplSerializer.java:201)[112:com.esri.ges.framework.messaging.jms-messaging:10.5.1] at com.esri.ges.messaging.jms.GeoEventImplSerializer.read(GeoEventImplSerializer.java:159)[112:com.esri.ges.framework.messaging.jms-messaging:10.5.1] at com.esri.ges.messaging.jms.GeoEventImplSerializer.read(GeoEventImplSerializer.java:106)[112:com.esri.ges.framework.messaging.jms-messaging:10.5.1] at com.esri.ges.messaging.jms.GeoEventImplSerializer.read(GeoEventImplSerializer.java:34)[112:com.esri.ges.framework.messaging.jms-messaging:10.5.1] at com.esotericsoftware.kryo.Kryo.readObject(Kryo.java:708)[389:com.esotericsoftware.kryo:3.0.3] at com.esri.ges.messaging.jms.GeoEventImplSerializer.fromBytes(GeoEventImplSerializer.java:65)[112:com.esri.ges.framework.messaging.jms-messaging:10.5.1] at com.esri.ges.messaging.jms.amqp.AmqpMessagingFactory$AmqpGeoEventConsumer.receive(AmqpMessagingFactory.java:292)[112:com.esri.ges.framework.messaging.jms-messaging:10.5.1] at com.esri.ges.messaging.jms.MessagingImpl$ConsumerThread.run(MessagingImpl.java:193)[112:com.esri.ges.framework.messaging.jms-messaging:10.5.1]

I am not sure if those are related, but they happen when I activate the "learning mode". I suppose as part of the "learning" mode might be okay to guess wrong and thus cause those.

Hopefully this helps.

Regards,

Vladimir

VladimirStrinski

Once it gets messed up it has other consequences too - even though the definition claims to have a TRACK_ID field it later claims that such doesn't exist:

TRAC_ID does exist:

TRACK_ID does exist

and when yet trying to create a stream output it claims it doesn't have it:

Cannot find TRACK_ID

I am not sure what did I change or did to make this issue reappear. Somehow the previous few times all of this worked fine and then it stopped.

Regards,

Vladimir

VladimirStrinski

Is there a limit on the number of sub-attributes?

I may have hit the same issue after I added the 15th sub-attribute.

VladimirStrinski

Confirmed:

Up until 14 sub-attributes it works fine.

As soon as I add the 15th sub-attribute it starts misbehaving.

I've been able to reproduce this 4 times so far (the first two accidentally)

Is there a separate process for submitting bugs? Or will this thread suffice? And any updates with an estimate for the bugfix would be more than welcome.

Regards,

Vladimir

ChrisBeyett

I'll loop in RJ Sunderman to see if we can get the ball rolling. Since both you and I can reproduce the error we might have a few options.

RJ what do you think?

Replied above 13-Oct-2017 -- RJ

- Chris

VladimirStrinski

Some more details and observations -

Using latest Chrome I hit the issue almost all the time and can't edit definitions with sub-attributes.

Using IE11 it works fine until I hit 15 sub-attributes.

Using latest FireFox it failed me today at the 12th attribute.

This has become a major pain, exaggerated by an upcoming conference where we need to show GeoEvent Server and do demos and teach customers.

Any help would be greatly appreciated!

RJSunderman

Daniel Cota Chris Beyett‌ Vladimir Strinski‌

This issue is being tracked by Esri Tech Support as BUG-000107723

The GeoEvent Server product team has accepted the bug an is looking at a possible fix for the 10.6.1 product release.

- RJ

VladimirStrinski

Chris and RJ - Thanks for the prompt updates!

And yes - I am interested in being able to extract that XML and give this option a shot. If that procedure is documented somewhere can you please point me in the right direction? Feel free to PM me the link if you prefer. If not we can follow up with Tech Support.

Regards,

Vladimir

RJSunderman

Variants of this issue were documented by Esri Tech Support under the following:

BUG-000107723
BUG-000111776
BUG-000114252

Testing all reported behaviors, it appears that these issues have been addressed in the 10.6.1 release candidate.

RJSunderman

Vladimir Strinski‌

The illustration you included in your post from 11-Oct-2017 is part of an unrelated issue introduced in the 10.6 release. GeoEvent Definitions which were not suitable for use when publishing a 'Store Latest' feature service (or any feature service GeoEvent Server would use to add/update features) was triggering a sticky validation message -- by which I mean even if you selected a different GeoEvent Definition, one that was suitable and had a field tagged TRACK_ID, the GeoEvent Manager web application's panel still displayed the error message that GeoEvent Definition <name> is missing a TRACK_ID tag. Esri Support was tracking this as issue BUG-000113943 ... which we've also addressed as part of the 10.6.1 product release.

- RJ

VladimirStrinski

Hello RJ,

Thanks for the update. We're looking to test the solution in 10.6.1.

Unfortunately the suggestion "As a work around please consider manually creating a GeoEvent Definition which is flat (e.g. no Group elements)." does not work for us - the data comes from a third party and we have no control over its structure. We don't have an option to use "no Group elements".

As of 10.6 this issue has been confirmed to still be present.

Regards,

Vladimir

JulieK

Hello,

I am experiencing the same issue right now. As per RJ's workaround, I created a flat structure definition but that doesn't seem to work . With the newly created definition, my input doesn't work. Input works with the auto generated definition but I get 'missing TRACK_ID' when publishing stream service . The Flightaware API

http://flightxml.flightaware.com/json/FlightXML2/SearchBirdseyeInFlight

autogenerated definition

Do I need to create groups in the newly created definition? any thoughts??

Thanks in advance!!

RJSunderman

Julie - Apologies for the confusion. When I suggested using a flattened structure, that was after a getting a working hierarchical GeoEvent Definition to ingest the data. The bug we're trying to work around is that a hierarchical event definition, created by an inbound connector's adapter, cannot be edited after it has been created. You still have to use the hierarchical event definition with the configured input to ingest the data. After that you can use a Field Mapper to map the received event record to the simpler (flattened) structure, which you should also be able to edit within the GeoEvent Manager web application. You have to honor the structure used by the data provider to ingest the data; you cannot configure an input to ingest the data in structure you prefer to use.

- RJ

JulieK

aah I see what you are saying. Let me try it again, thanks for your response !!

Nimm an der Diskussion teil

Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registriere ein kostenloses Konto.

Schnellzugriffe

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