Closed erikvk closed 6 years ago
Just a status update: adding diagnostics and actively trying to figure out the problem.
@erikvk @alemoi is it right you could not reproduce it anymore?
@dan31 That's right. I am no longer able to reproduce the issue on our server. I have reached out to our customer, to see if they still have the issue.
My first guess is that this is somehow related to our code, in a way I'm unable to find, and that some update during the past weeks fixed it. Seems like a long shot, but still.
My second guess is that this is somehow time-related. We saw all hangs during the early hours of the day (2:00-6:00 AM), and we had the issue in august/early september, but not now. Also seems like a long shot.
I will let you know if this super elusive issue presents itself again.
Until then: ¯\_(ツ)_/¯
Let's have it closed for now. And when we experience any issues with UDP again - we will reopen it.
This issue is for reference – has already been discussed with @alemoi who is investigating
When having an
Handle.Udp()
in an app, listening for UDP datagrams in a production environment, we have noticed that the Starcounter network gateway can sometimes stop sending the incoming datagrams to the Starcounter app. When this happens, a network monitor tool like Wireshark or TCPView will still register the incoming datagrams, and even associate them with thescnetworkgateway
process, but the UDP handle in the app code is not called.Restarting the codehost (including restarting
sccode
) has no effect. Runningstaradmin kill all
, and restarting the Starcounter service and application, however, fixes the issue.Our conclusion is that the issue is located in the network gateway.