[JBoss JIRA] (WFLY-4427) Step status of the failed step by <fail> element becomes COMPLETED.
by Takashi Nishigaya (JIRA)
[ https://issues.jboss.org/browse/WFLY-4427?page=com.atlassian.jira.plugin.... ]
Takashi Nishigaya edited comment on WFLY-4427 at 3/14/15 11:05 AM:
-------------------------------------------------------------------
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 case, the behavior is a little bit confusing. If the job failed at the step with allow-start-if-complete="true", the restart() will re-execute all of the steps with allow-start-if-complete="true" and the rest of the steps unexecuted previously. But if failed at the step with allow-start-if-complete="false", the failed job cannot be restarted, because the failed step is always evaluated as the previous step status, COMPLETED.
I cannot imagine the real world scenario of case 3 and the effective usage of allow-start-if-complete.
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 case, the behavior is a little bit confusing. If the job failed at the step with allow-start-if-complete="true", the restart() will re-execute all of the steps with allow-start-if-complete="true" and the rest of the steps unexecuted previously. But if failed at the step with allow-start-if-complete="false", the failed job cannot be restarted, because the failed step is always evaluated as the previous step status, FAILED.
I cannot imagine the real world scenario of case 3 and the effective usage of allow-start-if-complete.
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)
11 years, 4 months
[JBoss JIRA] (WFCORE-598) Make it possible to register a child at a certain position
by Kabir Khan (JIRA)
Kabir Khan created WFCORE-598:
---------------------------------
Summary: Make it possible to register a child at a certain position
Key: WFCORE-598
URL: https://issues.jboss.org/browse/WFCORE-598
Project: WildFly Core
Issue Type: Feature Request
Components: Domain Management
Reporter: Kabir Khan
Assignee: Kabir Khan
Fix For: 1.0.0.Beta1
The BasicResource stores child resources in a LinkedHashMap so it is ordered in the order of the adds. It should be possible to insert a new child somewhere in the middle, rather than just at the end.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4427) Step status of the failed step by <fail> element becomes COMPLETED.
by Takashi Nishigaya (JIRA)
[ https://issues.jboss.org/browse/WFLY-4427?page=com.atlassian.jira.plugin.... ]
Takashi Nishigaya edited comment on WFLY-4427 at 3/13/15 11:32 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 case, the behavior is a little bit confusing. If the job failed at the step with allow-start-if-complete="true", the restart() will re-execute all of the steps with allow-start-if-complete="true" and the rest of the steps unexecuted previously. But if failed at the step with allow-start-if-complete="false", the failed job cannot be restarted, because the failed step is always evaluated as the previous step status, FAILED.
I cannot imagine the real world scenario of case 3 and the effective usage of allow-start-if-complete.
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 case, the behavior is a little bit confusing. If the job failed at the step with allow-start-if-complete="true", the restart() will re-execute all of the steps with allow-start-if-complete="true" and the rest of the steps unexecuted previously. But if failed at the step with allow-start-if-complete="false", the failed job cannot be restarted, because the failed step is always evaluated as the previous step status, FAILED.
I cannot imagine the real world scenario of case 3 and the effective usage of allow-start-if-complete.
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)
11 years, 4 months
[JBoss JIRA] (WFLY-4427) Step status of the failed step by <fail> element becomes COMPLETED.
by Takashi Nishigaya (JIRA)
[ https://issues.jboss.org/browse/WFLY-4427?page=com.atlassian.jira.plugin.... ]
Takashi Nishigaya edited comment on WFLY-4427 at 3/13/15 11:31 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 case, the behavior is a little bit confusing. Ff the job failed at the step with allow-start-if-complete="true", the restart() will re-execute all of the steps with allow-start-if-complete="true" and the rest of the steps unexecuted previously. But if failed at the step with allow-start-if-complete="false", the failed job cannot be restarted, because the failed step is always evaluated as the previous step status, FAILED.
I cannot imagine the real world scenario of case 3 and the effective usage of allow-start-if-complete.
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" 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.
> 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)
11 years, 4 months
[JBoss JIRA] (WFLY-4427) Step status of the failed step by <fail> element becomes COMPLETED.
by Takashi Nishigaya (JIRA)
[ https://issues.jboss.org/browse/WFLY-4427?page=com.atlassian.jira.plugin.... ]
Takashi Nishigaya edited comment on WFLY-4427 at 3/13/15 11:32 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 case, the behavior is a little bit confusing. If the job failed at the step with allow-start-if-complete="true", the restart() will re-execute all of the steps with allow-start-if-complete="true" and the rest of the steps unexecuted previously. But if failed at the step with allow-start-if-complete="false", the failed job cannot be restarted, because the failed step is always evaluated as the previous step status, FAILED.
I cannot imagine the real world scenario of case 3 and the effective usage of allow-start-if-complete.
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 case, the behavior is a little bit confusing. Ff the job failed at the step with allow-start-if-complete="true", the restart() will re-execute all of the steps with allow-start-if-complete="true" and the rest of the steps unexecuted previously. But if failed at the step with allow-start-if-complete="false", the failed job cannot be restarted, because the failed step is always evaluated as the previous step status, FAILED.
I cannot imagine the real world scenario of case 3 and the effective usage of allow-start-if-complete.
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)
11 years, 4 months
[JBoss JIRA] (WFLY-4427) Step status of the failed step by <fail> element becomes COMPLETED.
by Takashi Nishigaya (JIRA)
[ 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)
11 years, 4 months
[JBoss JIRA] (WFLY-4427) Step status of the failed step by <fail> element becomes COMPLETED.
by Takashi Nishigaya (JIRA)
[ https://issues.jboss.org/browse/WFLY-4427?page=com.atlassian.jira.plugin.... ]
Takashi Nishigaya commented on WFLY-4427:
-----------------------------------------
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)
11 years, 4 months
[JBoss JIRA] (DROOLS-739) BatchExecutionCommand interface does not contain setLookup() or getCommands() as documented
by Brad K. (JIRA)
[ https://issues.jboss.org/browse/DROOLS-739?page=com.atlassian.jira.plugin... ]
Brad K. updated DROOLS-739:
---------------------------
Summary: BatchExecutionCommand interface does not contain setLookup() or getCommands() as documented (was: BatchExecutionCommand interface does not contain setLookup() as documented)
> BatchExecutionCommand interface does not contain setLookup() or getCommands() as documented
> -------------------------------------------------------------------------------------------
>
> Key: DROOLS-739
> URL: https://issues.jboss.org/browse/DROOLS-739
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.2.0.Final
> Environment: Windows 10 Preview, NetBeans 8.0.2, Java 1.7.u75
> Reporter: Brad K.
> Assignee: Edson Tirelli
> Priority: Minor
>
> http://docs.jboss.org/drools/release/6.2.0.Final/drools-docs/html/ch09.ht... describes usage of BatchExecutionCommand (BEC) as
> {quote}BatchExecutionCommand command = new BatchExecutionCommand();
> command.setLookup("ksession1");
> InsertObjectCommand insertObjectCommand = new InsertObjectCommand(new Person("john", 25));
> FireAllRulesCommand fireAllRulesCommand = new FireAllRulesCommand();
> command.getCommands().add(insertObjectCommand);
> command.getCommands().add(fireAllRulesCommand);{quote}
> However, the BEC interface appears to be a tag-only interface with no abstract methods. The BatchExecutionCommandImpl, however, does have methods, but there are no corresponding methods in the BEC. Either the documentation is incorrect or the BEC interface is incorrect.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4427) Step status of the failed step by <fail> element becomes COMPLETED.
by Cheng Fang (JIRA)
[ https://issues.jboss.org/browse/WFLY-4427?page=com.atlassian.jira.plugin.... ]
Cheng Fang commented on WFLY-4427:
----------------------------------
According to Scott Kurz (Batch spec lead), this is how the current batch spec (1.0 Rev A) is designed to work. The user can configure the step in question with attribute allow-start-if-complete="true" to enable it to run in the restart. Or use a step listener afterStep() to decide whether to fail the step or not (and thus the job).
This behavior is a bit surprising for batch applications with this type of designs. We should evaluate if anything can be done to improve the ease of use.
> 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)
11 years, 4 months