Classloader leak due to ApiClient$SecureTrustManager

[amontorfano]

Description of the problem

When the java sdk client is used in a war deployed on JBoss EAP, a classloader leak occurs after a cycle of deployment/undeployment. In the long run, (after many cycles of deployment/undepoyment) this leads to an exhaustion of the Metaspace memory pool, since the GC is unable to free any allocated memory. Eventually, all deployments are bound to fail.

Analysis of the heap dump shows that the classloader is retained by an instance of com.docusign.esign.client.ApiClient$SecureTrustManager.

Steps to reproduce

Environment:

• OpenJDK 11
• JBoss EAP 7.3 patch 10
• JAVA_OPTS: -XX:MaxMetaspaceSize=172M -XX:MetaspaceSize=156M

1. Download the test case from https://github.com/amontorfano/demo-metaspace.git
2. Compile with mvn package
3. Deploy to an instance of Jboss
4. Undeploy
5. Repeat until metaspace exhaustion

Desired behaviour

Normally, one would observe the metaspace GC run, and any unused memory would be freed, when approaching the upper Metaspace limit; in this case, no classes are unloaded and deployment fails because of Metaspace OOM.

[jglassenberg]

My apologies for the delayed response from anyone at Docusign. I work on the Product Management side for our SDKs.

Our engineers are investigating this issue at this time. I don't have an ETA for any code changes to resolve this, but will provide updates here as they come.

[vinz]

Hi @amontorfano ,

Happy to report that the fix is now included in latest docusign-esign-java SDK:

https://central.sonatype.com/artifact/com.docusign/docusign-esign-java.

Please check and revert so that we can close this github issue.

Thanks, Vinay

[avinfinity]

This issue has been resolved. Hence we are closing this ticket. Please feel free to re-open this ticket in case you feel this issue is still pertaining with latest package.