java.lang.UnsupportedOperationException

Jenkins JIRA | qiao feng | 3 years ago
  1. 0

    Upgraded over the weekend from JIRA 5.2.x to 6.0.4: tested with a smaller system for final confirmation and decided to go with the upgrade. Upon upgrading, the plugin system failed to initialize with multiple errors, all appearing as: {noformat} 2013-07-20 21:19:41,130 localhost-startStop-1 ERROR [atlassian.plugin.loaders.ScanningPluginLoader] Unable to deploy plugin 'com.atlassian.plugins.remotable-plugins-api-0.8.2' from 'Unit: /var/atlassian/application-data/jira6/plugins/.bundled-plugins/remotable-plugins-api-0.8.2.jar (1372752790000)'. 2013-07-20 21:19:41,130 localhost-startStop-1 ERROR [atlassian.plugin.loaders.ScanningPluginLoader] Because of the following exception: java.lang.UnsupportedOperationException at java.util.AbstractMap$SimpleImmutableEntry.setValue(AbstractMap.java:759) at org.apache.felix.framework.BundleImpl.getCurrentLocalizedHeader(BundleImpl.java:442) at org.apache.felix.framework.Felix.getBundleHeaders(Felix.java:1404) at org.apache.felix.framework.BundleImpl.getHeaders(BundleImpl.java:312) at org.apache.felix.framework.BundleImpl.getHeaders(BundleImpl.java:294) at com.atlassian.plugin.osgi.util.OsgiHeaderUtil.getPluginKey(OsgiHeaderUtil.java:361) at com.atlassian.plugin.osgi.container.felix.FelixOsgiContainerManager$BundleRegistration.install(FelixOsgiContainerManager.java:649) at com.atlassian.plugin.osgi.container.felix.FelixOsgiContainerManager.installBundle(FelixOsgiContainerManager.java:503) at com.atlassian.plugin.osgi.factory.OsgiBundleFactory.create(OsgiBundleFactory.java:128) at com.atlassian.jira.plugin.MasterPluginFactory.create(MasterPluginFactory.java:78) at com.atlassian.plugin.loaders.ScanningPluginLoader.deployPluginFromUnit(ScanningPluginLoader.java:155) at com.atlassian.plugin.loaders.ScanningPluginLoader.loadAllPlugins(ScanningPluginLoader.java:89) at com.atlassian.plugin.loaders.PermissionCheckingPluginLoader.loadAllPlugins(PermissionCheckingPluginLoader.java:24) at com.atlassian.plugin.manager.DefaultPluginManager.init(DefaultPluginManager.java:203) at com.atlassian.jira.plugin.JiraPluginManager.start(JiraPluginManager.java:62) {noformat} Lots of iterations later, including starting from scratch, various PostgreSQL versions, OS X v. Ubuntu, it turns out that the _immediate_ proximate cause on my production server is the presence of the -XX:+AggressiveOpts option in the JVM extra args in setenv.sh, as below: {noformat} JVM_MINIMUM_MEMORY="4g" JVM_MAXIMUM_MEMORY="4g" # # The following are the required arguments for JIRA. # JVM_REQUIRED_ARGS="-Djava.awt.headless=true -Datlassian.standalone=JIRA -Dorg.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER=true -Dmail.mime.decodeparameters=true" # Uncomment this setting if you want to import data without notifications # #DISABLE_NOTIFICATIONS=" -Datlassian.mail.senddisabled=true -Datlassian.mail.fetchdisabled=true -Datlassian.mail.popdisabled=true" #----------------------------------------------------------------------------------- # # In general don't make changes below here # #----------------------------------------------------------------------------------- #----------------------------------------------------------------------------------- # This allows us to actually debug GC related issues by correlating timestamps # with other parts of the application logs. #----------------------------------------------------------------------------------- JVM_EXTRA_ARGS="" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:NewSize=1g" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:MaxNewSize=1g" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+UseConcMarkSweepGC" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+ExplicitGCInvokesConcurrent" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+UseParNewGC" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+UseTLAB" # JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+AggressiveOpts" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+OptimizeStringConcat" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+UseStringCache" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+UseCompressedOops" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -Xloggc:/usr/local/jira/logs/gc.log" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+PrintGCDetails" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+PrintGCDateStamps" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+HeapDumpOnOutOfMemoryError" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:HeapDumpPath=/usr/local/jira/logs" {noformat} In the end, I don't feel like this is highly likely to ever bite anyone, but I figured I'd record it because it might come in useful down the road. I don't _believe_ this affected 6.0.4 when connecting to the HSQL built in database, but I can't confirm that as I don't have good notes as to whether I'd changed the JVM args before switching to PostgreSQL.

    Atlassian JIRA | 3 years ago | John Knight
    java.lang.UnsupportedOperationException
  2. Speed up your debug routine!

    Automated exception search integrated into your IDE

  3. 0

    Upgraded over the weekend from JIRA 5.2.x to 6.0.4: tested with a smaller system for final confirmation and decided to go with the upgrade. Upon upgrading, the plugin system failed to initialize with multiple errors, all appearing as: {noformat} 2013-07-20 21:19:41,130 localhost-startStop-1 ERROR [atlassian.plugin.loaders.ScanningPluginLoader] Unable to deploy plugin 'com.atlassian.plugins.remotable-plugins-api-0.8.2' from 'Unit: /var/atlassian/application-data/jira6/plugins/.bundled-plugins/remotable-plugins-api-0.8.2.jar (1372752790000)'. 2013-07-20 21:19:41,130 localhost-startStop-1 ERROR [atlassian.plugin.loaders.ScanningPluginLoader] Because of the following exception: java.lang.UnsupportedOperationException at java.util.AbstractMap$SimpleImmutableEntry.setValue(AbstractMap.java:759) at org.apache.felix.framework.BundleImpl.getCurrentLocalizedHeader(BundleImpl.java:442) at org.apache.felix.framework.Felix.getBundleHeaders(Felix.java:1404) at org.apache.felix.framework.BundleImpl.getHeaders(BundleImpl.java:312) at org.apache.felix.framework.BundleImpl.getHeaders(BundleImpl.java:294) at com.atlassian.plugin.osgi.util.OsgiHeaderUtil.getPluginKey(OsgiHeaderUtil.java:361) at com.atlassian.plugin.osgi.container.felix.FelixOsgiContainerManager$BundleRegistration.install(FelixOsgiContainerManager.java:649) at com.atlassian.plugin.osgi.container.felix.FelixOsgiContainerManager.installBundle(FelixOsgiContainerManager.java:503) at com.atlassian.plugin.osgi.factory.OsgiBundleFactory.create(OsgiBundleFactory.java:128) at com.atlassian.jira.plugin.MasterPluginFactory.create(MasterPluginFactory.java:78) at com.atlassian.plugin.loaders.ScanningPluginLoader.deployPluginFromUnit(ScanningPluginLoader.java:155) at com.atlassian.plugin.loaders.ScanningPluginLoader.loadAllPlugins(ScanningPluginLoader.java:89) at com.atlassian.plugin.loaders.PermissionCheckingPluginLoader.loadAllPlugins(PermissionCheckingPluginLoader.java:24) at com.atlassian.plugin.manager.DefaultPluginManager.init(DefaultPluginManager.java:203) at com.atlassian.jira.plugin.JiraPluginManager.start(JiraPluginManager.java:62) {noformat} Lots of iterations later, including starting from scratch, various PostgreSQL versions, OS X v. Ubuntu, it turns out that the _immediate_ proximate cause on my production server is the presence of the -XX:+AggressiveOpts option in the JVM extra args in setenv.sh, as below: {noformat} JVM_MINIMUM_MEMORY="4g" JVM_MAXIMUM_MEMORY="4g" # # The following are the required arguments for JIRA. # JVM_REQUIRED_ARGS="-Djava.awt.headless=true -Datlassian.standalone=JIRA -Dorg.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER=true -Dmail.mime.decodeparameters=true" # Uncomment this setting if you want to import data without notifications # #DISABLE_NOTIFICATIONS=" -Datlassian.mail.senddisabled=true -Datlassian.mail.fetchdisabled=true -Datlassian.mail.popdisabled=true" #----------------------------------------------------------------------------------- # # In general don't make changes below here # #----------------------------------------------------------------------------------- #----------------------------------------------------------------------------------- # This allows us to actually debug GC related issues by correlating timestamps # with other parts of the application logs. #----------------------------------------------------------------------------------- JVM_EXTRA_ARGS="" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:NewSize=1g" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:MaxNewSize=1g" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+UseConcMarkSweepGC" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+ExplicitGCInvokesConcurrent" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+UseParNewGC" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+UseTLAB" # JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+AggressiveOpts" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+OptimizeStringConcat" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+UseStringCache" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+UseCompressedOops" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -Xloggc:/usr/local/jira/logs/gc.log" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+PrintGCDetails" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+PrintGCDateStamps" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:+HeapDumpOnOutOfMemoryError" JVM_EXTRA_ARGS="$JVM_EXTRA_ARGS -XX:HeapDumpPath=/usr/local/jira/logs" {noformat} In the end, I don't feel like this is highly likely to ever bite anyone, but I figured I'd record it because it might come in useful down the road. I don't _believe_ this affected 6.0.4 when connecting to the HSQL built in database, but I can't confirm that as I don't have good notes as to whether I'd changed the JVM args before switching to PostgreSQL.

    Atlassian JIRA | 3 years ago | John Knight
    java.lang.UnsupportedOperationException
  4. 0

    java.lang.UnsupportedOperationException

    Google Groups | 6 years ago | sebglon
    java.lang.UnsupportedOperationException

    1 unregistered visitors
    Not finding the right solution?
    Take a tour to get the most out of Samebug.

    Tired of useless tips?

    Automated exception search integrated into your IDE

    Root Cause Analysis

    1. java.lang.UnsupportedOperationException

      No message provided

      at java.util.AbstractMap$SimpleImmutableEntry.setValue()
    2. Java RT
      AbstractMap$SimpleImmutableEntry.setValue
      1. java.util.AbstractMap$SimpleImmutableEntry.setValue(AbstractMap.java:759)
      1 frame
    3. Hudson
      AbstractBuild$AbstractBuildExecution.defaultCheckout
      1. hudson.EnvVars.resolve(EnvVars.java:340)
      2. hudson.scm.SubversionSCM.getLocations(SubversionSCM.java:521)
      3. hudson.scm.SubversionSCM.buildEnvVars(SubversionSCM.java:689)
      4. hudson.model.AbstractBuild.getEnvironment(AbstractBuild.java:938)
      5. hudson.scm.SubversionSCM.checkout(SubversionSCM.java:865)
      6. hudson.model.AbstractProject.checkout(AbstractProject.java:1411)
      7. hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:671)
      7 frames
    4. jenkins.scm
      SCMCheckoutStrategy.checkout
      1. jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
      1 frame
    5. Hudson
      Executor.run
      1. hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:580)
      2. hudson.model.Run.execute(Run.java:1670)
      3. hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
      4. hudson.model.ResourceController.execute(ResourceController.java:88)
      5. hudson.model.Executor.run(Executor.java:231)
      5 frames