addon-com.awnaba.projectconfigurator.projectco#We are getting error while exporting project config(com.atlassian.jira.task.AlreadyExecutingException: A task with this context has already been submitted). Can restarting the Jira Service resolve this error?

[Utkarsh Agarwal]

Hi Team,

We are facing an issue with the Project configurator Add-on. One of the user started the complete export of project. And since then we are receiving a 500 error :

Cause

com.atlassian.jira.task.AlreadyExecutingException: A task with this context has already been submitted

com.atlassian.jira.task.AlreadyExecutingException: A task with this context has already been submitted

     at com.atlassian.jira.task.TaskManagerImpl.submitTask(TaskManagerImpl.java:170)

     at com.atlassian.jira.task.TaskManagerImpl.submitTask(TaskManagerImpl.java:113)

     at sun.reflect.GeneratedMethodAccessor2769.invoke(Unknown Source)

     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

     at java.lang.reflect.Method.invoke(Method.java:497)

We have waited for the process to complete but it has been 4 days since but we are getting the same error. We also tried re-enabling the add-on but no luck.

Please let us know that if we restart our Jira service this will kill the Process?

Or if you can provide a better approach for the same it will be highly appreciated.

Regards

Utkarsh

[José Marañón [Awnaba Software S.L.] · Accepted solution]

Hi Utkarsh,

Yes. Restarting JIRA should kill the process. The plugin is designed so that it will not start an export/import process if another one is already running.

Just to get some additional information, could you specify these items?

• Version of JIRA
• Version of the plugin
• Number of issues in the exported projects
• Number of projects, custom fields and workflows in the instance

Thanks in advance!

José

[Utkarsh Agarwal]

• Version of JIRA = 6.4.13
• Version of the plugin = 2.1.0-J6
• Number of issues in the exported projects = 116
• Number of projects, custom fields and workflows in the instance = around 900 projects, greater than 1000 custom fields and more than 2200 workflows

[Utkarsh Agarwal]

Thanks

Need to ask before we restart our server, will there be any issues during the server restart because of this issue?

If Yes, then how should we resolved this?

Also, is there any work around to kill this process without actually restarting our server, as we cannot do this every time there is an issue with the add-on.

Regards

Utkarsh

[José Marañón [Awnaba Software S.L.]]

Hi Utkarsh,

The number of custom fields and workflows is certainly large, but it does not justify that an export would take some days to complete. On the other hand the number of issues is quite low. My opinion is that this export process is not taking too long, but either it has failed or it has finished and somehow the process has not been properly finished and cleared.  

Suggestion (unrelated to this issue): export always selecting to include custom fields "only those used by exported projects". With so many custom fields, this will ensure your exports contain only those custom fields strictly needed for the project and avoid carrying many of them to the target instance.

will there be any issues during the server restart because of this issue?

I do not think so. To start with, export is a read only process, that does not persist any information. Anyway, for greater peace of mind, you can look at the JIRA log file and analyze there traces left by the export process. This is likely to throw some light on what happened with the process. Please feel free to request our assistance with that analysis, in that case send the relevant log section to our "support" email account. You can also have a look at the "projectconfigurator" folder under {JIRA_HOME}/export and check if the exported file is there (try to identify it by the date and exported project key or whatever name the user chose for it). If it is, that means the export in fact had finished.

is there any work around to kill this process without actually restarting our server?

EDITED: The only workaround I could think of, is similar in complexity to restarting JIRA. I think it would be a better solution to integrate into the plugin some way to stop the process, as you suggest in the next comment.

Best regards

José

[Utkarsh Agarwal]

Successfully restarted the JIRA server and Project Configurator is also working just fine.

For these issues there should be a way to know where the export/import process is stuck, and also when we disable the plugin from the JIRA UI it should kill the process. Also if there is a way to find out what all activities have been performed using Project Configurator, some kind of audit log just for project configurator can help a lot while debugging. Just a suggestion.

Thanks a lot for your support.

Regards

Utkarsh

[José Marañón [Awnaba Software S.L.]]

Glad you solved it!

Thanks sincerely for the suggestions. User feedback is the main source for new features and improvements to the plugin, so they are always helpful.

Please note that, as mentioned in my previous comment, in this case where the user did not get the results page, the JIRA log file could provide some of that information about the plugin actions. However, I understand that finding the traces left in the log file by a process that was launched 5 days ago might not be easy.

[Miranda Pearson]

I would also +1 the following: 

For these issues there should be a way to know where the export/import process is stuck, and also when we disable the plugin from the JIRA UI it should kill the process. Also if there is a way to find out what all activities have been performed using Project Configurator, some kind of audit log just for project configurator can help a lot while debugging. Just a suggestion.

This would be extremely valuable.