Description
We have come across a use of a disposed Socket object, as shown in the stack trace below:
System.ObjectDisposedException: Cannot access a disposed object.
Object name: 'System.Net.Sockets.Socket'.
at System.Net.Sockets.Socket.get_RemoteEndPoint()
at Unosquare.Net.HttpConnection.get_RemoteEndPoint()
at Unosquare.Labs.EmbedIO.HttpHandler.HandleClientRequest(CancellationToken ct)
This is using version 2.7.3 of EmbedIO from NuGet.
Reproducing
This error has appeared only once for us in months of heavy usage of EmbedIO, and I have not been able to reproduce it in any reliable way. This suggests there may be a race condition or something more complicated going on.
The nature of the web request that caused this issue was a GET request on a component's "status" end-point by an external monitoring service. It returns a very small JSON payload normally, and the component does not need to do much processing to form the response (i.e. very quick turnaround from request to response by the component). No other "status" fetching by that external monitoring service has ever seen this error before.
Expected behaviour
ObjectDisposedException should never be thrown to clients of the EmbedIO library.
Thanks!
Hello @mrsmidge, thanks for your input.
Based on the stack trace you provided, it seems that the exception was thrown _even before EmbedIO started processing the request_ (as it is the only moment when HttpHandler.HandleClientRequest calls the HttpConnection.RemoteEndPoint getter). This leaves quite a tiny time frame for the socket to "disappear under our noses".
What I find annoying about that exception is that HttpConnection was just trying to get an _immutable_ property of the socket, that in our case is already available when we first use a socket, as EmbedIO uses a TCP server, and accepted sockets are connected by definition.
I've prepared a pull request that caches the LocalEndPoint and RemoteEndPoint properties of requests as early as possible: this will most probably not fix your issue, but could lead to a more helpful stack trace if /when it happens again.
Thanks to @geoperez an update for EmbedIO v2 is on the way. The same changes have also been committed on the v3 branch and will be included in next preview.
Thanks, @rdeago. We'll update when the NuGet package is out, and I'll report back here if/when the issue occurs again.
Hi @mrsmidge you can check nuget version 2.9.2 (https://www.nuget.org/packages/EmbedIO/2.9.2)
@mrsmidge you're welcome! You're also welcome to join EmbedIO's Slack workspace where you can get more immediate help, share your use cases, and help us shape a brighter future for EmbedIO!
(Not to mention get help in upgrading your applications to the new EmbedIO v3.0 :wink:)
@mrsmidge is the nuget working fine?
@mrsmidge is the nuget working fine?
It took us several months of heavy EmbedIO usage before we even saw this error once, so we might need a little more time :smile:. I'll try to roll out 2.9.2 to more of our apps later this week and will report back if anything interesting happens!
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
It seems fair to close this ticket - we haven't seen any recurrence of the issue since upgrading to 2.9.2.