I am using ServiceStack 5.5.0 and running AppHost inherited from AppSelfHostBase.
Logging is configured via NLog. Operating system on production server is Windows Server 2012.
I’m getting this exception in logs without some obvius pattern:
System.Net.HttpListenerException (0x80004005): The I/O operation has been aborted because of either a thread exit or an application request at
System.Net.HttpListener.EndGetContext(IAsyncResult asyncResult) at
ServiceStack.AppHostHttpListenerPoolBase.ListenerCallback(IAsyncResult asyncResult): True
Service is communicating with c# console app that has JsonServiceClient for sending only two types of request - one for only health message(I’m alive) and one for sending some string data.
Also, service is configured with one #Sharp page that its refreshes itself every 5 seconds.
I have not yet been able to reproduce the error and cannot create minimum sample application.
Do you have any idea what could cause this kind of exception?
No, app is not restarted.
I think problem is not ServiceStack related.
I have object registered in container that is accessed from #Sharp page and health message service, and I have missed to lock that object to prevent conurrent access.
Do you think that may cause this kind of exception?
Unfortunately, I have not been able to reproduce the error too.
In my case, I wrote a small python script, which kept sending requests to my service. In some cases, the error occured after the 10th try - in some cases, it happened after the 70th try. And everytime, I attached a debugger to the process, the problem was gone away.
On other machines, the error never occured. Fortunately on our production environment.
If you find any solution, please let me know. I hope, you have more luck than me.
Possibly related? This link refers to a “WCF self-hosted service”, but the symptoms/cause seem generic:
On a self-hosted Windows Communication Foundation (WCF) service on a server that’s running Windows Server 2012 R2 and that uses HTTP-based bindings (such as basicHttpBinding), the server intermittently drops the underlying TCP connection. When this problem occurs, you can see it in the HTTP.SYS logs that are typically found in the C:\WINDOWS\System32\LogFiles\HTTPERR folder. The log files should have an entry that cites Timer_MinBytesPerSecond as the reason. This problem does not occur in Windows Server 2008 R2.
Starting with Windows Server 2012 R2, the kernel driver that handles HTTP requests (http.sys) was changed in terms of how it handles the Timer_MinBytesPerSecond property. By default, Http.sys considers any speed rate of less than 150 bytes per second as a potential low speed connection attack, and it drops the TCP connection to release the resource. This problem does not occur in Windows Server 2008 R2 because the threshold for a slow connection in Windows Server 2012 R2 is much more restrictive.