Skip to content
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

Proliferation of BouncyCastleProvider instances causing large memory consumption #94

Closed
bbrowning opened this issue May 31, 2016 · 5 comments
Milestone

Comments

@bbrowning
Copy link

bbrowning commented May 31, 2016

The upgrade to BouncyCastle 1.54 has introduced a bug where we're creating a new BouncyCastleProvider instance for every X509AuxCertificate we create. The code path that leads to this is:

CertificateFactory factory = SecurityHelper.getCertificateFactory("X.509");

which calls
static CertificateFactory getCertificateFactory(final String type, final Provider provider)

which ends up creating a new instance of org.bouncycastle.jcajce.provider.asymmetric.x509.CertificateFactory that instantiates a new BCJcaJceHelper at
https://github.com/bcgit/bc-java/blob/r1rv54/prov/src/main/java/org/bouncycastle/jcajce/provider/asymmetric/x509/CertificateFactory.java#L40
which ends up returning a new instance of BouncyCastleProvider at
https://github.com/bcgit/bc-java/blob/r1rv54/prov/src/main/java/org/bouncycastle/jcajce/util/BCJcaJceHelper.java#L22 unless the provider is registered already.

This causes the memory consumption of each X509AuxCertificate to explode for me, leading to a baseline memory usage of about 65MB of just BouncyCastleProvider objects in every JRuby runtime. This may be related to #86.

@bbrowning
Copy link
Author

Steps to reproduce with link to a proposed temporary fix at https://gist.github.com/bbrowning/a6af5239ad35dcdd83212a729d6896c5

@headius
Copy link
Member

headius commented Jun 8, 2016

I'm working on a test now.

headius added a commit that referenced this issue Jun 8, 2016

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
Still no good test for this, since I can't get it to reproduce
locally.
@headius
Copy link
Member

headius commented Jun 8, 2016

I've pulled in @bbrowning's fix but I have been unable to reproduce this locally. We still need a test that confirms the provider stays the same. See my test in 13e964a.

@headius headius added this to the 0.9.16 milestone Jun 8, 2016
@kares
Copy link
Member

kares commented Jun 9, 2016

for the record ... the regression in 1.54 has been (mostly) caused by bcgit/bc-java@4eecbee

@kares
Copy link
Member

kares commented Jun 9, 2016

released jruby-openssl 0.9.17 ... thanks @bbrowning for the investigation and the quick fix.
well also have a test checking that there aren't 2 providers created in place now.

@kares kares closed this as completed Jun 9, 2016
pierre added a commit to killbill/killbill-paypal-express-plugin that referenced this issue Aug 12, 2016
See jruby/jruby-openssl#94.

Signed-off-by: Pierre-Alexandre Meyer <pierre@mouraf.org>
pierre added a commit to killbill/killbill-cybersource-plugin that referenced this issue Aug 12, 2016
See jruby/jruby-openssl#94.

Signed-off-by: Pierre-Alexandre Meyer <pierre@mouraf.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants