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

[veita]

trafficstars

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]

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

[pprole]

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

[jeremylong]

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]

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.