-
Notifications
You must be signed in to change notification settings - Fork 113
System.InvalidOperationException: TODO, RESX: net_Websockets_AlreadyOneOutstandingOperation; #207
Comments
That issue seems to corrupt all of the application for some reason, leading to more of
|
The TODO is a duplicate of another issue #198. It isn't an actual issue, its that we forgot to add logging for some websocket scenarios. The exceptions you are getting are more likely because there is a websocket protocol violation between the client and the server. I'd check out the docs for more information https://docs.microsoft.com/en-us/aspnet/core/fundamentals/websockets. Sorry that the exceptions are confusing |
I think I figured out the issue with the sockets themselves. I was calling |
@shravan2x Yeah, that makes sense. The exception message here is supposed to be this one: https://github.com/dotnet/corefx/blob/dfb4bf4b7454fdbacbcada8ff8fe344a32fc527e/src/System.Net.WebSockets/src/Resources/Strings.resx#L115 : @jkotalik Yeah, plus there's another PR to corefx to copy across: dotnet/corefx#24846 . Since it looks like we'll be stuck with source copying for a little while longer, we may as well update it after that PR is merged. |
Hello, |
Don’t overlap more than one send or more than one receive in your code. |
@davidfowl Alright Thank's a lot. Any idea how to handle exceptions of this kind, to prevent the application crash ? |
Catch exceptions if you do things off the request thread. |
Calling SendAsync in parallel is not the only issue here, it just goes nuts after the disposal OK so i have added breakpoints in EVERY access of WebSocket in my service code. I started to get these annoying errors in logs for about million times, so i disconnected all the sessions and put those breakpoints while service was still running (receiving no new connections). Now the situation is connections died 45 minutes ago and these FrameResponseStream errors are logging periodically in batches and NOT hitting ANY breakpoint, Earlier in my code I called closedAsync, Dispoced, marked the ws object to null and not touching that object anywhere and not hitting ANY breakpoint... @anurse |
Agreed :). Filed #214 to make sure at the very least we update our copy of the code (it's pretty easy to update). |
We hooked up our message bus up to our implementation and push messages right off the hub to the client over a web socket. Is there any plans to add a buffer on top of web sockets to prevent this kind of stuff? I'd really hate to have to add locking around this. |
Would be really nice if a web socket had a state where I could check if it's currently sending data. |
@niemyjski such a state would be too transient, it would be a constant race condition. Any cross-thread access really needs a locking mechanism. SemaphoreSlim is my preferred async lock. We have no plans to add a buffering layer. |
That's a good option if callers may run in parallel. If the issue is that the caller is serialized but may call while a previous operation is still in fight, you can also just store the previous Send/ReceiveAsync-returned task and await it before sending/receiving the next message. It'll be a nop if there are no attempts at concurrent usage and will force serialization if there is. |
To add to what @stephentoub said, that's basically what the previous version of SignalR did via this TaskQueue abstraction. |
@davidfowl Thanks for that. I had to write a task queue last week for back plane related work (https://github.com/FoundatioFx/Foundatio/blob/feature/taskqueue/src/Foundatio/Queues/TaskQueue.cs). |
@davidfowl I'm curious how you are handling this in the new version of signalr (Will have to dive into the code). |
@niemyjski currently we're usings Channels as our synchronization primitive (later we'll change to pipelines in some places) but it's basically the same idea. There's a single consumer pulling data from the channel and writing to the websocket (and vice versa for websocket reads). There's never any overlapping sends or receives. |
This issue was moved to dotnet/aspnetcore#2322 |
This exception occurred during some testing, I'm not 100% sure how to reproduce it. If the
TODO
below actually means something was not implemented, that may be the cause.The text was updated successfully, but these errors were encountered: