Parallel Task

From b9421dc80af485591a9c50cc8921f912e0def11e Mon Sep 17 00:00:00 2001 From: Ashlee Young Date: Fri, 23 Oct 2015 10:05:40 -0700 Subject: Removing sources to replace with download links instead. Change-Id: Ie28789a725051aec0d1b04dd291b7690a7898668 Signed-off-by: Ashlee Young --- .../apache-ant-1.9.6/manual/Tasks/parallel.html | 235 --------------------- 1 file changed, 235 deletions(-) delete mode 100644 framework/src/ant/apache-ant-1.9.6/manual/Tasks/parallel.html (limited to 'framework/src/ant/apache-ant-1.9.6/manual/Tasks/parallel.html') diff --git a/framework/src/ant/apache-ant-1.9.6/manual/Tasks/parallel.html b/framework/src/ant/apache-ant-1.9.6/manual/Tasks/parallel.html deleted file mode 100644 index 362daf37..00000000 --- a/framework/src/ant/apache-ant-1.9.6/manual/Tasks/parallel.html +++ /dev/null @@ -1,235 +0,0 @@ - - - - - - -Parallel Task - - - - -

Parallel

Description

- Executes nested tasks in parallel with no guarantees of thread safety. - Every task will run in its own thread, with the likelihood of - concurrency problems scaling with the number of CPUs on the host system. -

Warning: While the Apache Ant core is believed to be thread safe, no such - guarantees are made about tasks, which are not tested for thread safety during - Ant's test process. - Third party tasks may or may not be thread safe, and some of Ant's core tasks, such as - <javac> are definitely not re-entrant. This is because they use libraries that - were never designed to be used in a multithreaded environment. -

- The primary use case for <parallel> is to run external programs - such as an application server, and the JUnit or TestNG test suites at the - same time. Anyone trying to run large Ant task sequences in parallel, such - as javadoc and javac at the same time, is implicitly taking on the task - of identifying and fixing all concurrency bugs the tasks that they run. - -

- Accordingly, while this task has uses, it should be considered an advanced - task which should be used in certain batch-processing or testing situations, - rather than an easy trick to speed up build times on a multiway CPU. -

- -

Parameters

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Attribute	Description	Required
threadCount	Maximum numbers of thread to use.	No
threadsPerProcessor	Maximum number of threads to use per available processor -(Java 1.4+)	No, defers to threadCount
timeout	Number of milliseconds before execution is terminated	No
failonany	If any of the nested tasks fails, execution of the task completes - at that point without waiting for any other tasks to complete.	No, default is false.
pollInterval	Currently has no effect	No, default is 1000

- -

Parallel tasks have a number of uses in an Ant build file including:

Taking advantage of available processing resources to execute external - programs simultaneously.
Testing servers, where the server can be run in one thread and the test -harness is run in another thread.

- -

Any valid Ant task may be embedded within a -parallel task, including other parallel tasks, though there is no guarantee that -the tasks will be thread safe in such an environment.

- -

While the tasks within the parallel task are being run, the main -thread will be blocked waiting for all the child threads to complete. If -execution is terminated by a timeout or a nested task failure when the -failonany -flag is set, the parallel task will complete without waiting for other nested -tasks to complete in other threads. -

- -

If any of the tasks within the <parallel> task fails and failonany is -not set, the remaining tasks in other threads will continue to run until -all threads have completed. In this situation, the parallel task will also fail.

- -

The parallel task may be combined with the -sequential task to define sequences of tasks to be executed on each thread -within the parallel block

- -

The threadCount attribute can be used to place a maximum number of available -threads for the execution. When not present all child tasks will be executed at -once. When present then the maximum number of concurrently executing tasks will -not exceed the number of threads specified. Furthermore, each task will be -started in the order they are given. But no guarantee is made as to the speed -of execution or the order of completion of the tasks, only that each will be -started before the next.

- -

If you are using Java 1.4 or later you can also use the threadsPerProcessor -and the number of available threads will be the stated multiple of the number of -processors (there is no affinity to a particular processor however). This will -override the value in threadCount. If threadsPerProcessor -is specified on any older JVM, then the value in threadCount will be used as is.

- -

When using threadCount and threadsPerProcessor - care should be taken to ensure that the build does not deadlock. - This can be caused by tasks such as waitfor - taking up all available threads before the tasks that would unlock the - waitfor -would occur. This is not a replacement for Java Language level thread -semantics and is best used for "embarassingly parallel" tasks.

- - -

Parameters specified as nested elements

- -

daemons

-The parallel task supports a <daemons> nested element. This is a list of tasks -which are to be run in parallel daemon threads. The parallel task will not wait for -these tasks to complete. Being daemon threads, however, they will not prevent Ant from -completing, whereupon the threads are terminated. Failures in daemon threads which -occur before the parallel task itself finishes will be reported and can cause -parallel to throw an exception. Failures which occur after parallel has completed are not -reported. -

- -

Daemon tasks can be used, for example, to start test servers which might not be easily -terminated from Ant. By using <daemons> such servers do not halt the build. -

- - -

Examples

-<parallel>
-  <wlrun ... >
-  <sequential>
-    <sleep seconds="30"/>
-    <junit fork="true" forkmode="once" ... >
-    <wlstop/>
-  </sequential>
-</parallel>
-

This example represents a typical pattern for testing a server application. -In one thread the server is started (the <wlrun> task). -The other thread consists -of a three tasks which are performed in sequence. The <sleep> task is used to -give the server time to come up. Another task which is capable of validating -that the server is available could be used in place of the <sleep> task. The -<junit> test harness then runs, again in its own JVM. Once the tests are complete, the server is stopped -(using <wlstop> in this example), allowing both threads to complete. The -<parallel> task will also complete at this time and the build will then -continue.

- -

-<parallel>
-  <javac fork="true"...> <!-- compiler servlet code -->
-  <wljspc ...> <!-- precompile JSPs -->
-</parallel>
-

- -

This example shows two independent tasks being run to achieve better -resource utilization during the build. In this instance, some servlets are being -compiled in one thead and a set of JSPs is being precompiled in another. Developers -need to be careful that the two tasks are independent, both in -terms of their dependencies and in terms of their potential interactions in -Ant's external environment. Here we set fork="true" for the -<javac> task, so that it runs in a new process; -if the <wljspc> task used the javac compiler in-VM -(it may), concurrency problems may arise. -

- -

- <macrodef name="dbpurge">
-    <attribute file="file"/>
-   <sequential>
-      <java jar="utils/dbpurge.jar" fork="true" >
-        <arg file="@{file} />
-      </java>
-   </sequential>
-</macrodef>
-    
-<parallel threadCount="4">
-  <dbpurge file="db/one" />
-  <dbpurge file="db/two" />
-  <dbpurge file="db/three" />
-  <dbpurge file="db/four" />
-  <dbpurge file="db/five" />
-  <dbpurge file="db/six" />
-  <dbpurge file="db/seven" />
-  <dbpurge file="db/eight" />
-  <!-- repeated about 40 times -->
-</parallel>
-

- -

This example represents a typical need for use of the threadCount and -threadsPerProcessor attributes. Spinning up all 40 of those tasks could cripple -the system for memory and CPU time. By limiting the number of -concurrent executions you can reduce contention for CPU, memory and disk IO, -and so actually finish faster. This is also a good -candidate for use of threadCount (and possibly threadsPerProcessor) because -each task is independent (every new JVM is forked) and has no dependencies on -the other tasks.

- - - - - -- cgit 1.2.3-korg