mirror of
https://github.com/galaxyproject/galaxy.git
synced 2026-08-31 01:02:04 +08:00
399d29cec6
- Creating the command line has been broken up into several methods associated with 'Tool' - Creation of the command line is now done by DefaultToolAction and stored in the database (thus if the tool config changes between queueing and running of a job things will not break, and if the JobQueue was running on a different machine from the web frontend it would not need knowledge of the tool config) - Broke the old JobQueue up quite a bit. New classes are: jobs.JobQueue: jobs to be run still get added here. It has a single monitor thread that iterates the jobs waiting for one to become runnable, then it tries to dispatch the job jobs.DefaultJobDispatcher: responsible for deciding how to run a job once it is ready to run. Just a trivial implementation for now, as before is PBS is enabled and the tool is not a 'data_source' tool, try to run it using PBS, otherwise run locally jobs.runners.local.LocalJobRunner: the old pool of worker threads that runs jobs processes locally jobs.runners.local.PBSJobRunner: PBS job runner. Only uses a single thread to watch all queued/running jobs. This is TOTALLY UNTESTED. I haven't even imported it. I just tried to break up Nate's code to make a state machine that could be managed with one thread. Need to know more about the PBS setup to test. Next steps: - Clean up locally running jobs when the queue is shut down (kill the jobs and mark the state change appropriately) - For all jobs it should be possible to requeue and jobs in the 'waiting' state on startup - For the PBS queue, it should be possible to recover the state of any jobs that were queued or running on startup. However we might need more data in the database for this