App-Oozie

 view release on metacpan or  search on metacpan

eg/workflows/cpan-sample-workflow/coordinator.xml  view on Meta::CPAN

        is one blocking the queue.

        You can also change the concurrency of your workflows here, although
        that should be done only in very specific cases (meaning that you know
        precisely what you are doing and why). Blindly scheduling parallel
        jobs can lead to taking down or slowing down some systems it might be
        consuming (i.e.: heavy writes on a mysql master or a job recreating
        a table in every run).
    -->

    <!-- Timeout after 23 hours -->
    <!--
        <controls>
            <timeout>1380</timeout>
            <concurrency>1</concurrency>
            <execution>FIFO</execution>
        </controls>
    -->

    <!--
        Optional. Specify the relevant datasets (input and output)

eg/workflows/cpan-sample-workflow/workflow.xml  view on Meta::CPAN

                this is the case please contact Team BigData.
                -->

            <arg>import</arg>

            <!--
                Notice that the configuration is acceseed by the
                action name: "sqoop_example"
            -->
            <arg>--connect</arg>
            <arg>jdbc:mysql://${wf:actionData('sqoop_example')['db_host']}/${wf:actionData('sqoop_example')['db_schema']?connectTimeout=300000&amp;socketTimeout=7200000</arg>

            <arg>--username</arg>
            <arg>${wf:actionData('sqoop_example')['db_user']}</arg>

            <arg>--password-file</arg>
            <arg>${wf:actionData('sqoop_example')['db_password_file']}</arg>

            <arg>--num-mappers</arg>
            <arg>64</arg>

 view all matches for this distribution
 view release on metacpan -  search on metacpan

( run in 1.012 second using v1.00-cache-2.02-grep-82fe00e-cpan-2c419f77a38b )