Closed vinjana closed 6 years ago
Apparently, this could relatively easily be quick-fixed by making some variables static
and synchronized
maps on dataset, to persist their content over the QUERY_STATUS and actual run phases. Whether that is a good solution, I do not know. The code above still needs refactoring, as there is simply too many factors deciding, whether to run or not etc. There should be some "deciderX" code.
Done
When running the BamToFastqPlugin in testrerun and rerun mode, the read-groups are culled a second time from the BAMs. Whatever the reasons for that (probably new workflow object), in the second round the workflow crashes with
(Note this is a development version from the development branch with callDirect() renamed to runDirect(). Current commit f343e5e)
I could trace further into
de.dkfz.roddy.execution.io.ExecutionService#execute(de.dkfz.roddy.execution.jobs.Command, boolean)
. However it is not clear to me what the semantics of the variablesconfigurationDisallowsJobSubmission
,allJobsBlocked
,pidIsBlocked
,preventCalls
,isDummyCommand
is and why particularly for testrerun again a special branch is followed.TODO: Clean up the semantics of all these variables and fix the problem with runDirect() in testrerun mode.