GeoEvent Error - update a feature - Operation rolled back + ZK Persistence error

[AllenScully]

We have a fairly straight-forward GeoEvent service that recently stopped working.  Essentially the service takes an input table that has geometry stored as a string, and writes to a polygon feature class (using a field calculator on the geometry string field).  

These polygons are then used as geofences in a separate GeoEvent service.

However something has caused this to stop working - I cannot get the service to write to the feature class any more.  No configuration changes were made, nor schema changes to any table/FC involved. 

I've tried different versions of the output feature service (new services w/ new, empty feature class) - multiple restarts of the service and full server reboots (it's dev environment) - no change.

 - We are running Enterprise 10.5, and I have installed the patch for GEP (GeoEvent-10.5-Patch1) to not avail.

 - The service WILL write to json output successfully, so it must be related to the output (Update a Feature).

 - The Monitor shows that the correct # of records are sent to the output, but nothing gets written to the feature service.

 - There are 2 errors I see in the logs: 

      1) Error Code 400 - Error while writing to feature service xxxx. Error: Unable to complete operation > Operation rolled back...

      2) com.esri.ges.fabric.internal.ZKPersistenceUtility > KeeperErrorCode = ConnectionLoss for /geoevent/config/clusters/default/arcgisServerConnections....(much more here that I can't intelligently decipher).  I've checked to Default connection in the data store, and all appears ok there.  

I'm stumped after 2 days of trying to track this down.  Likely will open a ticket, but figured I'd ask wiser more experienced heads than myself first.  

[nelsmickaelson]

Did you get resolution on this issue? We are experiencing this same problem and its very frustrating. Polling indicates updating is occurring but the feature service isn't being updated. I'm running 10.71.

Thank you

[AllenScully]

Hi Nels - 

We did figure this out - it may not be helpful for your purposes.

Our issue was actually data related.  The application that generated our input data allowed users to submit 'bad' polygons, with only 3 vertices, where the 1st and 3rd vertices were the same - so, basically a line, not a valid polygon.  GeoEvent would then attempt to process the 3-point geometry string into a polygon feature, and it would fail.  

The real take-away though that may be applicable elsewhere is that when this error happened, GeoEvent input connector would not just skip the bad record (after logging an error) and move on to the next record, but instead it just got stuck at the bad record and wouldn't process anything more from the source/input data.

Eventually we wrote some error trapping for the front-end application telling users to re-draw the polygon, and preventing the bad record from being written into our data.

Hope some of that is helpful - 

Allen

[nelsmickaelson]

Hi Allen,

Thank you for getting back to me. As you indicated sounds like a different problem…….but it may be that my data has some sort of an issue as well that is prohibiting insert of new data. I will check it out….it may be that I need to do some validation in the geoeventservice before sending it to the output.

It’s frustrating that geoevent’s dashboard doesn’t let you know there is an issue….it just keeps incrementing the counter.

Cheers

Nels