Skip to content

WebIdentityTokenFileCredentialsProvider is not AutoClosable, causing memory leak #3270

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
BartXZX opened this issue Jun 24, 2022 · 3 comments · Fixed by #3440
Closed

WebIdentityTokenFileCredentialsProvider is not AutoClosable, causing memory leak #3270

BartXZX opened this issue Jun 24, 2022 · 3 comments · Fixed by #3440
Labels
bug This issue is a bug.

Comments

@BartXZX
Copy link

BartXZX commented Jun 24, 2022

Describe the bug

The DefaultCredentialsProvider (AutoClosable) contains a WebIdentityTokenFileCredentialsProvider (not AutoClosable) which in turn creates its own StsWebIdentityCredentialsProvider (AutoClosable).

This StsWebIdentityCredentialsProvider creates and closes its own STS client. When we create our own (default) clients, use them, and close them, the DefaultCredentialsProvider gets closed. The WebIdentityTokenFileCredentialsProvider however, does not get closed, because it is not AutoClosable, which in turn means that the STS client all the way down does not get closed.

This results in the IdleConnectionReaper hanging on to many ConnectionManagers, and memory to increase.

As a fix we are reusing the client that we were previously re-creating, which is better anyway.
This issue is somewhat similar to a previous issue I filed earlier, except in that case it was Lazy<> that was not AutoClosable
#2149.

Expected Behavior

I expect WebIdentityTokenFileCredentialsProvider to close the resources it creates.

Current Behavior

Currently WebIdentityTokenFileCredentialsProvider is not closing the StsWebIdentityCredentialsProvider it creates.

Reproduction Steps

Using the client is necessary, because the DefaultCredentialsProvider only get created when using it.

while (true) {
  try (StsClient sts = StsClient.builder().build()) {
    AssumeRoleRequest request = AssumeRoleRequest.builder()
                .roleArn("myRole)
                .roleSessionName("mysessionname")
                .build();
    sts.assumeRole(request);
  }
}

Possible Solution

Make WebIdentityTokenFileCredentialsProvider implement AutoClosable, and close the StsWebIdentityCredentialsProvider.

Additional Information/Context

No response

AWS Java SDK version used

2.17.206

JDK version used

17

Operating System and version

openjdk 17 docker image

@BartXZX BartXZX added bug This issue is a bug. needs-triage This issue or PR still needs to be triaged. labels Jun 24, 2022
@debora-ito
Copy link
Member

Thank you for reaching out @BartXZX, it's a reasonable request. We added to our backlog to make WebIdentityTokenFileCredentialsProvider implement AutoCloseable.

@github-actions
Copy link

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

@jonathaff
Copy link

jonathaff commented Nov 8, 2022

@BartXZX what was your workaround to solve it?

Can you confirm that the last version of aws-sdk-java-v2 solved the issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This issue is a bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants