[GaHee]

.Netowe świry, jak to w końcu jest z klasą HttpClient. Zalecane jest tworzenie jej w using ze względu na fakt, że implementuje IDisposable, czy jednak lepiej mieć jedną instancje tej klasy? Po wywołaniu Dispose() nie są usuwane sockety, natomiast jak mamy jedną instancje możemy mieć problem z dns cachingiem.

https://aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/
http://byterot.blogspot.co.uk/2016/07/singleton-httpclient-dns.html

Jakie jest najlepsze rozwiązanie lub jak rozwiązać problem z dns caching'iem?

#csharp #dotnet #programowanie

[bacteria]

@GaHee: klient powinien byc jeden a o IDisposable sie nie martw bo pracujesz w managed framework czyli .NET sam sie pozbedzie klienta kiedy juz nie bedzie potrzebny. Nie wiem ile researchu zrobiles ale to rozlegly temat takze jak chcesz wiecej info moze tu zalukaj

https://softwareengineering.stackexchange.com/questions/330364/correct-way-of-using-httpclient

[GaHee]

@bacteria: Właśnie przeglądam ten wątek. ;) To teraz trochę z innej strony, czy pisząc wrapper do restowego API na własny użytek powinienem przejmować się problemem z dns cachingiem, czy raczej olać ten temat?

[zawadzio]

@GaHee: RestSharp?

[MamCieNaHita]

@bacteria: przecież IDisposable jest właśnie po to, żeby mieć RAII mimo GC z .NETa

[GaHee]

@MamCieNaHita: Zgadzam się z tobą, ale w przypadku HttpClienta IDisposable jest tylko przez HttpMessageHandler. A imo, lepiej jest nie zwolnić tego zasobu, niż natworzyć socketów. Tutaj temat: https://docs.microsoft.com/en-us/azure/architecture/antipatterns/improper-instantiation/