-
Suggestion
-
Resolution: Answered
-
None
-
9
-
We collect Jira feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.
NOTE: This suggestion is for JIRA Server. Using JIRA Cloud? See the corresponding suggestion.
It would be helpful if one of JIRA's bulit-in services was a re-indexer, so re-indexing could take place regularly (e.g. every night or every week). Often, when a problem is determined to be based on a re-indexing required, it isn't a convenient time to do so.
- is duplicated by
-
JRASERVER-12176 automatic re-index
- Closed
- is related to
-
JRASERVER-7842 Reindex in background to avoid locking users out
- Closed
-
JRASERVER-16347 Full reindex without locking Jira - reindex all issues one-by-one?
- Closed
- relates to
-
JRACLOUD-10874 Add Re-index as a built-in service
- Closed
[JRASERVER-10874] Add Re-index as a built-in service
Hi All,
Thanks for the comments and votes. We've taken a good look at this and it's not something we will fix in the near future. Since this request was opened we've introduced background indexing which might alleviate the needs of a built-in service.
Cheers,
Roy
I would also like to see this feature implemented in the newer versions with the ability to specify a Background Re-Index. This is especially helpful for those of us that would like to incorporate some scripted fields from the Script Runner plugin. These fields only get indexed during transitions or other field updates, so i can't use those fields very reliably if they rely on information that may change on separate objects such as versions, linked issues, etc. However, if i can schedule a nightly Background Re-Index, then those fields will once again be useful for JQL searches as well as gadgets.
Thank you Devon Prenovost and Ville Myrskyneva, for your comments posted 27/Jan/11 10:31 AM and 24/Jan/12 4:55 AM (respectively).
Your scripts work great on JIRA v5.1.6 and have solved my need to perform an unattended Re-Index late at night when no one is using the system. Awesome!
Hi
Does someone tried these scripts on Jira 5 with Background indexing features?
Regards,
Areg
Hi,
Can this (Sorry! Meant Dave Hafken's script mentioned above) be used for sending Jelly Script notifications only at the specified time?
Thanks,
Rajani
Hi there,
Any one got idea how to make this run at jira version 5.1? I tested the script posted by Ville Myrskyneva , but it cant trigger the reindex.
Any Idea? Thanks
The script might be great but what if you're on Windows as we are? I think this urgently needs a built-in solution as you cannot re-index druing working hours. And there ARE problems if you ignore re-indexing.
Hi,
About Dave's code above, how would i change <core:set var="hourOfDay" value = "2"/> to make it run every two hours, from 8am to 6pm?
thanks
I needed to add one more 'curl' call for the websudo page in order to make the script work (Using Jira 4.4.1).
Here's what I have:
#!/bin/sh ### SETTINGS ### USERNAME=admin PASSWORD=password DASHBOARD_PAGE_URL=http://127.0.0.1:8080/jira/secure/Dashboard.jspa WEBSUDO_PAGE_URL=http://127.0.0.1:8080/jira/secure/admin/WebSudoAuthenticate.jspa?webSudoPassword=$PASSWORD INDEX_PAGE_URL=http://127.0.0.1:8080/jira/secure/admin/jira/IndexReIndex.jspa COOKIE_FILE_LOCATION=jiracookie.txt ### COMMANDS ### curl -u $USERNAME:$PASSWORD --cookie-jar $COOKIE_FILE_LOCATION --output /dev/null $DASHBOARD_PAGE_URL curl --cookie $COOKIE_FILE_LOCATION --output /dev/null $WEBSUDO_PAGE_URL curl -u $USERNAME:$PASSWORD --cookie $COOKIE_FILE_LOCATION --header "X-Atlassian-Token: no-check" -d "indexPathOption=DEFAULT" -d "Re-Index=Re-Index" -d "indexPath=" --output /dev/null $INDEX_PAGE_URL rm $COOKIE_FILE_LOCATION
I also had to add this to my $JIRAHOME/jira-config.properties so the curl wouldn't break
jira.websudo.is.disabled = true
I would to put in place an automatic re-indexing on my JIRA instances.
I have got 2 instance of 700 000 issues (version 4.3.4 & 3.13.2). It take one hours to re-index all issues.
I try to script with CURL command but it is not working for now
URL :
secure/admin/jira/IndexAdmin.jspa?Re-Index=Re-Index
Could you please help me on that ?
Regards,
Sven.
We're having 3.13.0 here, with around 550k issues.
No problem really, but we do need to re-index regularly, othwerwise the backups become unusable because indexes are corrupt and db is not correct anymore.
Seems like atlassian doesn't take performance and heavy users that serious.
Please atlassian, take a good look at you database usage, and optimize it so we can really get a good performance and good indexing, because file-indexes when you have a sql databaase does not make any sense at all.
Any progress on this? Our internal team regularly adds/changes custom fields for projects, and thus we are having to reindex by hand everyday. If we don't, people don't see tickets in their queues that are assigned to them. I'd like to automate this.
Unfortunately, while the jelly script seemed to work, I got complaints after about 4 days that tickets weren't showing up in peoples queues but they were there, etc.. and it turns out the index cache was out of sync.. So I had to disable the script.
Hello,
I'm very interested in this feature.
I picked up the jelly script and fortunatly for me, our Jira server is restarting every morning when nobody is at the company.
So the Jelly script runs at the same time without the problem of locks of issue.
But unfortunatly the big blue message in adminstration page does not disapear .
In case anyone still needs it, I found a fantastic JIRA indexing script here:
http://justinit.wordpress.com/2011/01/19/jira-auto-reindex/
I have tested it on JIRA 4.1.1 and it works perfectly.
In case the page disappears:
#!/bin/sh ### SETTINGS ### USERNAME=<admin_username> PASSWORD=<password> DASHBOARD_PAGE_URL=http://<JIRA_URL>/secure/Dashboard.jspa INDEX_PAGE_URL=http://<JIRA_URL>/secure/admin/jira/IndexReIndex.jspa COOKIE_FILE_LOCATION=jiracoookie ### COMMANDS ### curl -u $USERNAME:$PASSWORD --cookie-jar $COOKIE_FILE_LOCATION --output /dev/null $DASHBOARD_PAGE_URL curl --cookie $COOKIE_FILE_LOCATION --header "X-Atlassian-Token: no-check" -d "indexPathOption=DEFAULT" -d "Re-Index=Re-Index" -d "indexPath=" --output /dev/null $INDEX_PAGE_URL rm $COOKIE_FILE_LOCATION
Hello Atlassian,
Dave's script does a good job reindexing JIRA at a specified time. Unfortunately it does NOT lock JIRA, so users can still lock in to JIRA during the reindex is running and change issues - and this issues are not in sync with the index after this.
So, can you provide the code to lock JIRA while the reindex is running?
Regards
Wolfgang
Wolfgang,
I'm pretty sure the code you are using will lock JIRA for you, just as a normal reindex locks JIRA.
Here's a jelly script that I'm using to reindex all issues daily at 2am, which looks the same as yours regarding what is being called:
<JiraJelly xmlns:jira="jelly:com.atlassian.jira.jelly.enterprise.JiraTagLib" xmlns:core="jelly:core" xmlns:log="jelly:log"> <core:set var="myName" value="Daily Reindex"/> <!-- The time to run this script --> <!-- NOTE: This script should only be called once an hour --> <core:set var="hourOfDay" value="02"/> <!-- The current time --> <core:invokeStatic className="java.util.Calendar" method="getInstance" var="rightNow"/> <core:getStatic className="java.util.Calendar" field="HOUR_OF_DAY" var="HOUR"/> <!-- Time Check --> <core:if test="${hourOfDay == rightNow.get(HOUR)}"> <!-- ******** --> <!-- Managers --> <!-- ******** --> <!-- The ComponentManager will be used to access all other managers. com.atlassian.jira.ComponentManager --> <core:invokeStatic className="com.atlassian.jira.ComponentManager" method="getInstance" var="componentManager"/> <!-- The IndexManager is required to reindex issues --> <core:invoke on="${componentManager}" method="getIndexManager" var="indexManager"/> <!-- ************* --> <!-- Reindex Issues --> <!-- ************* --> <log:warn trim="true"> ${myName}: Reindexing ALL issues. </log:warn> <core:invoke on="${indexManager}" method="reIndexAll" var="millis"/> <log:warn trim="true"> ${myName}: Reindex time in ms: ${millis} </log:warn> </core:if> </JiraJelly>
I have a service call the above script once an hour; the script checks the current time and will only run during the 2am hour.
Clunky, I know, but it seems to work.
Hello Atlassian,
are you still alive?
Is there any workaround available at least for the people who do not run JIRA in different timezones?
I tried to run the reindex as service using the Script Runner and a Groovy-script
import com.atlassian.jira.ComponentManager ComponentManager.getInstance().getIndexManager().reIndexAll(); return;
but it's useless without locking JIRA. How can JIRA be locked during the reindex?
Regards,
Wolfgang
Atlassian, any updates on this issue? We would like to be able to schedule re-indexing for any situation that would require it. We have offices in 3 different time zones and finding the right time to run a re-index is very hard. It would be very helpful if we could schedule it so no one would need to do it manually. This is the case for even the latest Jira version 4.2.1.
So in JIRA 4.1.2, when our users update a custom field, we are told via a friendly Blue Screen that we need to reindex at some point. Great - Friday midnight would be perfect. So lets set that up as a regular task in JIRA...
Erm... looks like we can't ! So my vote is on this issue, otherwise we'll have to leave a post-it in our New York office saying "if your the last one out, please turn out the lights, oh and kick off a JIRA re-index too please", which feels less than awesome.
Nick,
Changing a custom field searcher requires a re-index. Adding a new calculated custom field requires a re-index Due to desires for more and more precise reports we find ourselves adding new calculated custom fields and installing more tuned custom field searchers quite often (like a couple times a month). With 130,000 issues, it takes about a half an hour to re-index our Jira...a half hour that our Jira is offline...which is unfortunate as we have users online 24 hours a day.
Chris,
If you ran reindexAll() in the middle of the day it might run and let people log in but Jira's going to look like it's hung every time someone tries to edit an issue because there's a lock on the index, right?
I tried to run something like this forum discussion in the middle of the night. About 2/3's of the issues edited by users during that time were corrupted in the index. It may have worked flawlessly if I had realized to put a Thread.yield() in there, but, I'm not going to run that experiment ever again.
All of the corruptions occurred silently – I saw zero exceptions or errors in the logs.
Hi Tim,
Yes if you implement your own JiraService, you can call IndexManager.reIndexAll(). Your run() method would look something like this:
public void run() { try { ComponentManager.getInstance().getIndexManager().reIndexAll(); } catch (IndexException e) { log.error(e); } }
Can this somehow be done by calling reIndexAll() as a service from http://www.atlassian.com/software/jira/docs/api/3.4.3/com/atlassian/jira/issue/index/IssueIndexManager.html ?
This may be a "band-aid" but I'm seeing issues since upgrading to 3.7 and still in 3.7.4 where I have to re-index manually to get the navigator to align with the issues (i.e. issue is in status b but the navigator still lists it as status a and its showing up in the wrong portlets). It'd be a nice stop gap to have a service run at a specified time until I can find the time to figure out why this is happening.
Well, there is still an outstanding issue in the Toolkit. If I change a user's e-mail address, it does not set the domain of reporter correctly for all issues they have reported. That would require a re-index. So, it would be helpful if I could do that overnight.
See this issue
This really shouldn't be needed, especially after 3.7.3+.
We have gone to great lengths to rewrite the code for reindexing and it should be dramatically more stable.
And this is just a band-aid solution that doesn't address the real underlying problem - what caused the index to become corrupt in the first place.
Would it be easier to implement JRA-61325?
I guess that would be enough for most of us, JIRA admins.