History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: JRA-12303
Type: Improvement Improvement
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Kristof Van Cleemput
Votes: 2
Watchers: 3
Operations

If you were logged in you would be able to see more operations.
JIRA

Workflow needs workover

Created: 02/Mar/07 05:02 AM   Updated: 28/Mar/07 01:33 AM
Component/s: Workflow
Affects Version/s: 3.7.3 Professional
Fix Version/s: None

Time Tracking:
Not Specified

Environment: windows xp using firefox
Issue Links:
Reference
 

Participants: Bertrand Ducret, Kristof Van Cleemput and Neal Applebaum
Since last comment: 59 weeks, 3 days ago
Labels:


 Description  « Hide
Changing a workflow takes too long (16h) and other processes can interfer (automatic backup).
Because of the interferance the new workflow wasn't activated and most of the issues were converted to the new workflow (nobody could change these issues to resolved, closed, ...) I'm told that you need to redo the workflow change until all issues are converted (but if this takes 16 h everytime then it's not worth the trouble). So for everybodies sake I had to restore a backup to get everything going again.

It seems the workflow activation needs a workover to improve its speed and to ensure that nothing can interfere while it's running.
It seems there's a missing indirection because every issue has to be changed when the workflow changes.
The workflow only consists of a little amount of steps. If you put something between the issue and the workflow then you should be able to change it in a few seconds and see problems when there are missing steps that can't convert. Normally you add stuff to a workflow so there shouldn't be a need to change the issue because all the steps that where in the previous workflow are also in the new workflow

Also there is nothing in the log or on the screen that gives you an indication what's going on or wrong or if it succeeded, ...

Documentation for the prof. edition only states how to activate a workflow (It wasn't hard to adjust but is this really all, no warnings that it takes allmost a day, that other processes will interfer)



 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
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.

Neal Applebaum - 02/Mar/07 07:51 AM
Correction - the project had about 1,200 issues!

Kristof Van Cleemput - 05/Mar/07 01:15 AM
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 ), what else?


Kristof Van Cleemput - 05/Mar/07 01:22 AM
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

Neal Applebaum - 05/Mar/07 08:11 AM - edited
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.)

Bertrand Ducret - 27/Mar/07 02:12 PM
So, I have the same problem.

The workaround I have found is unactivating the indexing functionnality
stoping Jira
delete index file
restarting Jira

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.


Kristof Van Cleemput - 28/Mar/07 01:33 AM
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)