runtime: HttpClient throws unexpected TaskCanceledException when HttpClient is reused
This is the raw stack trace from the exception that occurs:
FATAL: Unhandled exception (A task was canceled.).
DEBUG: at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.ConfiguredTaskAwaitable`1.ConfiguredTaskAwaiter.GetResult()
at System.Net.Http.HttpClient.<FinishSendAsyncUnbuffered>d__59.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at QuarkHttp.QNewHttpClient.<SendNewAsync>d__5.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at QuarkHttp.QHttpClient.<SendAsync>d__1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at DataApi.<GetDataAsync>d__4.MoveNext() in C:\...\DataApi.cs:line 84
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at DataPoller.<RefreshChangesAsync>d__18.MoveNext() in C:\...\DataPoller.cs:line 121
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at DataPoller.<RunPollCycle>d__17.MoveNext() in C:\...\DataPoller.cs:line 98
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadPoolWorkQueue.Dispatch()
The issue:
My problem originates with the HttpWebRequest
API being depricated and a significantly lower performance version being used in .NET Core 2.0. I use a library (QuarkHttp) that is a tiny wrapper around the HttpWebRequest
API. When porting this wrapper library to .NET Core, I used a shared HttpClient
instance to avoid the overhead of creating new connections each time (following @geoffkizer’s comment /cc @davidsh). My code looks like this:
static QNewHttpClient()
{
_defaultHttpClient = CreateHttpClient((false, null));
_proxyHttpClients = new ConcurrentDictionary<(bool, IWebProxy), HttpClient>();
}
public static async Task<QHttpWrapNewResponse> SendNewAsync(this QHttpRequest request, bool fetchResponse = true, bool isAllowRedirects = false, int timeout = 100000, IWebProxy proxy = null)
{
HttpClient httpClientToUse = _defaultHttpClient;
if (isAllowRedirects || proxy != null)
httpClientToUse = _proxyHttpClients.GetOrAdd((isAllowRedirects, proxy), CreateHttpClient);
DateTime startTime = DateTime.Now;
HttpRequestMessage requestMessage = CreateHttpRequestMessage(request);
HttpCompletionOption completionOption = (fetchResponse ? HttpCompletionOption.ResponseContentRead : HttpCompletionOption.ResponseHeadersRead);
HttpResponseMessage responseMessage;
try
{
responseMessage = await httpClientToUse.SendAsync(requestMessage, completionOption, (new CancellationTokenSource(timeout)).Token).ConfigureAwait(false);
}
catch (Exception ex) when (ex is TaskCanceledException || ex is OperationCanceledException)
{
Log.Error($"{ex.GetType()} thrown (Time taken: {(DateTime.Now - startTime).TotalSeconds}s).");
Log.Debug($"URL: {request.Url}\tMethod: {request.Method}");
throw;
}
return new QHttpWrapNewResponse(responseMessage, fetchResponse);
}
private static HttpClient CreateHttpClient((bool allowRedirects, IWebProxy proxy) properties)
{
HttpClientHandler clientHandler = new HttpClientHandler
{
AllowAutoRedirect = properties.allowRedirects,
AutomaticDecompression = DecompressionMethods.Deflate | DecompressionMethods.GZip,
UseCookies = false
};
if (properties.proxy != null)
{
if (!clientHandler.SupportsProxy)
throw new Exception("Proxy not supported.");
clientHandler.UseProxy = true;
clientHandler.Proxy = properties.proxy;
}
return new HttpClient(clientHandler)
{
Timeout = TimeSpan.FromMilliseconds(Int32.MaxValue)
};
}
private static HttpRequestMessage CreateHttpRequestMessage(QHttpRequest request)
{
HttpRequestMessage requestMessage = new HttpRequestMessage(new HttpMethod(request.Method.Name()), request.Url);
requestMessage.Version = request.Version;
if (request.Referrer != null)
requestMessage.Headers.TryAddWithoutValidation("referer", request.Referrer);
foreach (string curHeader in request.Headers)
{
string normalizedHeader = curHeader.ToLower();
if (normalizedHeader != "content-type")
//requestMessage.Headers.Add(curHeader, request.Headers[curHeader]);
if (!requestMessage.Headers.TryAddWithoutValidation(curHeader, request.Headers[curHeader]))
throw new Exception("Header invalid.");
}
if (request.Payload != null)
{
requestMessage.Content = request.Payload;
requestMessage.Content.Headers.ContentType = MediaTypeHeaderValue.Parse(request.ContentType);
}
return requestMessage;
}
The exception occurs on this line
responseMessage = await httpClientToUse.SendAsync(requestMessage, completionOption, (new CancellationTokenSource(timeout)).Token).ConfigureAwait(false);
In the exception handler, I measure the time taken myself to ensure that I wasn’t missing something obvious. This is the output of that logging:
[2017/12/08 16:37:43.742 QuarkHttp.QNewHttpClient] ERROR: System.Threading.Tasks.TaskCanceledException thrown (Time taken: 100.0041412s).
[2017/12/08 16:37:43.742 QuarkHttp.QNewHttpClient] DEBUG: URL: https://some.site/url Method: Get
One point to note is that this issue occurs across atleast 5 different domains that I know of, but have never seen this issue anywhere in the past. It works as expected on the .NET framework 4.5.x,4.6.x,4.7.x and Mono 4.x.x/5.x.x. However, on .NET Core, the issue occurs very often (many times an hour in my application).
This is why I think this is a framework issue rather than my own error:
In the SendNewAsync
method, the line HttpClient httpClientToUse = _defaultHttpClient;
causes the reuse of the default HttpClient. When this line is changed to HttpClient httpClientToUse = CreateHttpClient((false, null));
(which is used to initialize the default HttpClient in the first place as seen in the constructor), a new HttpClient is used for every request. This makes things slower, but the issue disappears. It only occurs when the same HttpClient
is reused.
I have no code that modifies the HttpClient
in any way after it is initially created. In my specific application, the proxy and allowRedirects options are never changed, so the HttpClient
that’s used wasn’t taken from _proxyHttpClients
either.
I’m not sure how to debug this issue further. I could definitely test things if anyone has ideas.
My .NET Core version is 2.0.2, and it runs on Ubuntu 16.04.
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 1
- Comments: 58 (31 by maintainers)
Commits related to this issue
- IP-5 Use new instance of HttpClient for each request due to https://github.com/dotnet/corefx/issues/25800 — committed to LykkeCity/Lykke.Ico.Job.BtcTransactionTracker by cassade 6 years ago
Any updates on this issue?
I was finally able to reproduce it!
It has nothing to do with the
HttpCompletionOption
. It appears to happen because of this:It only happens on Linux.
The correct behavior would be for it to detect closed connections and recreate a new one. I remember @davidsh mentioning that .NET Core on linux uses a CURL wrapper, but Windows uses something else. That might lead to the differing behavior.
This explains why it didn’t occur when I used a new
HttpClient
every time - no attempt was made to reuse old connections.Reproduction:
Run this, wait 5-6 minutes, then enter a key to send another request.
Result on Windows:
Result on Ubuntu 16.04:
The exception occurs after 30s, as expected from the CancellationToken we passed in.
P.S. I made a separate issue for the extra newlines in the Ubuntu output at https://github.com/dotnet/corefx/issues/25809.
@karelz I had the exact same issue on Debian Stretch Docker images. Roughly 1-3 calls in a 1000 from a static
HttpClient
would randomly fail with the exact same Task Canceled / timeout exception, with the same stacktrace (ending withFinishSendAsyncBuffered
).The HTTP call would never leave the box, so the target service never even recorded an incoming request. It was happening fairly consistently, but impossible to reproduce on demand though, and appeared to happen with no apparent behavior pattern.
The problem disappeared after upgrading to the .NET Core 2.1 RC runtime, so it might have been some issue with the curl handler.
The team I work with has been observing this issue on a host of .NET Core services we have - all of them have had the 100s timeout on various calls with no correlation to call size and minimal correlation to load. We also experienced the frustration of low reproducibility and inability to get the issue to occur in our dev environments. I suspect part of that stemmed from developing on Windows boxes, but our services are running in containers on Linux.
Luckily we have seen the issue resolve when we built against .NET Core 2.1 RC. I haven’t had the time to completely isolate the issue, but since was present when we built against 2.1 Preview 1, we believe it was related to the fact that since preview 2, the default is to use the SocketsHttpHandler instead of the native handler (which uses libcurl). After almost 3 days running so far we haven’t seen any timeouts, so we’re pretty confident it’s resolved.
We encountered the same issue on Windows Server 2008 R2.
I reproduced the issue on a ubuntu 16.04 x64 vm with runtime 2.0.6 and sdk 2.1.101.
The issue came out with the default
completionOption
parameter ofHttpClient.GetAsync
method which isHttpCompletionOption.ResponseContentRead
. When I changed it toHttpCompletionOption.ResponseHeadersRead
, everything goes fine.It seems to have something to do with the call of
LoadIntoBufferAsync
on the response’s content inHttpClient.FinishSendAsyncBuffered
method but I have not figured it out how. The direct cause of the timeout should be thatInterop.Http.MultiInfoRead
inCurlHandler.WorkerBodyLoop
method always returnsfalse
when called after last request for 4-5 min (LoadIntoBufferAsync
has been called at least once).@Priya91 can you check your test on 2.0? It would be good to have a confirmation we are able to reproduce it on 2.0 and the fact we can’t reproduce it on master (2.1) means, it is fixed.
@tiayi I don’t follow - the code snippet above does not create new
HttpClient
instances. Just one.