[JBoss JIRA] (DROOLS-743) kie ci regression: unable to resolve dependency of kjar during KB creation
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-743?page=com.atlassian.jira.plugin... ]
Matteo Mortari updated DROOLS-743:
----------------------------------
Attachment: 20150317.DROOLS-743.zip
The reproducer(s).
> kie ci regression: unable to resolve dependency of kjar during KB creation
> --------------------------------------------------------------------------
>
> Key: DROOLS-743
> URL: https://issues.jboss.org/browse/DROOLS-743
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.2.0.Final
> Environment: Please notice it works OK with Drools 6.1.0.Final
> Currently JDK8, Wildfly 8.2.0.Final.
> Reporter: Matteo Mortari
> Assignee: Mario Fusco
> Attachments: 20150317.DROOLS-743.zip
>
>
> h5. Executive summary
> With version 610Final using kie-ci, if the kjar KieModule had some pom dependency, say on a "object model" or reference package, the classes in the dependency artifact would be resolved correctly during knowledge base creation. However with 620Final, when the kjar KieModule is fetched and knowledge base creation starts, it seems like the kie-ci is no longer able to "see" the classes of this pom dependency.
> This is a problem especially in all scenarios where different rule packages kjar KieModule defines rules based on a common library, "object model".
> h5. Details and Reproducer
> Suppose you have a library, object model, package reference .jar artifact, attached:
> {{exercise_kie_ci-rules-objectmodel}}
> Suppose you have a simple kjar project:
> {{exercise_kie_ci-rules}}
> with very simple rule
> {code}
> package com.acme.exercise_kie_ci_rules;
> import com.acme.exercise_kie_ci_rules_objectmodel.AcmePojo;
> rule "just test dependency of objectmodel"
> no-loop
> when
> then
> AcmePojo pojo = new AcmePojo("Ciao");
> System.out.println("Simple rule for inserting pojo..."+pojo);
> insert(pojo);
> end
> {code}
> You will notice in kjar pom the dependency is explicited and rule compilation works ok with kie-maven-plugin.
> Now install them with:
> mvn install the artifactId exercise_kie_ci-rules-objectmodel
> mvn install the artifactId exercise_kie_ci-rules
> Now deploy the {{exercise-kie-ci}} on WildFly:
> IFF Drools version is 610Final works ok:
> {code}
> 19:21:03,708 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "exercise-kie-ci.war" (runtime-name: "exercise-kie-ci.war")
> ...
> 19:21:07,776 INFO [org.drools.compiler.kie.builder.impl.KieRepositoryImpl] (ServerService Thread Pool -- 50) KieModule was added:ZipKieModule[ ReleaseId=com.acme:exercise_kie_ci-rules:1.0.0file=C:\Users\mmortari\.m2\repository\com\acme\exercise_kie_ci-rules\1.0.0\exercise_kie_ci-rules-1.0.0.jar]
> 19:21:07,877 INFO [com.acme.exercise_kie_ci.Exercise] (ServerService Thread Pool -- 50) Creating kieBase with STREAM option
> 19:21:07,960 INFO [com.acme.exercise_kie_ci.Exercise] (ServerService Thread Pool -- 50) There should be rules:
> 19:21:07,960 INFO [com.acme.exercise_kie_ci.Exercise] (ServerService Thread Pool -- 50) kp [Package name=com.acme.exercise_kie_ci_rules] rule just test dependency of objectmodel
> 19:21:08,123 INFO [org.wildfly.extension.undertow] (MSC service thread 1-12) JBAS017534: Registered web context: /exercise-kie-ci
> 19:21:08,146 INFO [org.jboss.as.server] (ServerService Thread Pool -- 28) JBAS018559: Deployed "exercise-kie-ci.war" (runtime-name : "exercise-kie-ci.war")
> {code}
> Kindly notice line mentioning the artifact was kjar KieModule was resolved and correctly imported, an debug log line mentioning the very simple rule is available in the KB.
> However, if you now switch the Drools version to 620Final in the {{exercise-kie-ci}} and redeploy to WildFly, it would no longer work:
> {code}
> 19:23:09,524 ERROR [org.drools.compiler.kie.builder.impl.AbstractKieModule] (ServerService Thread Pool -- 54) Unable to build KieBaseModel:defaultKieBase
> Error importing : 'com.acme.exercise_kie_ci_rules_objectmodel.AcmePojo'
> 19:23:09,747 ERROR [org.drools.compiler.kie.builder.impl.AbstractKieModule] (ServerService Thread Pool -- 54) Unable to build KieBaseModel:defaultKieBase
> Error importing : 'com.acme.exercise_kie_ci_rules_objectmodel.AcmePojo'
> 19:23:09,748 INFO [com.acme.exercise_kie_ci.Exercise] (ServerService Thread Pool -- 54) Message [id=1, level=ERROR, path=rules.drl, line=1, column=0
> text=Error importing : 'com.acme.exercise_kie_ci_rules_objectmodel.AcmePojo']
> {code}
> I will attach reproducer.
> Could you kindly advise, please?
> As always, thank you.
> Ciao
> MM
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (DROOLS-743) kie ci regression: unable to resolve dependency of kjar during KB creation
by Matteo Mortari (JIRA)
Matteo Mortari created DROOLS-743:
-------------------------------------
Summary: kie ci regression: unable to resolve dependency of kjar during KB creation
Key: DROOLS-743
URL: https://issues.jboss.org/browse/DROOLS-743
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 6.2.0.Final
Environment: Please notice it works OK with Drools 6.1.0.Final
Currently JDK8, Wildfly 8.2.0.Final.
Reporter: Matteo Mortari
Assignee: Mario Fusco
h5. Executive summary
With version 610Final using kie-ci, if the kjar KieModule had some pom dependency, say on a "object model" or reference package, the classes in the dependency artifact would be resolved correctly during knowledge base creation. However with 620Final, when the kjar KieModule is fetched and knowledge base creation starts, it seems like the kie-ci is no longer able to "see" the classes of this pom dependency.
This is a problem especially in all scenarios where different rule packages kjar KieModule defines rules based on a common library, "object model".
h5. Details and Reproducer
Suppose you have a library, object model, package reference .jar artifact, attached:
{{exercise_kie_ci-rules-objectmodel}}
Suppose you have a simple kjar project:
{{exercise_kie_ci-rules}}
with very simple rule
{code}
package com.acme.exercise_kie_ci_rules;
import com.acme.exercise_kie_ci_rules_objectmodel.AcmePojo;
rule "just test dependency of objectmodel"
no-loop
when
then
AcmePojo pojo = new AcmePojo("Ciao");
System.out.println("Simple rule for inserting pojo..."+pojo);
insert(pojo);
end
{code}
You will notice in kjar pom the dependency is explicited and rule compilation works ok with kie-maven-plugin.
Now install them with:
mvn install the artifactId exercise_kie_ci-rules-objectmodel
mvn install the artifactId exercise_kie_ci-rules
Now deploy the {{exercise-kie-ci}} on WildFly:
IFF Drools version is 610Final works ok:
{code}
19:21:03,708 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "exercise-kie-ci.war" (runtime-name: "exercise-kie-ci.war")
...
19:21:07,776 INFO [org.drools.compiler.kie.builder.impl.KieRepositoryImpl] (ServerService Thread Pool -- 50) KieModule was added:ZipKieModule[ ReleaseId=com.acme:exercise_kie_ci-rules:1.0.0file=C:\Users\mmortari\.m2\repository\com\acme\exercise_kie_ci-rules\1.0.0\exercise_kie_ci-rules-1.0.0.jar]
19:21:07,877 INFO [com.acme.exercise_kie_ci.Exercise] (ServerService Thread Pool -- 50) Creating kieBase with STREAM option
19:21:07,960 INFO [com.acme.exercise_kie_ci.Exercise] (ServerService Thread Pool -- 50) There should be rules:
19:21:07,960 INFO [com.acme.exercise_kie_ci.Exercise] (ServerService Thread Pool -- 50) kp [Package name=com.acme.exercise_kie_ci_rules] rule just test dependency of objectmodel
19:21:08,123 INFO [org.wildfly.extension.undertow] (MSC service thread 1-12) JBAS017534: Registered web context: /exercise-kie-ci
19:21:08,146 INFO [org.jboss.as.server] (ServerService Thread Pool -- 28) JBAS018559: Deployed "exercise-kie-ci.war" (runtime-name : "exercise-kie-ci.war")
{code}
Kindly notice line mentioning the artifact was kjar KieModule was resolved and correctly imported, an debug log line mentioning the very simple rule is available in the KB.
However, if you now switch the Drools version to 620Final in the {{exercise-kie-ci}} and redeploy to WildFly, it would no longer work:
{code}
19:23:09,524 ERROR [org.drools.compiler.kie.builder.impl.AbstractKieModule] (ServerService Thread Pool -- 54) Unable to build KieBaseModel:defaultKieBase
Error importing : 'com.acme.exercise_kie_ci_rules_objectmodel.AcmePojo'
19:23:09,747 ERROR [org.drools.compiler.kie.builder.impl.AbstractKieModule] (ServerService Thread Pool -- 54) Unable to build KieBaseModel:defaultKieBase
Error importing : 'com.acme.exercise_kie_ci_rules_objectmodel.AcmePojo'
19:23:09,748 INFO [com.acme.exercise_kie_ci.Exercise] (ServerService Thread Pool -- 54) Message [id=1, level=ERROR, path=rules.drl, line=1, column=0
text=Error importing : 'com.acme.exercise_kie_ci_rules_objectmodel.AcmePojo']
{code}
I will attach reproducer.
Could you kindly advise, please?
As always, thank you.
Ciao
MM
--
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 edited comment on WFLY-4427 at 3/17/15 2:14 PM:
-----------------------------------------------------------
Batch TCK has some tests that use <fail> subelement under steps to enforce compliance to current batch spec (1.0 Rev A):
https://github.com/WASdev/standards.jsr352.jbatch/blob/master/com.ibm.jba...
https://github.com/WASdev/standards.jsr352.jbatch/blob/master/com.ibm.jba...
https://github.com/WASdev/standards.jsr352.jbatch/blob/master/com.ibm.jba...
https://github.com/WASdev/standards.jsr352.jbatch/blob/master/com.ibm.jba...
https://github.com/WASdev/standards.jsr352.jbatch/blob/master/com.ibm.jba...
https://github.com/WASdev/standards.jsr352.jbatch/blob/master/com.ibm.jba...
In [testTransitionElementOnAttrValuesWithRestartJobParamOverrides|https://git...], the test strategy explicitly verifies that the step is not reexecuted after the previous job execution failed or stopped with <fail> or <stop> subelement.
was (Author: cfang):
Batch TCK has some tests that use <fail> subelement under steps to enforce compliance to current batch spec (1.0 Rev A):
https://github.com/WASdev/standards.jsr352.jbatch/blob/master/com.ibm.jba...
https://github.com/WASdev/standards.jsr352.jbatch/blob/master/com.ibm.jba...
https://github.com/WASdev/standards.jsr352.jbatch/blob/master/com.ibm.jba...
https://github.com/WASdev/standards.jsr352.jbatch/blob/master/com.ibm.jba...
https://github.com/WASdev/standards.jsr352.jbatch/blob/master/com.ibm.jba...
https://github.com/WASdev/standards.jsr352.jbatch/blob/master/com.ibm.jba...
> 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] (JGRP-1675) Threads stuck in FlowControl.decrementIfEnoughCredits
by Sebastiano Vigna (JIRA)
[ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.... ]
Sebastiano Vigna commented on JGRP-1675:
----------------------------------------
Well, presently we'd have to try and try for days until it happens again. I'll see if I can make it happen with a simulated environment—for the time being we'll just keep the protocols out of the stack.
> Threads stuck in FlowControl.decrementIfEnoughCredits
> -----------------------------------------------------
>
> Key: JGRP-1675
> URL: https://issues.jboss.org/browse/JGRP-1675
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.5
>
> Attachments: jgroups-udp-radim.xml, RemoteGetStressTest.java, UPerf2.java
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.
> h3. Workaround
> It appears that setting MFC and UFC max_credits to 10M or removing these protocols at all is a workaround for this issue.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (JGRP-1675) Threads stuck in FlowControl.decrementIfEnoughCredits
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1675:
--------------------------------
Can you reproduce this ? It would be interesting to see what the active pool/queue sizes are, e.g. with {{probe.sh jmx=UDP.oob,reg,int}}.
You can also look at the credits of all members with {{probe.sh op=UFC.printCredits}}.
OK, this is a unicast message, or else it would not be stuck in {{UFC}}. We now need to see which peer it is that's not processing this node's messages. Method {{printCredits()}} should list credits for each receiver, and the one that's 0 is the one you need to look at.
Note that you can also connect via jconsole to get the above data.
I suspect that the peer's thread pool is maxed out, but do confirm this.
> Threads stuck in FlowControl.decrementIfEnoughCredits
> -----------------------------------------------------
>
> Key: JGRP-1675
> URL: https://issues.jboss.org/browse/JGRP-1675
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.5
>
> Attachments: jgroups-udp-radim.xml, RemoteGetStressTest.java, UPerf2.java
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.
> h3. Workaround
> It appears that setting MFC and UFC max_credits to 10M or removing these protocols at all is a workaround for this issue.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (JGRP-1675) Threads stuck in FlowControl.decrementIfEnoughCredits
by Sebastiano Vigna (JIRA)
[ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.... ]
Sebastiano Vigna commented on JGRP-1675:
----------------------------------------
No, they were stuck for 8 hours and the all other members of the group were happily exchanging messages. Only one agent on four was stuck—so it cannot be the fault of another party.
> Threads stuck in FlowControl.decrementIfEnoughCredits
> -----------------------------------------------------
>
> Key: JGRP-1675
> URL: https://issues.jboss.org/browse/JGRP-1675
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.5
>
> Attachments: jgroups-udp-radim.xml, RemoteGetStressTest.java, UPerf2.java
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.
> h3. Workaround
> It appears that setting MFC and UFC max_credits to 10M or removing these protocols at all is a workaround for this issue.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (JGRP-1675) Threads stuck in FlowControl.decrementIfEnoughCredits
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1675:
--------------------------------
Well, senders are sometimes stuck in UFC if they send faster than a receiver can process messages; that's not necessarily an indication of a bug. The question is what are you doing and what type of messages is the ParsingThread sending (OOB, regular) ?
If you look at the receivers, are they all stuck in application code, processing mesages ?
> Threads stuck in FlowControl.decrementIfEnoughCredits
> -----------------------------------------------------
>
> Key: JGRP-1675
> URL: https://issues.jboss.org/browse/JGRP-1675
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.5
>
> Attachments: jgroups-udp-radim.xml, RemoteGetStressTest.java, UPerf2.java
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.
> h3. Workaround
> It appears that setting MFC and UFC max_credits to 10M or removing these protocols at all is a workaround for this issue.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (DROOLS-742) DecisionTableXLSToDecisionTableGuidedConverterTest fails on jdk8
by Tibor Zimányi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-742?page=com.atlassian.jira.plugin... ]
Tibor Zimányi updated DROOLS-742:
---------------------------------
Git Pull Request: https://github.com/droolsjbpm/drools-wb/pull/22
> DecisionTableXLSToDecisionTableGuidedConverterTest fails on jdk8
> ----------------------------------------------------------------
>
> Key: DROOLS-742
> URL: https://issues.jboss.org/browse/DROOLS-742
> Project: Drools
> Issue Type: Bug
> Components: decision tables
> Affects Versions: 6.2.0.Final
> Reporter: Tibor Zimányi
> Assignee: Mario Fusco
> Priority: Minor
>
> Failing test is from drools-wb repo.
> Test methods testConditions() and testConditionsIndexedParameters() fails on jdk8.
> XLS files used in these methods contain multiple parameters column (column with more parameters than one). When XLS is parsed, these parameters are transformed into child columns of BRLConditionColumn. In ParameterUtilities class is method extractTemplateKeys. This method extracts params from preprocessed original string from XLS table cell containing parameters. But because the method uses HashSet as return value, the ordering of parameters cannot be determined (in HashSet, the order of items can be different than the order in which the items were inserted).
--
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:
----------------------------------
Takashi, can you start a discussion on batch spec list (public(a)jbatch.java.net) https://java.net/projects/jbatch/lists
on this issue? There are quite some TCK tests rely on the current behavior. So I think the best option is to first explore possibility of spec improvement.
> 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