JIRA 7 : scripting reindex issue => stackoverflow on issueIndexManager.reIndex(issue)

Jerome F_ December 8, 2015

Hi,


I'm trying to have caculated fields in JIRA  with Script Runner and these calculated field are reindexed for JQL filters. To perform that, I perform all my calculations on a "Scripted Field" which updates an "Integer Field" that needs to be-reindexed.

 

My code is :

import com.atlassian.jira.component.ComponentAccessor

import com.atlassian.jira.issue.index.IssueIndexManager

import com.atlassian.jira.util.ImportUtils


IssueIndexManager issueIndexManager = ComponentAccessor.getComponent(IssueIndexManager.class);

boolean wasIndexing = ImportUtils.isIndexIssues();

ImportUtils.setIndexIssues(true);

issueIndexManager.reIndex(issue);
  // line which creates the stackoverflow

ImportUtils.setIndexIssues(wasIndexing);


return 1

 

But I have a unknown error, with this message:

java.lang.StackOverflowError
at  net.sourceforge.jtds.jdbc.JtdsStatement.(JtdsStatement.java:159)
at  net.sourceforge.jtds.jdbc.JtdsPreparedStatement.(JtdsPreparedStatement.java:100)
at  net.sourceforge.jtds.jdbc.JtdsConnection.prepareStatement(JtdsConnection.java:2492)
at  org.apache.commons.dbcp.DelegatingConnection.prepareStatement(DelegatingConnection.java:295)
at  org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.prepareStatement(PoolingDataSource.java:318)
at  org.ofbiz.core.entity.jdbc.interceptors.connection.DelegatingConnection.prepareStatement(DelegatingConnection.java:137)
at  org.ofbiz.core.entity.jdbc.SQLProcessor.prepareStatement(SQLProcessor.java:563)
at  org.ofbiz.core.entity.GenericDAO.select(GenericDAO.java:621)
at  org.ofbiz.core.entity.GenericDAO.select(GenericDAO.java:592)
at  org.ofbiz.core.entity.GenericHelperDAO.findByPrimaryKey(GenericHelperDAO.java:97)
at  org.ofbiz.core.entity.GenericDelegator.findByPrimaryKey(GenericDelegator.java:611)
at  org.ofbiz.core.entity.GenericDelegator.findByPrimaryKey(GenericDelegator.java:649)
at  com.atlassian.jira.ofbiz.DefaultOfBizDelegator.findByPrimaryKey(DefaultOfBizDelegator.java:448)
at  com.atlassian.jira.ofbiz.DefaultOfBizDelegator.findByPrimaryKey(DefaultOfBizDelegator.java:440)
at  com.atlassian.jira.ofbiz.DefaultOfBizDelegator.findById(DefaultOfBizDelegator.java:431)
at  com.atlassian.jira.ofbiz.WrappingOfBizDelegator.findById(WrappingOfBizDelegator.java:243)
at  com.atlassian.jira.issue.managers.DefaultIssueManager.getIssue(DefaultIssueManager.java:149)
at  ...

 

Is there someone to help us ? Script Runner also advices to use "IssueIndexingService.reIndex(Issue)", how can we use this new feature?

 

Regards,

Jerome

 

Configuration:

  • JIRA 7.0.0
  • Script Runner 4.2.0.1

3 answers

1 accepted

1 vote
Answer accepted
JamieA
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
December 10, 2015

You cannot make any modifications within a calculated field... the only thing you can do is pull information from the current issue, or other issues, or outside of the JIRA environment altogether, and display it.

When JIRA reindxes an issue it gets the value from all custom fields. In your case, that act reindexes the issue, which gets the value from the script field, which reindexes the issue, which... etc. Infinite recursion and stack overflow ensues.

You should not need to reindex the issue at all... I'd take a step back, remove that code, see what is not working, and ask a new question. 

If your script fields have a searcher configured you should be able to search on them fine.

 

1 vote
Juergen Krieger
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
March 6, 2016

I am using 

IssueIndexingService issueIndexService = ComponentAccessor.getComponent(IssueIndexingService.class);

to get the index service.
And I have to disagree. There sure is a use for re-indexing an issue.
You are correct that your custom searcher would update the issue, though only on access.
So until someone access the ticket and it updates itself, the index will contain the old values meaning that filter ( dashboards ) that would show this issue on the updated values will not contain that issue until it is re-indexed.
JamieA
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
March 7, 2016

I agree with that but I think your premise that this is a correct use of calculated fields is wrong. Reindexing issues periodically or when some external value may have changed is not very scalable. I'd consider custom JQL functions or some custom report... 

Juergen Krieger
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
March 22, 2016

I didn't mean in combination of calculated fields, was talking about the service itself.

In our case we do not have calculated fields but plugins that define a custom field and bring their own searcher along. 

Keep the wrong use aside, there is no other way to validate permissions on a ticket without a field inheriting userpicker, grouppicker,... 

 

About the JQL functions, we just dropped our plugin as the jql custom function are very bad in performance and with over 100k tickets and also 40k+ users it can literally shutdown jira. So we switched to preparing most use cases by filling custom fields through a plugin that listens to according changes on a ticket and fills them in a worker thread. so we can keep performance about 200 times faster than by using jql.

 

0 votes
Joffrey_Hamman November 28, 2016

I have almost the same problematic. 
My goal was to reindex issues whose the scripted field value has changed, in order to sort them in the issues viewer.
If you run a groovy script inside the scripted field, it ends in a infinite loop.
Then, I run my groovy script in an escalation service which runs every minute.

I share with you my code which works well under Jira 7.1.0, maybe it can help you.

Escalation service :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
import com.atlassian.jira.issue.index.IssueIndexingService
import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.issue.Issue
import com.atlassian.jira.util.ImportUtils
import org.apache.log4j.Category
 
def issueManager = ComponentAccessor.getIssueManager()
def issueIndexingService = ComponentAccessor.getComponent(IssueIndexingService)
 
boolean wasIndexing = ImportUtils.isIndexIssues();
ImportUtils.setIndexIssues(true);
log.warn("Reindex issue ${issue.key} ${issue.id}")
issueIndexingService.reIndex(issueManager.getIssueObject(issue.id));
ImportUtils.setIndexIssues(wasIndexing);


To test under script Console, you have to define "issue" before :

1
Issue issue = issueManager.getIssueObject("your issue Key");
Todd Lindsey July 30, 2018

Thanks Joffrey Hamman, your code  really helped , 

why do we need this 

boolean wasIndexing = ImportUtils.isIndexIssues();ImportUtils.setIndexIssues(true);

 

ImportUtils.setIndexIssues(wasIndexing);

 

 

Cheers

Ramesh

Suggest an answer

Log in or Sign up to answer