[
https://issues.jboss.org/browse/WFLY-4427?page=com.atlassian.jira.plugin....
]
Takashi Nishigaya edited comment on WFLY-4427 at 3/13/15 9:21 PM:
------------------------------------------------------------------
Thank you, Cheng.
I am considering the restarting use cases of using allow-start-if-complete attribute:
# All of the steps defined with allow-start-if-complete="false" (default)
#* This type of job cannot be restarted. This is almost the same meaning as
restartable="false".
# All of the steps defined with allow-start-if-complete="true"
#* This type of job is designed to re-execute all of the steps of the failed job. This is
the same as newly invoking start(), instead of restart().
# Mixed with steps with allow-start-if-complete="true" and
allow-start-if-complete="false"
#* In this type of job, restarting the failed job means compensation purpose. Restart()
will only re-execute all of the steps with allow-start-if-complete="true" and
the rest of the steps unexecuted previously. It is used only when a set of the job
recovery steps is determined at design time.
When designing the job definitions, if we want to restart the failed job from the point of
the step just failed previously, we cannot use the fail-by-exit-status strategy. In such
case, we should use fail-by-throwing-a-exception strategy.
was (Author: nishigaya):
Thank you, Cheng.
I am considering the restarting use cases of using allow-start-if-complete attribute:
# All of the steps defined with allow-start-if-complete="false" (default)
#* This type of job cannot be restarted. This is almost the same meaning as
restartable="false".
# All of the steps defined with allow-start-if-complete="true"
#* This type of job is designed to re-execute all of the steps of the failed job. This is
the same as newly invoking start(), instead of restart().
# Mixed with steps with allow-start-if-complete="true" and
allow-start-if-complete="false"
#* In this type of job, restarting the failed job means compensation purpose. Restart()
will only re-execute all of the steps with allow-start-if-complete="true". It is
used only when a set of the job recovery steps is determined at design time.
When designing the job definitions, if we want to restart the failed job from the point of
the step just failed previously, we cannot use the fail-by-exit-status strategy. In such
case, we should use fail-by-throwing-a-exception strategy.
Step status of the failed step by <fail> element becomes
COMPLETED.
-------------------------------------------------------------------
Key: WFLY-4427
URL:
https://issues.jboss.org/browse/WFLY-4427
Project: WildFly
Issue Type: Bug
Components: Batch
Affects Versions: 8.2.0.Final
Reporter: Takashi Nishigaya
Assignee: Cheng Fang
Attachments: batch-restart-failed.zip
Assuming the following job definition, if STEP1 returns "1" as the exit status,
the job status becomes FAILED. But the step status is COMPLETED.
{noformat}
job status: FAILED
step: STEP1, step status: COMPLETED
{noformat}
{noformat}
<job id="batch-job1" version="1.0"
xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/jobXML_1_0.xsd ">
<step id="STEP1">
<batchlet ref="TestBatchlet1" />
<next on="0" to="STEP2" />
<fail on="1" exit-status="FAILED_BY_EXIT_STATUS" />
</step>
<step id="STEP2">
<batchlet ref="TestBatchlet2" />
</step>
</job>
{noformat}
In this case, we can not restart the failed job from the failed step STEP1.
This behavior is correct based on the description of 10.8 Restart Processing, 3. a. in
JSR 352.
But it is not expected result.
{quote}
10.8 Restart Processing
3. Starting at the restart position, each execution element is re-examined to determine
if it should re-execute:
a. If the execution element is a COMPLETED step that specifies allow-restart-if-
complete=false, then follow the transition to the next
execution element based on the exit status for this step from the previous execution.
{quote}
On the other hand, If the STEP1 is failed by throwing an exception, both of the resulting
job status and the step status are FAILED.
{noformat}
job status: FAILED
step: STEP1, step status: FAILED
{noformat}
In this case, restarting the failed job is correctly executed, because the step status is
FAILED.
I think the step status of the failed step should be FAILED in both cases. But the
section "8.6.2 Fail Element" of JSR352 says nothing about what step status value
must be exposed after failed.
This behavior is the same in GlassFish 4 and WildFly 8.2.
So, I want to know what is the correct specification or intended behavior.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)