Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
2.0.0
-
None
-
None
Description
Each time a JCloud context involving BouncyCastleCrypto is created, a new instance of BouncyCastleProvider will be registered in JCE. It happens that these JCE Providers will never be garbage-collected, because JceSecurity keeps them all referenced in an IdentityMap. See JDK-8168469.
This memory leak can be completely insignificant in many applications where only very few JClouds contexts are ever created, but it can also become a real issue in applications which create many short-lived JClouds contexts (a single BouncyCastleProvider object retains ~700KB on the heap, so hundreds of them is hundreds of megabytes).
An example of such a problematic application is Jenkins, with its "jclouds-plugin". See JENKINS-47967 for a detailed description of the issue in this context.
As a workaround in this Jenkins plugin, I've proposed to stop relying on BouncyCastleCrypto (and thus on BouncyCastleCryptoModule), and to use instead an (otherwise similar) implementation of Crypto which always re-uses a single BouncyCastleProvider object. See JenkinsBouncyCastleCrypto.java
I think the same could be done directly in JClouds (by applying similar change in BouncyCastleCrypto.java). If you think it's the right approach, then I can submit a PR.
Note: bug detected in Jenkins with JClouds 2.0.0, which is not the latest release, but it looks like none of the JClouds code involved in this issue has been changed since then.