You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Thank you for reaching out @BartXZX, it's a reasonable request. We added to our backlog to make WebIdentityTokenFileCredentialsProvider implement AutoCloseable.
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.
Describe the bug
The
DefaultCredentialsProvider (AutoClosable)
contains aWebIdentityTokenFileCredentialsProvider (not AutoClosable)
which in turn creates its ownStsWebIdentityCredentialsProvider (AutoClosable)
.This
StsWebIdentityCredentialsProvider
creates and closes its own STS client. When we create our own (default) clients, use them, and close them, theDefaultCredentialsProvider
gets closed. TheWebIdentityTokenFileCredentialsProvider
however, does not get closed, because it is notAutoClosable
, 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 notAutoClosable
#2149.
Expected Behavior
I expect
WebIdentityTokenFileCredentialsProvider
to close the resources it creates.Current Behavior
Currently
WebIdentityTokenFileCredentialsProvider
is not closing theStsWebIdentityCredentialsProvider
it creates.Reproduction Steps
Using the client is necessary, because the
DefaultCredentialsProvider
only get created when using it.Possible Solution
Make
WebIdentityTokenFileCredentialsProvider
implementAutoClosable
, and close theStsWebIdentityCredentialsProvider
.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
The text was updated successfully, but these errors were encountered: