I noticed situation when request to /event-heartbeat never finishes. Below is the trace:
2017-07-06 00:15:05,277 DEBUG eStack.ServerEventsClient - [SSE-CLIENT] Prep for Heartbeat…
2017-07-06 00:15:05,286 DEBUG eStack.ServerEventsClient - [SSE-CLIENT] Sending Heartbeat…
2017-07-06 00:15:05,358 DEBUG eStack.ServerEventsClient - [SSE-CLIENT] Heartbeat sent to: https://myserverurl/event-heartbeat?id=1xq9QNIVyPGpjRbmHpVo
2017-07-06 00:15:15,380 DEBUG eStack.ServerEventsClient - [SSE-CLIENT] Prep for Heartbeat…
2017-07-06 00:15:15,389 DEBUG eStack.ServerEventsClient - [SSE-CLIENT] Sending Heartbeat…
and that’s it… Since the call to ConnectionInfo.HeartbeatUrl.GetStringFromUrlAsync never completes, the heartbeat process stops. I don’t see any other HTTP activity on the client at this time. Nothing sets the IsCancellationRequested either.
Below is the corresponding IIS Log trace for last heartbeat:
2017-07-06 05:15:12 22.214.171.124 GET /event-heartbeat id=1xq9QNIVyPGpjRbmHpVo 443 - XX.XX.XX.XX - - 200 0 1236 7016
This trace shows sc-win32-status code of 1236 and time taken of 7016ms (usually 100-200ms).
This status code means ERROR_CONNECTION_ABORTED.
We have approximately 130 clients connected at this time with 10 or so experiencing this issue very often. This issue may be related to network quality as those clients frequently experience heartbeat timeouts and other (SSL/DNS) connection issues.
Would it be more reliable to change the heartbeat timer to fire several times instead of once? Perhaps it can adjust the “next” start time after successful heartbeat but keep the time frequency set at heartbeat timeout value.
What do you think?