MinioClient generates a lot of connections in TIME_WAIT

[DynamicOperationsFacilitator]

I ran into some stability problems while listing and downloading metadata from one of our services using Minio. I've traced it down to the RestSharp dependency in the minio-dotnet client. I've added a comment regarding this in an existing issue in the RestSharp repo restsharp/RestSharp#1322

To reproduce issue I've made two equivalent scripts for .net core 2.2 using the most recent (at this time) version of the Minio SDK as well as the Amazon SDK as a reference. You can download them from this gist: https://gist.github.com/DynamicOperationsFacilitator/fc3148bad05552fd5138a12c79399c17

While listing buckets in an infinite loop isn't really a normal workload. it's a fast operation that highlights the difference in how well persistent HTTP connections work in minio-dotnet vs. awssdk.s3

Example of how to run:

git clone https://gist.github.com/DynamicOperationsFacilitator/fc3148bad05552fd5138a12c79399c17
cd fc3148bad05552fd5138a12c79399c17
docker-compose build && docker-compose up -d
docker-compose exec minioclient netstat -n
docker-compose exec amazons3client netstat -n

Sample output from running netstat in each container:

$ docker-compose exec minioclient netstat -n |  head
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 172.19.0.4:37547        172.19.0.2:9000         TIME_WAIT
tcp        0      0 172.19.0.4:36883        172.19.0.2:9000         TIME_WAIT
tcp        0      0 172.19.0.4:46841        172.19.0.2:9000         TIME_WAIT
tcp        0      0 172.19.0.4:34095        172.19.0.2:9000         TIME_WAIT
tcp        0      0 172.19.0.4:46111        172.19.0.2:9000         TIME_WAIT
tcp        0      0 172.19.0.4:38251        172.19.0.2:9000         TIME_WAIT
tcp        0      0 172.19.0.4:43549        172.19.0.2:9000         TIME_WAIT
tcp        0      0 172.19.0.4:42931        172.19.0.2:9000         TIME_WAIT

$ docker-compose exec minioclient netstat -n | wc -l
4019

$ docker-compose exec amazons3client netstat -n
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0    550 172.19.0.5:38061        172.19.0.2:9000         ESTABLISHED
tcp        0      0 172.19.0.5:34379        172.19.0.2:9000         ESTABLISHED
Active UNIX domain sockets (w/o servers)
Proto RefCnt Flags       Type       State         I-Node   Path

[DynamicOperationsFacilitator]

Using dotnet core 2.1or the images yields the same results.

[kannappanr]

@DynamicOperationsFacilitator Thanks for reporting this issue. We will take a look at it.

[harshavardhana]

This perhaps because dotnet client is not able to effectively use keep-alive

[ElderJames]

We can use HttpClientFactory to create HttpClient in MinioClient or cache the HttpClients.

[lucius-the]

Run into the same problem, issue #364
You definitely need to reuse HttpClient.

Read more:
https://aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/
https://docs.microsoft.com/en-us/azure/architecture/antipatterns/improper-instantiation/

HttpClient is thread-safe since Framework 4.5, don't know what happens in previous versions.

[tonyqus]

Hi, has this issue been resolved? This issue may potentially make .net program unstable.

[knorring]

I think MinioClient uses RestSharp behind the scenes. RestSharp currently have an open issue that could be related: restsharp/RestSharp#1322?

[harshavardhana]

We moved away from RestSharp with a full re-implementation with HttpClientFactory