search

jeremylong / DependencyCheck

OWASP dependency-check is a software composition analysis utility that detects publicly disclosed vulnerabilities in application dependencies.
https://owasp.org/www-project-dependency-check/
Apache License 2.0
6.2k stars 1.25k forks source link

InstanceAlreadyExistsException: org.apache.commons.jcs3:type=JCSAdminBean after upgrade to 9.0.10 #6543

Open veita opened 4 months ago

veita commented 4 months ago

Describe the bug After upgrade from Dependency Check 8.2.1 to 9.0.10 the build of a project with multiple subprojects that use Dependency Check the build pipeline fails with the error below. Downgrade back to 8.2.1 does not work due to NVD API changes.

Version of dependency-check used The problem occurs using version 9.0.10 of the Gradle plugin.

Log file

Could not register JMX bean.
javax.management.InstanceAlreadyExistsException: org.apache.commons.jcs3:type=JCSAdminBean
    at java.management/com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:436)
    at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1865)
    at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:960)
    at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:895)
    at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:320)
    at java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:523)
    at org.apache.commons.jcs3.engine.control.CompositeCacheManager.initialize(CompositeCacheManager.java:271)
    at org.apache.commons.jcs3.engine.control.CompositeCacheManager.getUnconfiguredInstance(CompositeCacheManager.java:212)
    at org.apache.commons.jcs3.JCS.getCacheManager(JCS.java:116)
    at org.apache.commons.jcs3.JCS.getInstance(JCS.java:159)
    at org.owasp.dependencycheck.data.cache.DataCacheFactory.getPomCache(DataCacheFactory.java:155)
    at org.owasp.dependencycheck.analyzer.CentralAnalyzer.initialize(CentralAnalyzer.java:123)
    at org.owasp.dependencycheck.Engine.lambda$loadAnalyzers$1(Engine.java:241)
    at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
    at org.owasp.dependencycheck.Engine.loadAnalyzers(Engine.java:240)
    at org.owasp.dependencycheck.Engine.initializeEngine(Engine.java:207)
    at org.owasp.dependencycheck.Engine.<init>(Engine.java:196)
    at org.owasp.dependencycheck.Engine.<init>(Engine.java:168)
    at org.owasp.dependencycheck.Engine.<init>(Engine.java:158)
    at org.owasp.dependencycheck.gradle.tasks.AbstractAnalyze.analyze(AbstractAnalyze.groovy:88)
    ...

To Reproduce Go to https://github.com/veita/dependency-check-cache-bug and follow the steps described there.

Expected behavior Build should not throw an exception.

aikebah commented 3 months ago

Your reproducer works for me, so there is something else happening in your case.

pprole commented 2 weeks ago

I have the same issue. did u figure out what the root cause was?

jeremylong commented 2 weeks ago

Only time I've run into this is if I have the re-built the project without cleaning. Not sure how you upgraded - did you just copy the contents of the new zip into an already existing location (i.e. where dependency-check was previously installed)? You would need to clear out the bin and lib directory before extracting the new version of the CLI.

mresetar commented 1 week ago

The same issue is happening for me with 9.0.9 and 10.0.2 plugin versions. It is a multiple-project build.

To me, it looks like while multiple tasks are running they clash on registering the same MBean (name clash?).

Interstingly I can't reproduce the issue with project OP has posted.

Below is ST from 10.0.2 plugin run:

Could not register JMX bean.
javax.management.InstanceAlreadyExistsException: org.apache.commons.jcs3:type=JCSAdminBean
        at java.management/com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:436)
        at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1865)
        at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:960)
        at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:895)
        at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:320)
        at java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:523)
        at org.apache.commons.jcs3.engine.control.CompositeCacheManager.initialize(CompositeCacheManager.java:271)
        at org.apache.commons.jcs3.engine.control.CompositeCacheManager.getUnconfiguredInstance(CompositeCacheManager.java:212)
        at org.apache.commons.jcs3.JCS.getCacheManager(JCS.java:116)
        at org.apache.commons.jcs3.JCS.getInstance(JCS.java:159)
        at org.owasp.dependencycheck.data.cache.DataCacheFactory.getPomCache(DataCacheFactory.java:155)
        at org.owasp.dependencycheck.analyzer.CentralAnalyzer.initialize(CentralAnalyzer.java:123)
        at org.owasp.dependencycheck.Engine.lambda$loadAnalyzers$1(Engine.java:241)
        at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
        at org.owasp.dependencycheck.Engine.loadAnalyzers(Engine.java:240)

As @jeremylong says it works when there is a clean build it makes sense because it is less likely that projects will have running dependencyCheckAnalyze at the exact same time.

Quick look at the SO I see this scenario is reported when data cache is not created in singleton fashion (one per JVM). 

            return d

So this from https://github.com/jeremylong/DependencyCheck/blob/708ea51ff0ce71f041f310947cbe32b57b52858b/core/src/main/java/org/owasp/dependencycheck/data/cache/DataCacheFactory.java#L43 should be a singleton.