mirror of
https://github.com/galaxyproject/galaxy.git
synced 2026-10-29 17:42:12 +08:00
43 lines
1.8 KiB
XML
43 lines
1.8 KiB
XML
<?xml version="1.0"?>
|
|
<!-- If workflow_schedulers_conf.xml exists it defines the workflow scheduling
|
|
plugins to load and how to configure them. Currently only the core workflow
|
|
scheduling is available.
|
|
-->
|
|
<workflow_schedulers default="core">
|
|
<!-- Each element in this file corresponds to a workflow scheduling plugin
|
|
in lib/galaxy/workflow/schedulers. -->
|
|
|
|
<!-- Core plugin schedules whole workflow at outset inside Galaxy and doesn't
|
|
require any external dependencies. -->
|
|
<core id="core" />
|
|
|
|
<!-- Handlers (Galaxy server processes that perform the scheduling work) can
|
|
be defined here in the same format as in job_conf.xml. By default, the
|
|
handlers defined in job_conf.xml will be used (or the web process that
|
|
receives the workflow scheduling request if handlers are not configured
|
|
in job_conf.xml).
|
|
|
|
The options here are the same as is documented for <handlers> in
|
|
job_conf.xml.sample_advanced with two exceptions:
|
|
|
|
- If a uWSGI farm named `workflow-schedulers` is present, it will be
|
|
preferred, followed by `job-handlers`. If any untagged handlers are
|
|
defined in this configuration they are eligible to schedule workflows
|
|
in addition to any matching mules.
|
|
- If uWSGI farms are present, the default assignment method is
|
|
`db-preassign` rather than `uwsgi-mule-message`, because `db-preassign`
|
|
is deterministic. All workflows scheduled in a single history will be
|
|
assigned to the same handler, ensuring they are scheduled serially
|
|
(preventing their outputs from being interleaved in the history). You
|
|
can override this by explicitly setting
|
|
`assign_with="uwsgi-mule-message"`.
|
|
-->
|
|
<!--
|
|
<handlers>
|
|
<handler id="handler0"/>
|
|
<handler id="handler1"/>
|
|
</handlers>
|
|
-->
|
|
|
|
</workflow_schedulers>
|