33
33
*
34
34
* include::myJob.xml[]
35
35
*
36
- * A very simple job is defined in the +myJob.xml+ file. Just a single step with a reader, processor and writer. For
36
+ * A very simple job is defined in the +myJob.xml+ file. Just a single step with a reader, a processor and writer. For
37
37
* this sample, a custom checkpoint policy is going to be used. The custom policy needs to implement
38
38
* +javax.batch.api.chunk.CheckpointAlgorithm+ or in alternative extend
39
39
* +javax.batch.api.chunk.AbstractCheckpointAlgorithm+ that already provides empty implementations for all methods.
47
47
*/
48
48
@ RunWith (Arquillian .class )
49
49
public class BatchChunkCheckpointTest {
50
- /**
51
- * We're just going to deploy the application as a +web archive+. Note the inclusion of the following files:
52
- *
53
- * [source,file]
54
- * ----
55
- * /META-INF/batch-jobs/myjob.xml
56
- * ----
57
- *
58
- * The +myjob.xml+ file is needed for running the batch definition.
59
- */
50
+ /**
51
+ * We're just going to deploy the application as a +web archive+. Note the inclusion of the following files:
52
+ *
53
+ * [source,file]
54
+ * ----
55
+ * /META-INF/batch-jobs/myjob.xml
56
+ * ----
57
+ *
58
+ * The +myjob.xml+ file is needed for running the batch definition.
59
+ */
60
60
@ Deployment
61
61
public static WebArchive createDeployment () {
62
62
WebArchive war = ShrinkWrap .create (WebArchive .class )
@@ -68,15 +68,15 @@ public static WebArchive createDeployment() {
68
68
return war ;
69
69
}
70
70
71
- /**
72
- * In the test, we're just going to invoke the batch execution and wait for completion. To validate the test
73
- * expected behaviour we need to query the +Metric[]+ object available in the step execution.
74
- *
75
- * The batch process itself will read and process 10 elements from numbers 1 to 10, but only write the odd
76
- * elements. Commits are executed after 5 elements are read by the custom checkpoint algorithm.
77
- *
78
- * @throws Exception an exception if the batch could not complete successfully.
79
- */
71
+ /**
72
+ * In the test, we're just going to invoke the batch execution and wait for completion. To validate the test
73
+ * expected behaviour we need to query the +Metric[]+ object available in the step execution.
74
+ *
75
+ * The batch process itself will read and process 10 elements from numbers 1 to 10, but only write the odd
76
+ * elements. Commits are executed after 5 elements are read by the custom checkpoint algorithm.
77
+ *
78
+ * @throws Exception an exception if the batch could not complete successfully.
79
+ */
80
80
@ Test
81
81
public void testBatchChunkCheckpoint () throws Exception {
82
82
JobOperator jobOperator = BatchRuntime .getJobOperator ();
@@ -92,15 +92,16 @@ public void testBatchChunkCheckpoint() throws Exception {
92
92
93
93
// <1> The read count should be 10 elements. Check +MyItemReader+.
94
94
assertEquals (10L , metricsMap .get (Metric .MetricType .READ_COUNT ).longValue ());
95
- // <2> The write count should be 5. The 10 elements are read and the checkpoint is on every 5th read .
95
+ // <2> The write count should be 5. Only half of the elements read are processed to be written .
96
96
assertEquals (10L / 2L , metricsMap .get (Metric .MetricType .WRITE_COUNT ).longValue ());
97
- // <3> The commit count is equals to the write count plus 1. An empty read is executed after all reads .
97
+ // <3> The commit count should be 3. Checkpoint is on every 5th read, plus one final read-commit .
98
98
assertEquals (10L / 5L + 1 , metricsMap .get (Metric .MetricType .COMMIT_COUNT ).longValue ());
99
99
}
100
100
}
101
101
102
102
// <4> The checkpoint algorithm should be checked 10 times. One for each element read.
103
103
assertTrue (MyCheckpointAlgorithm .checkpointCountDownLatch .await (0 , TimeUnit .SECONDS ));
104
+ // <5> Job should be completed.
104
105
assertEquals (jobExecution .getBatchStatus (), BatchStatus .COMPLETED );
105
106
}
106
107
}
0 commit comments