Uploaded image for project: 'Jira Data Center'
  1. Jira Data Center
  2. JRASERVER-45161

Deleting an Issue Type can result in a NullPointerException when attempting to perform a number of actions within JIRA

XMLWordPrintable

      NOTE: This bug report is for JIRA Server. Using JIRA Cloud? See the corresponding bug report.

      Summary

      Deleting an Issue Type somehow fails, resulting in a significant number of NullPointerExceptions to be thrown. This causes the operation of JIRA to fail in multiple areas - JIRA Agile, searching for issues, editing issues, retrieving filters and so on.

      Steps to Reproduce

      Deleting the issue type in some sort of specific sequence or event causes this problem to occur. We have not been able to accurately replicate this.

      Expected Results

      Issue types can be deleted without problems occurring.

      Actual Results

      The issue type appears to be deleted, however leaves some orphaned records. This results in the below NullPointerExceptions being thrown:

      2015-09-01 13:18:37,966 http-bio-8443-exec-876 ERROR etamondo 798x1458470x53 wb9ew5 10.137.249.24 /rest/greenhopper/1.0/rapidviewconfig/editmodel.json [web.rapid.view.RapidViewEditResource] Unable to complete GreenHopper REST method 
java.lang.NullPointerException
	at com.atlassian.jira.issue.fields.option.IssueConstantOption.getId(IssueConstantOption.java:48)
	at com.atlassian.jira.issue.fields.config.manager.IssueTypeSchemeManagerImpl.getIssueTypesForConfigScheme(IssueTypeSchemeManagerImpl.java:299)
	at com.atlassian.jira.issue.fields.config.manager.IssueTypeSchemeManagerImpl.getIssueTypesForProject(IssueTypeSchemeManagerImpl.java:263)
	at com.atlassian.jira.issue.fields.config.manager.IssueTypeSchemeManagerImpl.getIssueTypesForProject(IssueTypeSchemeManagerImpl.java:268)
	at com.atlassian.jira.jql.context.FieldConfigSchemeClauseContextUtil.addProjectIssueTypeContextsForProjects(FieldConfigSchemeClauseContextUtil.java:261)
	at com.atlassian.jira.jql.context.FieldConfigSchemeClauseContextUtil.getContextForConfigScheme(FieldConfigSchemeClauseContextUtil.java:147)
	at com.atlassian.jira.jql.permission.CustomFieldClausePermissionChecker.hasPermissionToUseClause(CustomFieldClausePermissionChecker.java:54)
	at com.atlassian.jira.jql.permission.DefaultClausePermissionHandler.hasPermissionToUseClause(DefaultClausePermissionHandler.java:52)
	at com.atlassian.jira.issue.search.managers.DefaultSearchHandlerManager.getVisibleClauseHandlers(DefaultSearchHandlerManager.java:184)
	at com.atlassian.jira.web.component.jql.DefaultAutoCompleteJsonGenerator.getVisibleFieldNamesJson(DefaultAutoCompleteJsonGenerator.java:70)  <+2> (DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:483)
	at com.atlassian.plugin.osgi.hostcomponents.impl.DefaultComponentRegistrar$ContextClassLoaderSettingInvocationHandler.invoke(DefaultComponentRegistrar.java:134)
	at com.sun.proxy.$Proxy402.getVisibleFieldNamesJson(Unknown Source)  <+2> (DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:483)
	at com.atlassian.plugin.osgi.bridge.external.HostComponentFactoryBean$DynamicServiceInvocationHandler.invoke(HostComponentFactoryBean.java:154)
	at com.sun.proxy.$Proxy402.getVisibleFieldNamesJson(Unknown Source)
	at com.atlassian.greenhopper.web.rapid.view.RapidViewEditHelper.getJQLAutoCompleteData(RapidViewEditHelper.java:250)
	at com.atlassian.greenhopper.web.rapid.view.RapidViewEditHelper.getEditModel(RapidViewEditHelper.java:174)
	at com.atlassian.greenhopper.web.rapid.view.RapidViewEditResource$8.call(RapidViewEditResource.java:219)
	at com.atlassian.greenhopper.web.rapid.view.RapidViewEditResource$8.call(RapidViewEditResource.java:212)
	at com.atlassian.greenhopper.web.util.RestCall.response(RestCall.java:42)
	at com.atlassian.greenhopper.web.AbstractResource.createResponse(AbstractResource.java:100)
	at com.atlassian.greenhopper.web.AbstractResource.response(AbstractResource.java:81)
	at com.atlassian.greenhopper.web.rapid.view.RapidViewEditResource.getEditModel(RapidViewEditResource.java:211)  <+2> (DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:483)  <+19> (DispatchProviderHelper.java:234) (DispatchProviderHelper.java:100) (DefaultMethodInvocation.java:61) (ExpandInterceptor.java:38) (DefaultMethodInvocation.java:61) (DispatchProviderHelper.java:132) (DispatchProviderHelper.java:230) (ResourceJavaMethodDispatcher.java:75) (HttpMethodRule.java:288) (RightHandPathRule.java:147) (ResourceClassRule.java:108) (RightHandPathRule.java:147) (RootResourceClassesRule.java:84) (WebApplicationImpl.java:1469) (WebApplicationImpl.java:1400) (WebApplicationImpl.java:1349) (WebApplicationImpl.java:1339) (WebComponent.java:416) (ServletContainer.java:537)
	at com.atlassian.plugins.rest.module.RestDelegatingServletFilter$JerseyOsgiServletContainer.doFilter(RestDelegatingServletFilter.java:178)  <+1> (ServletContainer.java:795)
	at com.atlassian.plugins.rest.module.RestDelegatingServletFilter.doFilter(RestDelegatingServletFilter.java:73)  <+16> (DelegatingPluginFilter.java:78) (IteratingFilterChain.java:42) (ServletFilterModuleContainerFilter.java:77) (ServletFilterModuleContainerFilter.java:63) (DelegatingPluginFilter.java:78) (IteratingFilterChain.java:42) (DelegatingPluginFilter.java:70) (RestServletUtilsUpdaterFilter.java:26) (RestServletUtilsUpdaterFilter.java:40) (DelegatingPluginFilter.java:78) (IteratingFilterChain.java:42) (DelegatingPluginFilter.java:70) (ContextFilter.java:25) (DelegatingPluginFilter.java:78) (IteratingFilterChain.java:42) (DelegatingPluginFilter.java:70)
	at com.atlassian.mywork.client.filter.ServingRequestsFilter.doFilter(ServingRequestsFilter.java:37)  <+3> (DelegatingPluginFilter.java:78) (IteratingFilterChain.java:42) (DelegatingPluginFilter.java:70)
	at com.atlassian.plugins.cors.CorsFilter.doFilter(CorsFilter.java:65)  <+3> (DelegatingPluginFilter.java:78) (IteratingFilterChain.java:42) (DelegatingPluginFilter.java:70)
	at com.atlassian.prettyurls.filter.PrettyUrlsSiteMeshFixupFilter.doFilter(PrettyUrlsSiteMeshFixupFilter.java:36)  <+3> (DelegatingPluginFilter.java:78) (IteratingFilterChain.java:42) (DelegatingPluginFilter.java:70)
	at com.atlassian.prettyurls.filter.PrettyUrlsDispatcherFilter.doFilter(PrettyUrlsDispatcherFilter.java:60)  <+3> (DelegatingPluginFilter.java:78) (IteratingFilterChain.java:42) (DelegatingPluginFilter.java:70)
	at com.atlassian.prettyurls.filter.PrettyUrlsSiteMeshFilter.doFilter(PrettyUrlsSiteMeshFilter.java:92)  <+3> (DelegatingPluginFilter.java:78) (IteratingFilterChain.java:42) (DelegatingPluginFilter.java:70)
	at com.atlassian.prettyurls.filter.PrettyUrlsMatcherFilter.doFilter(PrettyUrlsMatcherFilter.java:56)  <+3> (DelegatingPluginFilter.java:78) (IteratingFilterChain.java:42) (DelegatingPluginFilter.java:70)
	at com.atlassian.labs.botkiller.BotKillerFilter.doFilter(BotKillerFilter.java:36)  <+18> (DelegatingPluginFilter.java:78) (IteratingFilterChain.java:42) (ServletFilterModuleContainerFilter.java:77) (ServletFilterModuleContainerFilter.java:63) (ApplicationFilterChain.java:241) (ApplicationFilterChain.java:208) (AccessLogFilter.java:103) (AccessLogFilter.java:87) (ApplicationFilterChain.java:241) (ApplicationFilterChain.java:208) (XsrfTokenAdditionRequestFilter.java:54) (ApplicationFilterChain.java:241) (ApplicationFilterChain.java:208) (ChainedFilterStepRunner.java:87) (ApplicationFilterChain.java:241) (ApplicationFilterChain.java:208) (IteratingFilterChain.java:46) (DelegatingPluginFilter.java:70)
	at com.atlassian.prettyurls.filter.PrettyUrlsCombinedMatchDispatcherFilter.doFilter(PrettyUrlsCombinedMatchDispatcherFilter.java:61)  <+22> (DelegatingPluginFilter.java:78) (IteratingFilterChain.java:42) (ServletFilterModuleContainerFilter.java:77) (ServletFilterModuleContainerFilter.java:63) (ApplicationFilterChain.java:241) (ApplicationFilterChain.java:208) (SecurityFilter.java:239) (ApplicationFilterChain.java:241) (ApplicationFilterChain.java:208) (TrustedApplicationsFilter.java:100) (ApplicationFilterChain.java:241) (ApplicationFilterChain.java:208) (BaseLoginFilter.java:172) (JiraLoginFilter.java:70) (ApplicationFilterChain.java:241) (ApplicationFilterChain.java:208) (IteratingFilterChain.java:46) (DelegatingPluginFilter.java:70) (OAuthFilter.java:69) (DelegatingPluginFilter.java:78) (IteratingFilterChain.java:42) (DelegatingPluginFilter.java:70)
	at com.atlassian.plugins.rest.module.servlet.RestSeraphFilter.doFilter(RestSeraphFilter.java:40)  <+3> (DelegatingPluginFilter.java:78) (IteratingFilterChain.java:42) (DelegatingPluginFilter.java:70)
	at com.atlassian.prettyurls.filter.PrettyUrlsCombinedMatchDispatcherFilter.doFilter(PrettyUrlsCombinedMatchDispatcherFilter.java:61)  <+9> (DelegatingPluginFilter.java:78) (IteratingFilterChain.java:42) (ServletFilterModuleContainerFilter.java:77) (ServletFilterModuleContainerFilter.java:63) (ApplicationFilterChain.java:241) (ApplicationFilterChain.java:208) (AbstractJohnsonFilter.java:71) (ApplicationFilterChain.java:241) (ApplicationFilterChain.java:208)
	at org.tuckey.web.filters.urlrewrite.RuleChain.handleRewrite(RuleChain.java:176)
	at org.tuckey.web.filters.urlrewrite.RuleChain.doRules(RuleChain.java:145)
	at org.tuckey.web.filters.urlrewrite.UrlRewriter.processRequest(UrlRewriter.java:92)  <+10> (UrlRewriteFilter.java:394) (ApplicationFilterChain.java:241) (ApplicationFilterChain.java:208) (GzipFilter.java:82) (GzipFilter.java:59) (JiraGzipFilter.java:55) (ApplicationFilterChain.java:241) (ApplicationFilterChain.java:208) (IteratingFilterChain.java:46) (DelegatingPluginFilter.java:70)
	at com.atlassian.analytics.client.filter.JiraAnalyticsFilter.doFilter(JiraAnalyticsFilter.java:41)  <+4> (AbstractHttpFilter.java:31) (DelegatingPluginFilter.java:78) (IteratingFilterChain.java:42) (DelegatingPluginFilter.java:70)
	at com.atlassian.prettyurls.filter.PrettyUrlsCombinedMatchDispatcherFilter.doFilter(PrettyUrlsCombinedMatchDispatcherFilter.java:61)  <+40> (DelegatingPluginFilter.java:78) (IteratingFilterChain.java:42) (ServletFilterModuleContainerFilter.java:77) (ServletFilterModuleContainerFilter.java:63) (ApplicationFilterChain.java:241) (ApplicationFilterChain.java:208) (ChainedFilterStepRunner.java:87) (ApplicationFilterChain.java:241) (ApplicationFilterChain.java:208) (AbstractCachingFilter.java:33) (AbstractHttpFilter.java:31) (ApplicationFilterChain.java:241) (ApplicationFilterChain.java:208) (AbstractEncodingFilter.java:41) (AbstractHttpFilter.java:31) (PathMatchingEncodingFilter.java:45) (AbstractHttpFilter.java:31) (ApplicationFilterChain.java:241) (ApplicationFilterChain.java:208) (JiraStartupChecklistFilter.java:79) (ApplicationFilterChain.java:241) (ApplicationFilterChain.java:208) (MultipartBoundaryCheckFilter.java:41) (ApplicationFilterChain.java:241) (ApplicationFilterChain.java:208) (ChainedFilterStepRunner.java:87) (JiraFirstFilter.java:60) (ApplicationFilterChain.java:241) (ApplicationFilterChain.java:208) (StandardWrapperValve.java:220) (StandardContextValve.java:122) (AuthenticatorBase.java:501) (StandardHostValve.java:171) (ErrorReportValve.java:103) (StandardEngineValve.java:116) (AccessLogValve.java:950) (CoyoteAdapter.java:408) (AbstractHttp11Processor.java:1070) (AbstractProtocol.java:611) (JIoEndpoint.java:316)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
	at java.lang.Thread.run(Thread.java:745)

      Workaround

      This can be fixed by following the workaround in NullPointerException when creating issue, editing issue, move issue, accessing the Screen tab from the Project.

        1. deleteIssueTypeSQL.txt
          761 kB
        2. missingIssueType.png
          missingIssueType.png
          64 kB

            [JRASERVER-45161] Deleting an Issue Type can result in a NullPointerException when attempting to perform a number of actions within JIRA

            Chris Solgat added a comment -

            So far the only fix version is for Cloud. Any possibility of knowing what Server version this will appear in?

            Chris Solgat added a comment - So far the only fix version is for Cloud. Any possibility of knowing what Server version this will appear in?

            Oswaldo Hernandez (Inactive) added a comment -

            Thanks for that investigation tcampbell, that should be enough for us to move forwards with trying to come up with fix.

            Cheers,
            Os.

            Oswaldo Hernandez (Inactive) added a comment - Thanks for that investigation tcampbell , that should be enough for us to move forwards with trying to come up with fix. Cheers, Os.

            Trevor Campbell (Inactive) added a comment -

            There is an obvious race condition in how the optionconfiguration entries are updated. If two or more deletes happen concurrently each will for each configuration

            • load the full list of issue type into memory
            • remove the issue type from the list
            • remove all entries in the database for that configuration
            • rewrite the database entries from the list.

            So entries removed by the first delete issue type operation may be rewritten by the second overlapping delete issue type operation.
            This happens beginning at com.atlassian.jira.issue.fields.config.manager.IssueTypeSchemeManagerImpl#removeOptionFromAllSchemes and going through com.atlassian.jira.issue.fields.option.OptionSetManager#updateOptionSet

            Trevor Campbell (Inactive) added a comment - There is an obvious race condition in how the optionconfiguration entries are updated. If two or more deletes happen concurrently each will for each configuration load the full list of issue type into memory remove the issue type from the list remove all entries in the database for that configuration rewrite the database entries from the list. So entries removed by the first delete issue type operation may be rewritten by the second overlapping delete issue type operation. This happens beginning at com.atlassian.jira.issue.fields.config.manager.IssueTypeSchemeManagerImpl#removeOptionFromAllSchemes and going through com.atlassian.jira.issue.fields.option.OptionSetManager#updateOptionSet

            Chris Solgat added a comment -

            I ran another delete and captured the SQL statements and cleaned up the log file. This was simply a delete and not a duplication of the problem just to provide the information I spoke about earlier. While looking at the entirety of the Delete process will likely be needed, I might recommend starting at this statement and going from there –

            2016-02-16 19:44:20,253 http-bio-8080-exec-24 userid 1234x56789x1 z23j4c /secure/admin/DeleteIssueType.jspa 70ms "DELETE FROM dbo.optionconfiguration WHERE FIELDID='issuetype' AND FIELDCONFIG='10000'"

            The next 900+ lines show how that scheme is being rebuilt. From the above delete statement until the entity is completely rebuilt was over 2 seconds (with no other traffic or load on the system). I think the biggest key will be finding out how that list is being stored/recalled, and possibly whether or not a check against issuetype table can be implemented after the issue type is deleted from the table (last SQL entry).

            Chris Solgat added a comment - I ran another delete and captured the SQL statements and cleaned up the log file. This was simply a delete and not a duplication of the problem just to provide the information I spoke about earlier. While looking at the entirety of the Delete process will likely be needed, I might recommend starting at this statement and going from there – 2016-02-16 19:44:20,253 http-bio-8080-exec-24 userid 1234x56789x1 z23j4c /secure/admin/DeleteIssueType.jspa 70ms "DELETE FROM dbo.optionconfiguration WHERE FIELDID='issuetype' AND FIELDCONFIG='10000'" The next 900+ lines show how that scheme is being rebuilt. From the above delete statement until the entity is completely rebuilt was over 2 seconds (with no other traffic or load on the system). I think the biggest key will be finding out how that list is being stored/recalled, and possibly whether or not a check against issuetype table can be implemented after the issue type is deleted from the table (last SQL entry).

            Oswaldo Hernandez (Inactive) added a comment -

            Thanks heaps for that chris.solgat.

            That definitely looks like a very plausible theory, and it should guide the investigation. I have asked one of our engineers to timebox an investigation into this issue. Hopefully, we will be able to finally track this down.

            Regards,

            Oswaldo Hernández.
            JIRA Bugmaster.
            [Atlassian].

            Oswaldo Hernandez (Inactive) added a comment - Thanks heaps for that chris.solgat . That definitely looks like a very plausible theory, and it should guide the investigation. I have asked one of our engineers to timebox an investigation into this issue. Hopefully, we will be able to finally track this down. Regards, Oswaldo Hernández. JIRA Bugmaster. [Atlassian] .

            Chris Solgat added a comment -

            I have a little more information that may be helpful. I was attempting to re-create this in a test environment, but was unable to and had to abandon my efforts to work on other problems. I did however have the SQL logging turned on and noticed some very helpful information about how it makes updates to the database. While I could not verify 100%, what I did see is that every time an issue type is deleted, the Default Issue Type Scheme is deleted from the database and then rebuilt one issue type at a time. This is significant because it would need to store the list in a variable (or retrieve it from cache/memory) and then use this to rebuild the new Scheme. If a second issue type was deleted while this process was happening, my theory is that it would pull the list from memory, which could still have the previously removed issue type still present. Then when it rebuilt the scheme, it would have an entry for a non-existing issue type. I don't remember the exact timings, but I know that the total time to delete an issue type for us was in the multiple seconds range (>= 3-5 seconds). As I said, I was not able to verify any of this, but I did see enough information to lead me to believe that there is a good possibility that a subsequent deletion could be the main cause. I can try to find the old log files and get them cleaned up, but there would be no guarantees.

            Chris Solgat added a comment - I have a little more information that may be helpful. I was attempting to re-create this in a test environment, but was unable to and had to abandon my efforts to work on other problems. I did however have the SQL logging turned on and noticed some very helpful information about how it makes updates to the database. While I could not verify 100%, what I did see is that every time an issue type is deleted, the Default Issue Type Scheme is deleted from the database and then rebuilt one issue type at a time. This is significant because it would need to store the list in a variable (or retrieve it from cache/memory) and then use this to rebuild the new Scheme. If a second issue type was deleted while this process was happening, my theory is that it would pull the list from memory, which could still have the previously removed issue type still present. Then when it rebuilt the scheme, it would have an entry for a non-existing issue type. I don't remember the exact timings, but I know that the total time to delete an issue type for us was in the multiple seconds range (>= 3-5 seconds). As I said, I was not able to verify any of this, but I did see enough information to lead me to believe that there is a good possibility that a subsequent deletion could be the main cause. I can try to find the old log files and get them cleaned up, but there would be no guarantees.

            Oswaldo Hernandez (Inactive) added a comment -

            You are welcome chris.solgat, glad to know you were able to resolve the issue with the information in the KB article

            Regards,

            Oswaldo Hernández.
            JIRA Bugmaster.
            [Atlassian].

            Oswaldo Hernandez (Inactive) added a comment - You are welcome chris.solgat , glad to know you were able to resolve the issue with the information in the KB article Regards, Oswaldo Hernández. JIRA Bugmaster. [Atlassian] .

            Chris Solgat added a comment -

            Thank you, yes we were experiencing problems with the database. The fix mentioned in the KB article did fix this for us. I had just noticed that this was Closed out with an Incomplete resolution, and with what I saw in the KB article, there is no known root cause for why this happens. I was simply providing details that were specific to my scenario in hopes that it may help find out the root cause.

            Chris Solgat added a comment - Thank you, yes we were experiencing problems with the database. The fix mentioned in the KB article did fix this for us. I had just noticed that this was Closed out with an Incomplete resolution, and with what I saw in the KB article, there is no known root cause for why this happens. I was simply providing details that were specific to my scenario in hopes that it may help find out the root cause.

            Oswaldo Hernandez (Inactive) added a comment -

            Hi chris.solgat,

            Upon a quick review of your comment it seems like the database of your JIRA instance is suffering from some data integrity issues.

            Consequenly, could you please raise a support ticket with us at https://support.atlassian.com so we can help you get your database back into working order? Thanks

            Regards,

            Oswaldo Hernández.
            JIRA Bugmaster.
            [Atlassian].

            Oswaldo Hernandez (Inactive) added a comment - Hi chris.solgat , Upon a quick review of your comment it seems like the database of your JIRA instance is suffering from some data integrity issues. Consequenly, could you please raise a support ticket with us at https://support.atlassian.com so we can help you get your database back into working order? Thanks Regards, Oswaldo Hernández. JIRA Bugmaster. [Atlassian] .

            Chris Solgat added a comment - - edited

            We just ran into this today. One thing I noticed, but did not see mentioned here is that all of my entries were being held up by the FIELDCONFIG 10000 (Default Issue Type Scheme). From the UI, these issue types were not present in any other Schemes. Since I'm assuming that the Default Issue Type Scheme would be used when doing a Create or Search for Issues, these "missing" items are causing the problems. Also, when I look at my Default Issue Type Scheme, I can see that there are blank entries for the missing issue types. I'm putting a screenshot on here to show what I'm talking about. You will see one blank entry, but I have a total of four missing entries at the moment. I also noticed that there is no way to remove an issue type from the Default Issue Type Scheme (which I'm guessing is by design), but what if that's what's causing these issue types to be held onto.

            Chris Solgat added a comment - - edited We just ran into this today. One thing I noticed, but did not see mentioned here is that all of my entries were being held up by the FIELDCONFIG 10000 (Default Issue Type Scheme). From the UI, these issue types were not present in any other Schemes. Since I'm assuming that the Default Issue Type Scheme would be used when doing a Create or Search for Issues, these "missing" items are causing the problems. Also, when I look at my Default Issue Type Scheme, I can see that there are blank entries for the missing issue types. I'm putting a screenshot on here to show what I'm talking about. You will see one blank entry, but I have a total of four missing entries at the moment. I also noticed that there is no way to remove an issue type from the Default Issue Type Scheme (which I'm guessing is by design), but what if that's what's causing these issue types to be held onto.

              ohernandez@atlassian.com Oswaldo Hernandez (Inactive)
              dcurrie@atlassian.com Dave C
              Affected customers:
              3 This affects my team
              Watchers:
              19 Start watching this issue

                Created:
                Updated:
                Resolved: