nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Some issues take ages to index

motherg

Hi all,

I've got an issue where some issues take over an hour to be indexed. You can view them immediately by using the URL but if you do a search they do not appear (this obviously affects our greenhopper boards too due to them being based on filters).

The main problem is that it's utterly sparadic, doesn't affect a specific user or issue type - it seems to be completely random.

Executing a background index does not solve the problem but a full (locked out) index does. If you leave it a couple of hours they will naturually appear - other users can raise issues in this time period and they will be indexed with no problem.

Our WebSys team have looked at the logs and have give me this entry - none of us know what it means so I'm hoping someone can help out?

catalina.out:2013-07-03 17:56:35,041 localhost-startStop-1 WARN [manager.issue.fields.ManagedFieldConfigurationRestorerImpl] Field 'Epic Status': Option on index '0' was 'New' but we expected to be 'To Do'

It appears to be related to the statuses of epics but I can't see how that's having an affect?

Accepted answers

motherg

It may be related - it depends if anything else can cause the error I guess.

But ignoring all that, the thing that initially caused my problem of issues not being indexed quickly was down to a custom event I put in the workflow.

Rather than having a generic Issue Creation event I put in a custom one (called Bug Created). This was so that I could tune to the notification scheme to notify us of bug creation but not story creation (stories have a seperate workflow which have different event hooks to allow for better notifications).

Anyway, I didn't know that creating a custom even on the Issue Creation transition stripped out the re-index command, so I had to put them in manually.

All of this makes me think the issue you are seeing maybe unlreated to mine.

All comments

motherg

Anyone?

motherg

Having spoken with Atlassian, it appears this is a problem caused by the Suite Utilities plugin so I've added the appropriate tage and contacted them. I want to keep this open here so if a solution is found it can be communicated to other users of Atlassian Answers

Joana Sancho

I've got the same WARN log:

2013-11-28 22:06:23,678 localhost-startStop-1 WARN [manager.issue.fields.ManagedFieldConfigurationRestorerImpl] Field 'Estado de épica': Option on index '0' was 'Por hacer' but we expected to be 'To Do'

But, we would like to have all field names in english, but they appear in spanish.

motherg

Are you having the same issue as well, issues taking ages to index? Because I know what the issue is and how to fix it :-)

Joana Sancho

I really don't know if our issues are taking ages to index. We have about 40000 issues, so the time it takes isn't excessively high, but maybe the relation (number of issues)/(indexing time) isn't good enough. I really don't know.

How do you fix it? Maybe our problem can be solved in a similar way. Is it related with Jira Agile?

We are experiencing some random CPU spikes that block our Jira instance.

motherg

It may be related - it depends if anything else can cause the error I guess.

But ignoring all that, the thing that initially caused my problem of issues not being indexed quickly was down to a custom event I put in the workflow.

Anyway, I didn't know that creating a custom even on the Issue Creation transition stripped out the re-index command, so I had to put them in manually.

All of this makes me think the issue you are seeing maybe unlreated to mine.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

issue

jira

addon-com.googlecode.jira-suite-utilities

index