|
|
|
[
Permlink
| « Hide
]
Neal Applebaum - 02/Mar/07 07:51 AM
Just FYI, I was using JIRA under Weblogic 8.1 and also found that changing a project's workflow took hours to complete. Logs showed broken pipes etc. Then we switched to Tomcat 5.5 and changing workflow took seconds. I mean it was so fast I thought it must have errored out! A project with over 100 issues took about no more than a couple of minutes instead of 4 hours. So there must be more at play here than just JIRA's admin stuff.
Correction - the project had about 1,200 issues!
We use tomcat 5.5.9 and it seems the main problem is that for every issue there are a few records that need changing (everything in the history with workflows + state of the issue). So every issue has at least 3 records to change (open, resolve and close). If there are other things that could mess up the workflow thn the workflow activation should take care of it.
It should stop the backup while it's running. It should do an integrety check before running, it should give you information on what it is doing and how long it is going to take even if it's in the log (now nothing or nothing usefull Is this the second time you ran the workflow activation or is it a backup that was put on the tomcat. If it's the second time then only the issues that were not converted the first time are changed. I think that it will take the same amount if you do a new change but not sure
In my experience, changing the app server had a dramatic improvement (on the same set of backup/test data). Anyway, Atlassian is tracking sevearl issues relating to workflow changes (e.g. progress indicator etc.)
So, I have the same problem.
The workaround I have found is unactivating the indexing functionnality Jira claim a bit but run (exept for the "Find functionality of course) You aplly your workflow then you launch the re-indexation. The time lost with the indexation will be compensated by the gain of the faster applying Of course, Jira is off for the users during this time. In that case it's something the workflow change should automatically do. I don't now how it works but it also could do a lock tables ... write and unlock tables after the process (I found that that speeds up everything with a factor 10 when doing massive changes to the database)
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||