Bug 35779 - Shared HttpClient instance fails after cancellation
Summary: Shared HttpClient instance fails after cancellation
Status: RESOLVED FIXED
Alias: None
Product: Android
Classification: Xamarin
Component: Mono runtime / AOT Compiler (show other bugs)
Version: 5.1
Hardware: Other Mac OS
: --- normal
Target Milestone: ---
Assignee: Marek Habersack
URL:
Depends on:
Blocks:
 
Reported: 2015-11-11 06:03 UTC by Rupert Rawnsley
Modified: 2015-12-14 09:39 UTC (History)
7 users (show)

See Also:
Tags: BZCU
Is this bug a regression?: ---
Last known good build:


Attachments
Example project that reproduces the problem. (28.30 KB, application/zip)
2015-11-11 06:03 UTC, Rupert Rawnsley
Details

Description Rupert Rawnsley 2015-11-11 06:03:08 UTC
Created attachment 13773 [details]
Example project that reproduces the problem.

[Cross-posted from https://forums.xamarin.com/discussion/55223/shared-httpclient-instance-fails-after-cancellation]

Although the thread safety of HttpClient was recently improved, I've found a scenario where the state of a HttpClient instance can become irrevocably corrupt. After more than a year of suffering from this obscure problem, I think I finally have a simple project in which it is reliably reproducible (attached with code below for easy reference).

The flow is as follows:

    1. Start 10 HTTP requests for the same resource on individual background threads
    2. Start 10 more HTTP requests for the same resource on individual background threads
    3. Cancel the first 10 requests
    4. Wait for all the threads to finish

The expectation is that the first set of requests terminate quickly with a TaskCancelledException, then the second set run to completion. The request logic only actually waits for the header to be returned and doesn't bother downloading the content, so under favourable network conditions we would expect this to all complete within 10 seconds or so.

However, in the sample project the second set of requests never return and in fact the HttpClient timeout of 30 seconds eventually kicks in to kill the tasks off.

There are four adjustments to the sample project that stop this problem happening (the first three have NOTE comments in the code):

    1. Increasing the DefaultConnectionLimit to 100
    2. Removing the task cancellation step
    3. Using an instance of HttpClient per request rather than using a single shared instance
    4. Targeting a different domain for the second set of requests

Change any one of these things and the code will run as expected.

Based on this evidence, and tinkering with the target URL, I think the likely culprit has something to do with DNS resolution. Perhaps cancelling a task when a DNS query is being processed somehow corrupts the state of the HttpClient object? It is a natural area for lock protection, but perhaps the cancellation logic forgets the unlock?

The sample code is adapted from a @MihaMarkic bug report about a related (or possibly identical) problem: https://bugzilla.xamarin.com/show_bug.cgi?id=20974
Comment 1 Marek Habersack 2015-12-14 09:04:10 UTC
This issue is fixed in the current Xamarin.Android stable release (6.0.0-34) and it appears to be a different issue than the one reported in bug #20974
Comment 2 Rupert Rawnsley 2015-12-14 09:39:13 UTC
I can confirm that the example now runs as expected in Xamarin.Android 6.0.0.34. Thank you!

Notice (2018-05-21): bugzilla.xamarin.com will be switching to read-only mode on Thursday, 2018-05-25 22:00 UTC.

Please join us on Visual Studio Developer Community and GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs and copy them to the new locations as needed for follow-up. The See Also field on each Bugzilla bug will be updated with a link to its new location when applicable.

After Bugzilla is read-only, if you have new information to add for a bug that does not yet have a matching issue on Developer Community or GitHub, you can create a follow-up issue in the new location. Copy and paste the title and description from this bug, and then add your new details. You can get a pre-formatted version of the title and description here:

In special cases you might also want the comments:

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Note You need to log in before you can comment on or make changes to this bug.