Tcp Connection Leak in CLOSED_WAIT when GZIpEnabled is set on TranslateService
See original GitHub issueWhen using the Google.Apis.Translate.v2
package and creating and disposing TranslateService
instances we have noticed a leak of IPv4 connections.
Minimal reproduction:
using System;
using System.Linq;
using System.Net;
using System.Threading.Tasks;
using Google.Apis.Services;
using Google.Apis.Translate.v2;
namespace Churyumov
{
class Program
{
private static readonly NetworkCredential s_clientIdentity =
new NetworkCredential(
"<YOUR>",
"<CREDENTIALS>");
private static readonly string[] s_foreignText =
new[]
{
"The quick brown fox jumps over the lazy dog",
"Le renard brun rapide saute sur le chien paresseux",
"Der schnelle braune Fuchs springt über den faulen Hund"
};
static async Task Main(string[] args)
{
var initializer = new BaseClientService.Initializer
{
ApplicationName = s_clientIdentity.UserName,
ApiKey = s_clientIdentity.Password,
GZipEnabled = true // << changing this to `false` prevents the leak
};
using (var service = new TranslateService(initializer))
{
var request = service.Detections.List(s_foreignText);
var response = await request.ExecuteAsync(default);
foreach (var result in response.Detections)
{
Console.WriteLine(string.Join(", ", result.Select(r => r.Language)));
}
}
Console.WriteLine("Check open connections here!");
}
}
}
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp2.2</TargetFramework>
<RootNamespace>Churyumov</RootNamespace>
<LangVersion>Latest</LangVersion>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Google.Apis.Translate.v2" Version="1.40.0.875" />
</ItemGroup>
</Project>
When inspecting the application on the Check open connections here
line with lsof
you can see the connection to the Google translate service has not been disposed:
$ lsof -p `pgrep dotnet` | grep IPv
dotnet 57839 willspeak 52u IPv4 0xd178e425407bd7f9 0t0 TCP 10.11.1.61:50431->lhr48s08-in-f10.1e100.net:https (ESTABLISHED)
It looks like the TwoWayDelegatingHandler
created when the GZipEnabled
option is set to true
doesn’t properly dispose of an inner handler:
Issue Analytics
- State:
- Created 4 years ago
- Comments:7
Top Results From Across the Web
Troubleshooting connections stuck in CLOSE_WAIT status
6 Answers. CLOSE_WAIT is the state the local TCP state machine is in when the remote host sends a FIN (closes it's connection)...
Read more >This is strictly a violation of the TCP specification
A socket can be in CLOSE_WAIT state indefinitely until the application closes it. Faulty scenarios would be like a file descriptor leak: server ......
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
The build+release process has started for v1.40.1 - it should be available on nuget.org within a couple of hours.
Thanks for reporting this. It’s meant to be disposed in
TwoWayDelegatingHandler
here: https://github.com/googleapis/google-api-dotnet-client/blob/6133df9980b6f65b456564a2488e538dc43a08ef/Src/Support/Google.Apis.Core/Http/TwoWayDelegatingHandler.cs#L55 I’ll investigate further.