0

In .NET Core 2.1 there is HttpClient completly rewritten. There were many imporvements like it uses websockets and etc now. It also fixes concurrency problems. I want to ask if FLurl utilizes new .NET core HttpClient or uses olderone? If older one is the case so when/if it is going to be updated?

Vytautas Pranskunas
  • 772
  • 12
  • 23
  • 1
    HttpClient didn't have any concurrency problems. If you experienced concurrency problems, explain the actual problem so people can help. HttpClient in fact was thread-safe from the beginning and you could(should) use a single instance for multiple calls. It was async from the beginning, meaning you didn't have to ever block while using it. Are you using `.Wait()` or `.Result` perhaps? – Panagiotis Kanavos Jun 25 '18 at 08:00
  • Actually it looks like it has: https://github.com/dotnet/corefx/issues/14897 and https://github.com/dotnet/corefx/issues/30040 I have faced it when doing load testing. And actually I remmeber having this since x4.1 – Vytautas Pranskunas Jun 25 '18 at 10:26
  • BTW: how Result impacts concurrency? – Vytautas Pranskunas Jun 25 '18 at 10:39
  • The issues you linked to don't show any concurrency bugs - the first is an *old, fixed* bug that was wrongly reopened by people that assumed it was related to their problems. The second was actually closed as unrelated. The only real issue wasn't related to concurrency at all – Panagiotis Kanavos Jun 25 '18 at 10:42
  • 1
    As for `.Result` it *blocks* a call which means you *lose* concurrency. If you use `.Result` in your code you may well be blocking yourself. In any case, without code that shows what the problem is, it's impossible to help or even guess what's wrong. – Panagiotis Kanavos Jun 25 '18 at 10:43
  • BTW the issue you linked to had nothing to do with concurrency at all. The *server* returnd a body to an `HTTP HEAD` response that by definition shouldn't have a body. Unless you made a `HEAD` request, the linked issue is unrelated – Panagiotis Kanavos Jun 25 '18 at 10:47
  • Then i missunderstood it because while reading through all posts there it was mentioned somewhere that it is because of concurrency of WinHttp. But anyway this not answers my initial question - is Flurl uses new HttpClient from .NET core 2.1 or no? – Vytautas Pranskunas Jun 25 '18 at 11:41
  • It does answer the question - it doesn't matter. First, whatever problem you have has nothing to do with any assumed HttpClient concurrency issues. If there were any, thousands of developers would have noticed years ago - WinHTTP is an *Operating System* library used by the Full Framework as well – Panagiotis Kanavos Jun 25 '18 at 11:59
  • 1
    Second, the *application's runtime* and is what provides the default HttpClient version. If your application targets 2.1, you get the new HttpClient. You can install newer versions by installing a newer version of the HttpClient NuGet package. That won't fix any problems in your code or the library though – Panagiotis Kanavos Jun 25 '18 at 11:59
  • Panagiotis Kanavos - Indeed - when I moved code to core 2.1 there is no failed requests (out of 5000) running same load test. So issue gone. p.s. there were no Wait or Result peaces in the code – Vytautas Pranskunas Jun 28 '18 at 08:04
  • Which issue? You still haven't explained what the problem is. The links you posted in the comments aren't related to any concurrency issues, they were about incorrect server responses. It could be that HttpClient now ignores invalid bodies in requests that shouldn't have a body like HEAD instead of throwing. Do you have any code? Exception call stack? Fiddler capture? – Panagiotis Kanavos Jun 28 '18 at 08:28
  • I do not have any fiddler for now. But problem was that every 100th or so request was comming like error throwinf exactly same exception like in those two links i posted. But i can assure that no part of code sends HEAD. "System.Net.Http.WinHttpException: The server returned an invalid or unrecognized response " – Vytautas Pranskunas Jun 28 '18 at 13:22
  • Which means the *server* returned a bad response. This has nothing to do with HttpClient. Tha'ts what the problem with the linked issues was as well, which is why they were closed. – Panagiotis Kanavos Jun 28 '18 at 13:24
  • BTW I use HttpClient to make thousands of requests per day in *batches*. If there were any concurrency issues I'd have noticed. What I *have* noticed is *servers* crashing if I make too many requests at the same time, which is why I use throttling to make only eg 10 or 20 requests at a time – Panagiotis Kanavos Jun 28 '18 at 13:26
  • Instead of assuming the upgrade to 2.1 solved the issue I'd suggest you configure the SocketHttpHandler to limit the number of concurrent connections. Add exception handling as well and log the full exception, not just the message. The full exception will probably contain the response. In any case you can inspect the response in the exception handler. HTTP calls fail all the time, you need to be able to check whether it was a 4xx error (your fault), a 5xx (the server's fault) or the connection went down – Panagiotis Kanavos Jun 28 '18 at 13:38
  • Finally, consider adding Polly as explained by Scott Hansleman in [Adding Resilience and Transient Fault handling to your .NET Core HttpClient with Polly](https://www.hanselman.com/blog/AddingResilienceAndTransientFaultHandlingToYourNETCoreHttpClientWithPolly.aspx). This will allow you to configure eg retries with delays for some failures or back off for 1 minute if too many errors occur at the same time etc – Panagiotis Kanavos Jun 28 '18 at 13:40
  • Thanks for the usefull info i will try to apply those techniques. – Vytautas Pranskunas Jun 29 '18 at 13:48

1 Answers1

1

As noted in the comments, Flurl targets .NET Standard, which effectively defines a contract for HttpClient, and the runtime you're targeting in your app provides the implementation. So yes, if your app targets .NET Core 2.1, then Flurl will use the .NET Core 2.1 implementation of HttpClient.

Todd Menier
  • 37,557
  • 17
  • 150
  • 173
  • Thanks - thats answers my question. Btw when i moved code to 2.1 there is no failed requests anymore. Thi si snot related to Flurl because I do not use it yet but still. – Vytautas Pranskunas Jun 28 '18 at 08:05