Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Note that this issue was previously logged but was closed during the backlog bankruptcy.
By default, SignalR should handle remote host unexpectedly closing connections since this is the reality of life in a network environment. Users turn off their systems or close browser windows w/o logging out of web sites.
Two main exceptions go unhandled and pollute the Elmah logs to the point they are unusable. I would say on my production web site, at least 80% of the errors in Elmah are caused by SignalR.
The request URLs are:
The exceptions are:
The client disconnected.
The remote host closed the connection. The error code is 0x80070057.
Steps to reproduce
Easiest way to see the issue occurring is to run Elmah and SignalR on a system. That way you can see the errors.
I have yet to figure out a definitive method for reproducing this, but my users have an uncanny ability to make it happen many times per day.
If I figure out a way to consistently reproduce it, I'll update this ticket.
Is ELMAH's filtering support not sufficient for suppressing these messages?
In ASP.NET Core, we have indeed suppressed most of these messages because you are correct they aren't terribly useful. Our limitation here is breaking changes. Suppressing these messages would negatively affect users who are expecting them. We could make it a config flag that allows you to suppress the exceptions but a) that isn't cheap in terms of time and resources and b) we don't have plans to ship a new minor version (in which an API change could be made) to do so.
If the ELMAH filtering is able to reduce these logs sufficiently for you, I'd strongly encourage using that. If not, let us know and we can look at our options.
Thanks--with all my searching, I never used a phrase that pointed me to Elmah's filtering support. I just wrote some filter rules and will deploy them early next week. I'll report back here what I did to help the community and then very likely close the ticket.
Thanks. Was finally able to deploy code where it could be tested and, YES, this is a reasonable work-around.
For anyone else that stumbles upon this thread, here is what I added to the web.config to exclude my specific errors: