Our production GeoEvent Server is at 10.8.1 (non-federated) server in the DMZ. We've set up a GeoTab stream service which is not streaming the actual geometry when we subscribe to it. We set up a .csv output file and have confirmed it's writing data per the GeoEvent Definition used to publish the service. We also set up a stream service to the ISS feed per Esri's GeoEvent stream services tutorial, it also will not stream the actual geometry. The logs show no errors. The logs show only INFO entries such as "Stream null/ISS-stream-service-out is found in memory." We've applied the latest security patches, and the odd thing is, we have the same implementation in our QA environment and there are no issues with the stream services.
Solved! Go to Solution.
We resolved the issue. Turns out there was a setting on the F5 under "Advanced" that was missed during the configuration for the production environment. There is a separate profile required for websocket that was set to none on production but had a profile on QA. The network engineer duplicated the WS profile and applied it to Prod. Which then allowed us to subscribe to our streaming services and resolved the issue. The moral of the story: work closely with your network engineering folks and *document, document, document* once you've gotten the correct settings on the F5 for a lower environment so they can then replicate those to the production environment. I should also add, we discovered this by essentially bypassing the F5 and updating the WebSocketContextURL to the server name wss://servername.domain:6143. Once we reverted the WebSocketContextURL to wss://reverseproxyservername.domain it failed to let us Subscribe.
We resolved the issue. Turns out there was a setting on the F5 under "Advanced" that was missed during the configuration for the production environment. There is a separate profile required for websocket that was set to none on production but had a profile on QA. The network engineer duplicated the WS profile and applied it to Prod. Which then allowed us to subscribe to our streaming services and resolved the issue. The moral of the story: work closely with your network engineering folks and *document, document, document* once you've gotten the correct settings on the F5 for a lower environment so they can then replicate those to the production environment. I should also add, we discovered this by essentially bypassing the F5 and updating the WebSocketContextURL to the server name wss://servername.domain:6143. Once we reverted the WebSocketContextURL to wss://reverseproxyservername.domain it failed to let us Subscribe.