java.lang.UnsupportedOperationException

Atlassian JIRA | John Knight | 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. 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
  3. Speed up your debug routine!

    Automated exception search integrated into your IDE

  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. Apache Felix Framework
      BundleImpl.getHeaders
      1. org.apache.felix.framework.BundleImpl.getCurrentLocalizedHeader(BundleImpl.java:442)
      2. org.apache.felix.framework.Felix.getBundleHeaders(Felix.java:1404)
      3. org.apache.felix.framework.BundleImpl.getHeaders(BundleImpl.java:312)
      4. org.apache.felix.framework.BundleImpl.getHeaders(BundleImpl.java:294)
      4 frames
    4. com.atlassian.plugin
      OsgiBundleFactory.create
      1. com.atlassian.plugin.osgi.util.OsgiHeaderUtil.getPluginKey(OsgiHeaderUtil.java:361)
      2. com.atlassian.plugin.osgi.container.felix.FelixOsgiContainerManager$BundleRegistration.install(FelixOsgiContainerManager.java:649)
      3. com.atlassian.plugin.osgi.container.felix.FelixOsgiContainerManager.installBundle(FelixOsgiContainerManager.java:503)
      4. com.atlassian.plugin.osgi.factory.OsgiBundleFactory.create(OsgiBundleFactory.java:128)
      4 frames
    5. com.atlassian.jira
      MasterPluginFactory.create
      1. com.atlassian.jira.plugin.MasterPluginFactory.create(MasterPluginFactory.java:78)
      1 frame
    6. com.atlassian.plugin
      DefaultPluginManager.init
      1. com.atlassian.plugin.loaders.ScanningPluginLoader.deployPluginFromUnit(ScanningPluginLoader.java:155)
      2. com.atlassian.plugin.loaders.ScanningPluginLoader.loadAllPlugins(ScanningPluginLoader.java:89)
      3. com.atlassian.plugin.loaders.PermissionCheckingPluginLoader.loadAllPlugins(PermissionCheckingPluginLoader.java:24)
      4. com.atlassian.plugin.manager.DefaultPluginManager.init(DefaultPluginManager.java:203)
      4 frames
    7. com.atlassian.jira
      JiraPluginManager.start
      1. com.atlassian.jira.plugin.JiraPluginManager.start(JiraPluginManager.java:62)
      1 frame