In our iOS App, we currently do not prevent the user from making infinite AsyncCalls on the HttpClient.
Everytime a button is pressed, the HttpClient fires a request and after presssing the button an extreme amount of times at High Speed (say 40 times in 5 seconds) the Threads start throwing canceled exceptions.
Every class that has to use a HttpClient roughly implements it like this:
var handler = new NativeMessageHandler { AllowAutoRedirect = false, UseCookies = false };
using (var httpClient = new HttpClient(handler)
{
BaseAddress = new Uri(this.serviceSettings.BaseUrl),
Timeout = TimeSpan.FromSeconds(this.serviceSettings.Timeout)
})
{
return await httpClient.GetAsync(url);
}
Either our usage (and implementation) of the HttpClient is correct and we should implement a simple GUI fix, or our understanding of the HttpClient is wrong and our implementation is wrong.
Related
I have the following implementation. And the default timeout is 100 seconds.
I wonder how can I able to change the default timeout?
HttpService.cs
public class HttpService : IHttpService
{
private static async Task GoRequestAsync<T>(string url, Dictionary<string, object> parameters, HttpMethod method,
Action<T> successAction, Action<Exception> errorAction = null, string body = "")
where T : class
{
using (var httpClient = new HttpClient(new HttpClientHandler()))
{
}
}
}
The default timeout of an HttpClient is 100 seconds.
HttpClient Timeout
You can adjust to your HttpClient and set a custom timeout duration inside of your HttpService.
httpClient.Timeout = 5000;
HttpClient Request Timeout
You could alternatively define a timeout via a cancellation token CancellationTokenSource
using (var cts = new CancellationTokenSource(new TimeSpan(0, 0, 5))
{
await httpClient.GetAsync(url, cts.Token).ConfigureAwait(false);
}
A few notes:
Making changes inside of the HttpClient will affect all requests. If you want to make it per request you will need to pass through your desired timeout duration as a parameter.
Passing an instance of CancellationTokenSource will work if it's timeout is lower than Timeout set by the HttpClient and HttpClient's timeout is not infinite. Otherwise, the HttpClient's timeout will take place.
client.Timeout = 5*1000; doesnt work because client.Timeout expects something of type: System.TimeSpan
I changed the Timeout value using:
client.Timeout = TimeSpan.FromSeconds(10); // Timeout value is 10 seconds
You can use other methods as well:
FromDays
FromHours
FromMilliseconds
FromMinutes
FromSeconds
FromTicks
Just for FYI:
Default value of Timeout property is 100 seconds
Since we don't see any task created with a timeout i cannot help.
But if you are using a System.Net.Http under the hood of your application than MSDN says:
The default value is 100,000 milliseconds (100 seconds).
You can than change the value of the HttpClient.Timeout property
clent.Timeout = 5*1000;
if your httpservice class had a dependency IHttpClient (which it should instead of newing up an httpclient) then you could change the default by set this property on your client when configuring services.
For example
services.AddHttpClient<IHttpService , HttpService >(x => x.Timeout = TimeSpan.FromSeconds(10));
I am getting data from a server via Rest API. But Whenever i am waiting for the client response the Methos is left by the Debugger and the Program start loading the GUI even though at this point there is no Data to Display. Im already stuck for a couple of days on it. How can i make the Code to wait for the Response? Iam already using Await
My Method to get The Data: (Client Call in Line 8)
public async Task<ObservableCollection<Datensatz>> getDataFromAzure()
{
string URL = URLForContent;
_client = new HttpClient();
_client.DefaultRequestHeaders.Add("ApiKey", PW);
var result1 = await _client.GetAsync(URL, HttpCompletionOption.ResponseHeadersRead).ConfigureAwait(false);
if (result1.StatusCode == System.Net.HttpStatusCode.OK)
{
var result = await result1.Content.ReadAsStringAsync();
var ContentFromJson = JsonConvert.DeserializeObject<ObservableCollection<Datensatz>>(result);
string json = JsonConvert.SerializeObject(ContentFromJson, Formatting.Indented);
var filename = #"data.json";
var destinatioPath = Path.Combine(Android.App.Application.Context.GetExternalFilesDir(null).ToString(), filename);
File.WriteAllText(destinatioPath, json);
App.Database_Main.FillMainDBWithJsonEntrys();
return ContentFromJson;
}
return null;
}
You can use the Wait method of the Task. Such as
Task result = getDataFromAzure()
result.Wait();
You can also use the Thread.sleep(1000) to make the main thread sleep for a while. But this will reduce the function of the application because we don't know how long time the async method need and if the time if more than 5 seconds will cause the ANR.
I've scoured stackoverflow looking for ways to make synchronous API calls in Blazor WASM, and come up empty. The rest is a fairly length explanation of why I think I want to achieve this, but since Blazor WASM runs single-threaded, all of the ways I can find to achieve this are out of scope. If I've missed something or someone spots a better approach, I sincerely appreciate the effort to read through the rest of this...
I'm working on a Blazor WASM application that targets a GraphQL endpoint. Access to the GraphQL endpoint is granted by passing an appropriate Authorization JWT which has to be refreshed at least every 30 minutes from a login API. I'm using a 3rd party GraphQL library (strawberry-shake) which utilizes the singleton pattern to wrap an HttpClient that is used to make all of the calls to the GraphQL endpoint. I can configure the HttpClient using code like this:
builder.Services
.AddFxClient() // strawberry-shake client
.ConfigureHttpClient((sp, client) =>
{
client.BaseAddress =
new Uri(
"https://[application url]/graphql"); // GraphQL endpoint
var token = "[api token]"; // token retrieved from login API
client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", token);
});
The trick now is getting the API token from the login API at least every 30 minutes. To accomplish this, I created a service that tracks the age of the token and gets a new token from the login API when necessary. Pared down, the essential bits of the code to get a token look like this:
public async Task<string> GetAccessToken()
{
if ((_expirationDateTime ?? DateTime.Now).AddSeconds(-300) < DateTime.Now)
{
try
{
var jwt = new
{
token =
"[custom JWT for login API validation]"
};
var payload = JsonSerializer.Serialize(jwt);
var content = new StringContent(payload, Encoding.UTF8, "application/json");
var postResponse = await _httpClient.PostAsync("https://[login API url]/login", content);
var responseString = await postResponse.Content.ReadAsStringAsync();
_accessToken = JsonSerializer.Deserialize<AuthenticationResponse>(responseString).access_token;
_expirationDateTime = DateTime.Now.AddSeconds(1800);
}
catch (Exception e)
{
Console.WriteLine(e);
throw;
}
}
return _accessToken;
}
So, now I need to wire this up to the code which configures the HttpClient used by the GraphQL service. This is where I'm running into trouble. I started with code that looks like this:
// Add login service
builder.Services.AddSingleton<FxAuthClient>();
// Wire up GraphQL client
builder.Services
.AddFxClient()
.ConfigureHttpClient(async (sp, client) =>
{
client.BaseAddress =
new Uri(
"https://[application url]/graphql");
var token = await sp.GetRequiredService<FxAuthClient>().GetAccessToken();
client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", token);
});
This "works" when the application is loaded [somewhat surprisingly, since notice I'm not "await"ing the GetAccessToken()]. But the behavior if I let the 30 minute timer run out is that the first attempt I make to access the GraphQL endpoint uses the expired token and not the new token. I can see that GetAccessToken() refreshes expired token properly, and is getting called every time I utilize the FxClient, but except for the first usage of FxClient, the GetAccessToken() code actually runs after the GraphQL request. So in essence, it always uses the previous token.
I can't seem to find anyway to ensure that GetAccessToken() happens first, since in Blazor WASM you are confined to a single thread, so all of the normal ways of enforcing synchronous behavior fails, and there isn't an asynchronous way to configure the FxClient's HttpClient.
Can anyone see a way to get this to work? I'm thinking I may need to resort to writing a wrapper around the strawberry FxClient, or perhaps an asynchronous extension method that wraps the ConfigureHttpClient() function, but so far I've tried to avoid this [mostly because I kept feeling like there must be an "easier" way to do this]. I'm wondering if anyone knows away to force synchronous behavior of the call to the login API in Blazor WASM, sees another approach that would work, or can offer any other suggestion?
Lastly, it occurs to me that it might be useful to see a little more detail of the ConfigureHttpClient method. It is autogenerated, so I can't really change it, but here it is:
public static IClientBuilder<T> ConfigureHttpClient<T>(
this IClientBuilder<T> clientBuilder,
Action<IServiceProvider, HttpClient> configureClient,
Action<IHttpClientBuilder>? configureClientBuilder = null)
where T : IStoreAccessor
{
if (clientBuilder == null)
{
throw new ArgumentNullException(nameof(clientBuilder));
}
if (configureClient == null)
{
throw new ArgumentNullException(nameof(configureClient));
}
IHttpClientBuilder builder = clientBuilder.Services
.AddHttpClient(clientBuilder.ClientName, (sp, client) =>
{
client.DefaultRequestHeaders.UserAgent.Add(
new ProductInfoHeaderValue(
new ProductHeaderValue(
_userAgentName,
_userAgentVersion)));
configureClient(sp, client);
});
configureClientBuilder?.Invoke(builder);
return clientBuilder;
}
I'm creating an app that requires todo parallel http request, I'm using HttpClient for this.
I'm looping over the urls and foreach URl I start a new Task todo the request.
after the loop I wait untill every task finishes.
However when I check the calls being made with fiddler I see that the request are being called synchronously. It's not like a bunch of request are being made, but one by one.
I've searched for a solution and found that other people have experienced this too, but not with UWP. The solution was to increase the DefaultConnectionLimit on the ServicePointManager.
The problem is that ServicePointManager does not exist for UWP. I've looked in the API's and I thought I could set the DefaultConnectionLimit on HttpClientHandler, but no.
So I have a few Questions.
Is DefaultConnectionLimit still a property that could be set somewhere?
if so, where do i set it?
if not, how do I increase the connnectionlimit?
Is there still a connectionlimit in UWP?
this is my code:
var requests = new List<Task>();
var client = GetHttpClient();
foreach (var show in shows)
{
requests.Add(Task.Factory.StartNew((x) =>
{
((Show)x).NextEpisode = GetEpisodeAsync(((Show)x).NextEpisodeUri, client).Result;}, show));
}
}
await Task.WhenAll(requests.ToArray());
and this is the request:
public async Task<Episode> GetEpisodeAsync(string nextEpisodeUri, HttpClient client)
{
try
{
if (String.IsNullOrWhiteSpace(nextEpisodeUri)) return null;
HttpResponseMessage content; = await client.GetAsync(nextEpisodeUri);
if (content.IsSuccessStatusCode)
{
return JsonConvert.DeserializeObject<EpisodeWrapper>(await content.Content.ReadAsStringAsync()).Episode;
}
}
catch (Exception ex)
{
Debug.WriteLine(ex.Message);
}
return null;
}
Oke. I have the solution. I do need to use async/await inside the task. The problem was the fact I was using StartNew instead of Run. but I have to use StartNew because i'm passing along a state.
With the StartNew. The task inside the task is not awaited for unless you call Unwrap. So Task.StartNew(.....).Unwrap(). This way the Task.WhenAll() will wait untill the inner task is complete.
When u are using Task.Run() you don't have to do this.
Task.Run vs Task.StartNew
The stackoverflow answer
var requests = new List<Task>();
var client = GetHttpClient();
foreach (var show in shows)
{
requests.Add(Task.Factory.StartNew(async (x) =>
{
((Show)x).NextEpisode = await GetEpisodeAsync(((Show)x).NextEpisodeUri, client);
}, show)
.Unwrap());
}
Task.WaitAll(requests.ToArray());
I think an easier way to solve this is not "manually" starting requests but instead using linq with an async delegate to query the episodes and then set them afterwards.
You basically make it a two step process:
Get all next episodes
Set them in the for each
This also has the benefit of decoupling your querying code with the sideeffect of setting the show.
var shows = Enumerable.Range(0, 10).Select(x => new Show());
var client = new HttpClient();
(Show, Episode)[] nextEpisodes = await Task.WhenAll(shows
.Select(async show =>
(show, await GetEpisodeAsync(show.NextEpisodeUri, client))));
foreach ((Show Show, Episode Episode) tuple in nextEpisodes)
{
tuple.Show.NextEpisode = tuple.Episode;
}
Note that i am using the new Tuple syntax of C#7. Change to the old tuple syntax accordingly if it is not available.
I have a site I manage for a client and they wanted to be able to send out emails to all of their membership. I contacted the host and they suggested writing it in a way that it sends out in batches of 50 or less every minute so the mail server doesn't get overloaded.
That sounds great but the only way I could think of to do this without causing the administrator to have to sit on a page while it sends emails and reloads between each batch was to have a page call an ashx handler which fired up a thread to do the work and the thread is set to sleep after each batch for 60 seconds.
When I run the code from my machine it works fine and completes the entire list of emails. When I run it from the web host, which I don't have access to aside from ftp, it nearly completes but doesn't. Then if I try to hit the ashx page again to finish any that weren't sent, it doesn't do anything. It's like the thread causes something to lock up maybe and keeps additional threads from running.
Here's the code I'm using and I've never used threading before... so, does anyone know why it might be doing this and how to make it work correctly? Do I need to specifically kill the thread after I'm done? If so, how? Thanks.
public void ProcessRequest(HttpContext context)
{
if (context.Request.QueryString["id"].IsValid<int>())
{
campaignId = context.Request.QueryString["id"].To<int>();
var t = new Thread(new ThreadStart(SendEmails))
{
Priority = ThreadPriority.Lowest
};
t.Start();
}
}
private void SendEmails()
{
int currentCount = 0;
BroadcastEmailCampaign campaign = EmailController.GetCampaign(campaignId, false);
List<Member> memberlist = EmailController.GetEmailList(campaign.CampaignId);
var message = new MailMessage
{
Body = campaign.Body,
From = new MailAddress(campaign.SentBy),
IsBodyHtml = true,
Subject = campaign.Subject,
BodyEncoding = Encoding.UTF8
};
//add attachment
if (!string.IsNullOrEmpty(campaign.Attachment) && File.Exists(campaign.Attachment))
{
var attachment = new Attachment(campaign.Attachment);
EmailAttachmentType.SetContentProperites(campaign.Attachment, ref attachment);
message.Attachments.Add(attachment);
}
if (memberlist.Count <= 0)
{
return;
}
bool sendingComplete = false;
EmailController.SetCampaignSendingStatus(true, campaign.CampaignId);
while (sendingComplete == false)
{
message.Bcc.Clear();
message.To.Clear();
message.To.Add(new MailAddress(dummyEmailAddress));
List<Member> emailsToSend = memberlist.Skip(currentCount).Take(takeCount).ToList();
if (emailsToSend.Count <= 0)
{
sendingComplete = true;
EmailController.LogEmailCampaignResult(campaign);
EmailController.SetCampaignSendingStatus(false, campaign.CampaignId);
}
if (!sendingComplete)
{
foreach (Member email in emailsToSend)
{
message.Bcc.Add(new MailAddress(email.Email));
campaign.SentTo.Add(new BroadcastEmailCampaignSentTo
{
MemberId = email.MemberId,
Email = email.Email,
DateSent = DateTime.Now
});
}
EmailController.SendEmail(message);
EmailController.LogEmailsSent(emailsToSend, campaignId);
currentCount += takeCount;
Thread.Sleep(pauseTime);
}
}
}
Since I read a lot of threading in ASP.NET and still have no real clue of the dos and donts, I usually solve tasks like you describe by a console application that runs as a Scheduled Task in Windows Task Scheduler every e.g. 5 minutes:
In the ASP.NET page, I write all required information into a database table.
The scheduler periodically polls the database table for new jobs (e.g. sending of an e-mail) and processes, then empties the database table that serves as a queue.
This enables my application to stay responsive and in addition I don't have to worry that an IISRESET or something like this would kill my background threads.
t.IsBackground=true;
If that doesn't do it, I suggest using the ThreadPool with QueueUserWorkItem.