New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixed the race condition in StreamingWebSocketClient #739
base: master
Are you sure you want to change the base?
Conversation
made StopAsync and StartAsync thread-safe. Implemented the fix for Nethereum#738. Fixed the problem where the _listener task completed immediately. Also, the listener now quits when the WebSocket disconnects.
As per other threads.. (and new people coming over) there was other pull request working on this, which include similar changes, but keeping this open just in case it helps anyone else. |
I've checked the up-to-date code as of now, and all of the problems that I've mentioned still exist.
There was also something to do with not being able to call StartAsync in the user-defined error handler; I made the HandleIncomingMessagesAsync not wait for HandleError call to finish, to counter that. |
Thank you!! I lost track of the improvements (or not tested correctly most probably!) |
@juanfranblanco I think it exactly one issue will cause the HIGH CPU USEAGE. I create a dump and below is the callstask.
|
StreamingWebSocketClient.StopAsync
andStreamingWebSocketClient.StartAsync
thread-safePlease don't add null checks to the
HandleIncomingMessagesAsync
function as the StopAsync function now properly waits for the listener to exit, doing so would make actual bugs harder to catch.The function also must not check the
_clientWebSocket
's state as the listener should be stopped once the connection is dropped. A properly implemented code would call theStartAsync
in theError
handler if the aim is to reconnect onErrors
.