Repeat of System.Net.HttpListenerException: The I/O operation has been aborted because of either a thread exit or an application request

ServiceStack Self Hosting
1

I don’t know if old threads are monitored as well as new ones, but is there any new information on this error? As it’s description is eerily similar to one of our issues, any suggestions would be appreciated.

We are exploring using AppHostHttpListenerSmartPoolBase instead of ‘AppSelfHostBase’ as we were using that as well, but it is not looking promising. Server resources are not constrained while the issue is ongoing. So far only seen in one environment

System.Net.HttpListenerException: The I/O operation has been aborted because of either a thread exit or an application request

2

@maggarwal When posts are put into a old forum thread they are pulled to the top of our feed, so we see updates.

What resources are you looking at? The last post in the previous thread talked another piece of software “eating all the ports” which might be referring to socket exhaustion. Do you have something else using IO/sockets that could be causing the issue? Or do you have usage of HttpClient in your code base without a pool/reuse pattern? Eg if you have a code path that is always instantiating a new HttpClient this can cause socket resource issues as they are not released until the application restarts.

If you are on a Linux machine and have access to the server you might be able to see socket usage using ss -tan, if you see a large number of unexpected entries, than this might point to a related problem.

3

Apologies, the last post in that thread was me when I was convinced it was a ports issue with the backup software present. After seeing the mention of possibly running out of server resources, such as memory, cpu, etc, resource monitor(it is Windows) was checked and everything looked fine except the backup software was using an obscene(hundreds if not more than a thousand) number of ports. We are moving away from ports being the problem as it is not consistently showing this during periods of faults.

The interesting part is it is the same error as a separate one we sometimes we see when there are too many requests in a short period of time. Pool/reuse pattern was not something I considered that I will look into.

Thanks for the reply, if you have any other ideas to investigate they would be appreciated.

1 Like