Maybe someone has an idea to find a workaround or solution for that problem:
The GeoEvent Extension 10.3.1 Input (JSON over TCP) stops working if the input
receives more than a message in ~ 100 ms. The Input geoevents are not dropped like it
appears to be in 10.2.2, instead the Input/TCP-Port stopps working at all.
Even restarting the Input Connector does not solve the problem. If the
Input connector stopped working once, no more data is received until the
complete GeoEvent Service has been restarted.
We had problems with remarkable packet loss in 10.2.2, so we decieded to use 10.3.1.
Now we are running into the problem described above that the incoming data is not processed
if the input stopped working once.
We reproduced the problem with a simple python tool that is sending JSON Data to the TCP Socket.
The test script sends always the identical JSON document. The JSON is about 1000 characters long.
The GeoEvent Service always processes some Input Events (5 to 20, it's always different), then the
Input stops working as described above.
Test Environment:
- Windows: Server 2012 R2 and Windows 7 Professional
- Running on a Hyper-V Virtual Machine with 16GB RAM and 4 Cores
- Tested on 3 different Machines (one with Portal federated the others blank ArcGIS Server and GEP)
- ArcGIS Versions 10.3.1
- GEP Connector: TCP JSON IN
The most Important aspect is, that the Input connector does not recover itself, instead it is totally
broken until the complete GEP is restarted. There is no chance to evaluate more
detailed where the problem could be. We did not find anything helpfull in the Logfiles.
It would be great if we could get some assistence or any hint what exactly the problem is and maybe how
to circumvent the Problem.
Unfortunately we are limited to TCP/JSON as Input, because this is the Interface to our customer.