bulk delete issues fails with java lang null pointer exception

[Eric Sebian]

Technical details

Log's referral number: 151d809c-0c09-4054-872e-553baedd0947

Cause

Referer URL: http://nyc-cbmweb-d29:8080/secure/views/bulkedit/BulkDeleteDetailsValidation.jspa

java.lang.NullPointerException

java.lang.NullPointerException
	at com.atlassian.jira.web.action.issue.bulkedit.BulkOperationProgress.doProgress(BulkOperationProgress.java:76) [classes/:?]

[Andy Heinzer]

Hi Eric,

It is difficult to say exactly what is causing this problem from just this error.  However the most common cause is likely some kind of corruption of the indexes in Jira.   For example, if the index was not updated for an issue that was already deleted, Jira could try to delete it again, which would likely create a nullpointerexception because the object has already been removed.

I would recommend first trying to follow this KB:  JIRA reports NullPointerException when trying to delete issues

This has you using the integrity checker to see if perhaps this is something else that Jira could correct.   If you can correct errors there and you still see this error, then I think the next steps would be to rebuild the indexes.  You can try the background index first if you like, it has the advantage that Jira is still usable by you end users while this is running. 

But sometimes you need you use the 'lock Jira and rebuild' option. This completely rebuilds the indexes of Jira from the current data in the database.  The problem is that once you start that, Jira is not accessible to end users until it is complete.  If you have a large or enterprise environment (per the sizing guide), with lots of issues and custom fields, the time it takes to rebuild indexes could be from minutes to hours.   So if you're Jira instance here is in use by a large number of users, it might be best to wait for a maintenance window before doing that kind of reindex to try to troubleshoot this problem.

[Eric Sebian]

thanks, Andrew. But I'm still having the issue. I have re-indexed, cleared integrity issues, restarted tomcat. still getting the below:

Technical details

Log's referral number: 3a0e11b9-70f9-429a-98b9-1172d29bceb2

Cause

Referer URL: http://nyc-cbmweb-d29:8080/browse/JCD-14015?jql=project%20%3D%20JCD

com.atlassian.greenhopper.manager.lexorank.LexoRankIntegrityException: Expected exactly one rank row for issue[id=186884] for rank field[id=14200], but found 2 rows

com.atlassian.greenhopper.manager.lexorank.LexoRankIntegrityException: Expected exactly one rank row for issue[id=186884] for rank field[id=14200], but found 2 rows
 at com.atlassian.greenhopper.manager.lexorank.LexoRankDaoImpl.findByFieldAndIssueId(LexoRankDaoImpl.java:242) [?:?]
 at com.atlassian.greenhopper.service.lexorank.LexoRankOperation.rankInitially(LexoRankOperation.java:152) [?:?]
 at com.atlassian.greenhopper.service.lexorank.LexoRankOperation.execute(LexoRankOperation.java:119) [?:?]
 at com.atlassian.greenhopper.manager.lexorank.LexoRankManagerImpl.performRankOperation(LexoRankManagerImpl.java:300) [?:?]
 at com.atlassian.greenhopper.manager.lexorank.LexoRankManagerImpl.getRankOrRankInitially(LexoRankManagerImpl.java:86) [?:?]
 at com.atlassian.greenhopper.customfield.lexorank.LexoRankCFType.getValueFromIssue(LexoRankCFType.java:121) [?:?]
 at com.atlassian.greenhopper.customfield.lexorank.LexoRankCFType.getValueFromIssue(LexoRankCFType.java:29) [?:?]
 at com.atlassian.jira.issue.fields.ImmutableCustomField.getValue(ImmutableCustomField.java:350) [classes/:?]
 at com.atlassian.jira.issue.managers.DefaultIssueDeleteHelper$DeletedIssueEventData.collectCustomFieldValues(DefaultIssueDeleteHelper.java:288) [classes/:?]
 at com.atlassian.jira.issue.managers.DefaultIssueDeleteHelper$DeletedIssueEventData.<init>(DefaultIssueDeleteHelper.java:275) [classes/:?]
 at com.atlassian.jira.issue.managers.DefaultIssueDeleteHelper.deleteIssue(DefaultIssueDeleteHelper.java:120) [classes/:?]
 at com.atlassian.jira.issue.managers.DefaultIssueManager.deleteIssue(DefaultIssueManager.java:719) [classes/:?]
 at com.atlassian.jira.issue.managers.RequestCachingIssueManager.deleteIssue(RequestCachingIssueManager.java:232) [classes/:?]
 at com.atlassian.jira.bc.issue.DefaultIssueService.delete(DefaultIssueService.java:402) [classes/:?]
 at com.atlassian.jira.bc.issue.DefaultIssueService.delete(DefaultIssueService.java:378) [classes/:?]
 at com.atlassian.jira.web.action.issue.DeleteIssue.doExecute(DeleteIssue.java:23) [classes/:?]
 at webwork.action.ActionSupport.execute(ActionSupport.java:165) [webwork-1.4-atlassian-30.jar:?]
 at com.atlassian.jira.action.JiraActionSupport.execute(JiraActionSupport.java:63) [jira-api-7.7.0.jar:?]
 at webwork.interceptor.DefaultInterceptorChain.proceed(DefaultInterceptorChain.java:39) [webwork-1.4-atlassian-30.jar:?]
 at webwork.interceptor.NestedInterceptorChain.proceed(NestedInterceptorChain.java:31) [webwork-1.4-atlassian-30.jar:?]
 at webwork.interceptor.ChainedInterceptor.intercept(ChainedInterceptor.java:16) [webwork-1.4-atlassian-30.jar:?]
 at webwork.interceptor.DefaultInterceptorChain.proceed(DefaultInterceptorChain.java:35) [webwork-1.4-atlassian-30.jar:?]
 at webwork.dispatcher.GenericDispatcher.executeAction(GenericDispatcher.java:225) [webwork-1.4-atlassian-30.jar:?]
 at webwork.dispatcher.GenericDispatcher.executeAction(GenericDispatcher.java:154) [webwork-1.4-atlassian-30.jar:?]
 at com.atlassian.jira.web.dispatcher.JiraWebworkActionDispatcher.service(JiraWebworkActionDispatcher.java:138) [classes/:?]
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:729) [servlet-api.jar:?]
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230) [catalina.jar:8.5.6]
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165) [catalina.jar:8.5.6]
 at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) [tomcat-websocket.jar:8.5.6]
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192) [catalina.jar:8.5.6]
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165) [catalina.jar:8.5.6]
 at com.atlassian.jira.web.filters.JiraLastFilter.lambda$doFilter$0(JiraLastFilter.java:39) [classes/:?]
 at com.atlassian.jira.web.filters.steps.ChainedFilterStepRunner.doFilter(ChainedFilterStepRunner.java:74) [classes/:?]
 at com.atlassian.jira.web.filters.JiraLastFilter.doFilter(JiraL

[Andy Heinzer]

Ah, that error is much more clear as to the cause.   Please see this KB: Cannot reindex jira due to Expected exactly 2 rows the maximum marker row and the lowest ranked row for rank field.

I suspect that the cause is #3 in that KB, and the KB does provide steps on how to correct this.  You might need to identify if your environment has a duplicate or obsolete rank field that is causing problems here.  Of course I would recommend that you create a backup of your database before you make any direct changes.

If you do not have duplicate or unused ranks fields, then the problem is likely in regards to your existing rank field is either missing a marker, or has more than 2 markers.  

Try to follow that KB and let me know if you run into any problems here.

Andy

[Eric Sebian]

Hi Andrew, I verified that there was only 1 rank custom field (other than an obsolete one). One other fun fact that I forgot to mention is that it is only sub tasks that I cant delete. tasks that are NOT sub tasks and do NOT have sub tasks associated with them, can be deleted. 

This instance is to help he prepare for a migration from Atlassian cloud to a data center version. so the data is currently from the cloud version. I'm working to verify how certain add-ons are going to react and reconfigure them ahead of time. Is there a chance that the issue is originating on the cloud side? Garbage in. Garbage out? How can I verify that? 

I tried restoring the data again but the problem persists. Would it be worth it to re-build the database entirely?

Please advise.  

[Andy Heinzer]

I suppose it is possible that the rank information from Cloud is having this problem too, but if that is the case, then you should have this same problem in the Cloud instance.   I am not sure if you still have access to the Cloud site in order to test this theory.  But if you do, I would recommend trying to test this to understand if the source of the problem is in the Cloud site or not.

If it is, then I strongly recommend creating a support case with our Cloud support team to have them resolve this.  I suspect it will require some downtime for your site in order to correct this.  You can create a support request for our cloud team at https://support.atlassian.com/contact/

But it is also possible that when you migrate from Cloud to Server, there could be an upgrade (or downgrade) task that is not getting executed correctly.   Or worse, that the import process did not complete the migration of all 100% of that data in the backup.  

So I would recommend looking very closely at the $JIRAHOME/log/atlassian-jira.log file at the time the import first took place.  Jira should be logging a percentage when importing all this data.  1-100%.   If you only see the logs indicate that say 90% was imported, and there exists some kind of error, such as a SQL exception, then I think we have a bigger problem here that should be addressed first.

It is possible to follow the KB on fixing the rank field to get past this, but it might be necessary for us to create a support request in order to get your logs first so we can better understand the best next steps to follow.

I can do this on your behalf if you like, or you can also create this on https://support.atlassian.com/contact/ as well.  Please let me know.