[JBoss JIRA] (WFLY-13933) access-log entries might become lost during the shutdown even if graceful timeout is specified
by Bartosz Baranowski (Jira)
[ https://issues.redhat.com/browse/WFLY-13933?page=com.atlassian.jira.plugi... ]
Bartosz Baranowski commented on WFLY-13933:
-------------------------------------------
It looks like few undertow related classes violate contracts.
[https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io...]
Implements Closeable. It has single method, which has following contract:
??Closes this stream and releases any system resources associated with it. If the stream is already closed then invoking this method has no effect.??
??As noted in [{{AutoCloseable.close()}}|https://docs.oracle.com/javase/8/docs/api/j..., cases where the close may fail require careful attention. It is strongly advised to relinquish the underlying resources and to internally _mark_ the {{Closeable}} as closed, prior to throwing the {{IOException}}.??
As is, close method in DefaultAccessLogReceiver just flip a boolean flag. Actually resource freeing actions are performed in another thread( XnioWorker).
Second violation is in [https://github.com/wildfly/wildfly/blob/master/undertow/src/main/java...
In Service([https://github.com/jboss-msc/jboss-msc/blob/1.4/src/main/java/or... on stop there:
??Stop the service. Do not return until the service has been fully stopped, unless an asynchronous service stop is performed.??
In both cases current behavior violate contract. In case of DefaultAccessLogReceiver - stream is still open after close() method returns. IT is possible for stream to remain open, if thread, in which it is supposed to be closed is terminated prior full write or even execution due to changes in -WFCORE-1632.-
As to AccessLogService - all underlying resources are not stopped when method returns from stop(). As is, IoUtils.safeClose((DefaultAccessLogReceiver) logReceiver); only flips flag in log receiver. Not only that, it does it only if DefaultLogReceiver is being used(not sure if its possible to configure something else, but it might be, judging from this check).
> access-log entries might become lost during the shutdown even if graceful timeout is specified
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-13933
> URL: https://issues.redhat.com/browse/WFLY-13933
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 20.0.0.Final
> Reporter: Masafumi Miura
> Assignee: Bartosz Baranowski
> Priority: Major
>
> access-log has a possibility to be lost during WildFly shutdown even if a graceful timeout is specified.
> If I understand correctly, access-log processing runs on a different thread from the application processing and the graceful shutdown does not care about it.
> Since WildFly 16+, WFCORE-1632 changed the shutdown behavior to wait only for 100ms (hard-coded). So, WildFly 16+ does not wait for completing a task worker thread processing access-log.
> I understand the purpose of WFCORE-1632. However, it might be good if we have an option to tune the wait time. (Of course, it would be difficult to know how long wait time is sufficient for completion. And specifying a large wait time can be a cause of long shutdown time. So, it's still questionable how it's useful.)
> Or, if it's possible to implement that the graceful shutdown can wait for access-log processing, it would be better. (This might be RFE?).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (DROOLS-5692) Inaccurate rule execution in executable model in RHDM 7
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-5692?page=com.atlassian.jira.plug... ]
Mario Fusco updated DROOLS-5692:
--------------------------------
Sprint: 2020 Week 40-42 (from Sep 28)
> Inaccurate rule execution in executable model in RHDM 7
> --------------------------------------------------------
>
> Key: DROOLS-5692
> URL: https://issues.redhat.com/browse/DROOLS-5692
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.44.0.Final
> Reporter: Abhijit Humbe
> Assignee: Mario Fusco
> Priority: Major
>
> Model compile generate code that inaccurately fires the rule in comparison to non executable model code created rulebase or in 6.x.
> {code:java}
> rule "test_rule"
> dialect "java"
> when
> $nanTest : DoubleNaNTest( $testDouble1 : testDouble1 , $testDouble2 : testDouble2 , $testDouble1 + 10 > $testDouble2 , testBoolean!=null, testBoolean==false)
> then
> System.out.println("rule_a fired ");
> $nanTest.setTestBoolean(true);
> update($nanTest);
> end
> DoubleNaNTest nan = new DoubleNaNTest();
> nan.setTestBoolean(false);
> nan.setTestDouble1(Double.NaN);//Double.NaN
> nan.setTestDouble2(100.0);
> KieSession ksession = sumKieBaseShort.newKieSession();
> ksession.insert(nan);
> {code}
>
> Expected:
> Above rule should not fired in executable model.
> Actual result:
> Above rule fired in executable model.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (WFLY-13933) access-log entries might become lost during the shutdown even if graceful timeout is specified
by Masafumi Miura (Jira)
[ https://issues.redhat.com/browse/WFLY-13933?page=com.atlassian.jira.plugi... ]
Masafumi Miura updated WFLY-13933:
----------------------------------
Affects Version/s: 20.0.0.Final
> access-log entries might become lost during the shutdown even if graceful timeout is specified
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-13933
> URL: https://issues.redhat.com/browse/WFLY-13933
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 20.0.0.Final
> Reporter: Masafumi Miura
> Assignee: Bartosz Baranowski
> Priority: Major
>
> access-log has a possibility to be lost during WildFly shutdown even if a graceful timeout is specified.
> If I understand correctly, access-log processing runs on a different thread from the application processing and the graceful shutdown does not care about it.
> Since WildFly 16+, WFCORE-1632 changed the shutdown behavior to wait only for 100ms (hard-coded). So, WildFly 16+ does not wait for completing a task worker thread processing access-log.
> I understand the purpose of WFCORE-1632. However, it might be good if we have an option to tune the wait time. (Of course, it would be difficult to know how long wait time is sufficient for completion. And specifying a large wait time can be a cause of long shutdown time. So, it's still questionable how it's useful.)
> Or, if it's possible to implement that the graceful shutdown can wait for access-log processing, it would be better. (This might be RFE?).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (WFLY-13933) access-log entries might become lost during the shutdown even if graceful timeout is specified
by Masafumi Miura (Jira)
[ https://issues.redhat.com/browse/WFLY-13933?page=com.atlassian.jira.plugi... ]
Masafumi Miura updated WFLY-13933:
----------------------------------
Description:
access-log has a possibility to be lost during WildFly shutdown even if a graceful timeout is specified.
If I understand correctly, access-log processing runs on a different thread from the application processing and the graceful shutdown does not care about it.
Since WildFly 16+, WFCORE-1632 changed the shutdown behavior to wait only for 100ms (hard-coded). So, WildFly 16+ does not wait for completing a task worker thread processing access-log.
I understand the purpose of WFCORE-1632. However, it might be good if we have an option to tune the wait time. (Of course, it would be difficult to know how long wait time is sufficient for completion. And specifying a large wait time can be a cause of long shutdown time. So, it's still questionable how it's useful.)
Or, if it's possible to implement that the graceful shutdown can wait for access-log processing, it would be better. (This might be RFE?).
was:
access-log has a possibility to be lost during EAP 7.3 shutdown even if a graceful timeout is specified.
If I understand correctly, access-log processing runs on a different thread from the application processing and the graceful shutdown does not care about it.
Since EAP 7.3, WFCORE-1632 changed the shutdown behavior to wait only for 100ms (hard-coded). So, EAP 7.3 does not wait for completing a task worker thread processing access-log.
I understand the purpose of WFCORE-1632. However, it might be good if we have an option to tune the wait time. (Of course, it would be difficult to know how long wait time is sufficient for completion. And specifying a large wait time can be a cause of long shutdown time. So, it's still questionable how it's useful.)
Or, if it's possible to implement that the graceful shutdown can wait for access-log processing, it would be better. (This might be RFE?).
> access-log entries might become lost during the shutdown even if graceful timeout is specified
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-13933
> URL: https://issues.redhat.com/browse/WFLY-13933
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Masafumi Miura
> Assignee: Bartosz Baranowski
> Priority: Major
>
> access-log has a possibility to be lost during WildFly shutdown even if a graceful timeout is specified.
> If I understand correctly, access-log processing runs on a different thread from the application processing and the graceful shutdown does not care about it.
> Since WildFly 16+, WFCORE-1632 changed the shutdown behavior to wait only for 100ms (hard-coded). So, WildFly 16+ does not wait for completing a task worker thread processing access-log.
> I understand the purpose of WFCORE-1632. However, it might be good if we have an option to tune the wait time. (Of course, it would be difficult to know how long wait time is sufficient for completion. And specifying a large wait time can be a cause of long shutdown time. So, it's still questionable how it's useful.)
> Or, if it's possible to implement that the graceful shutdown can wait for access-log processing, it would be better. (This might be RFE?).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (WFLY-13933) access-log entries might become lost during the shutdown even if graceful timeout is specified
by Masafumi Miura (Jira)
[ https://issues.redhat.com/browse/WFLY-13933?page=com.atlassian.jira.plugi... ]
Masafumi Miura moved JBEAP-20297 to WFLY-13933:
-----------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-13933 (was: JBEAP-20297)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Web (Undertow)
(was: Web (Undertow))
Fix Version/s: (was: 7.3.5.GA)
> access-log entries might become lost during the shutdown even if graceful timeout is specified
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-13933
> URL: https://issues.redhat.com/browse/WFLY-13933
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Masafumi Miura
> Assignee: Bartosz Baranowski
> Priority: Major
>
> access-log has a possibility to be lost during EAP 7.3 shutdown even if a graceful timeout is specified.
> If I understand correctly, access-log processing runs on a different thread from the application processing and the graceful shutdown does not care about it.
> Since EAP 7.3, WFCORE-1632 changed the shutdown behavior to wait only for 100ms (hard-coded). So, EAP 7.3 does not wait for completing a task worker thread processing access-log.
> I understand the purpose of WFCORE-1632. However, it might be good if we have an option to tune the wait time. (Of course, it would be difficult to know how long wait time is sufficient for completion. And specifying a large wait time can be a cause of long shutdown time. So, it's still questionable how it's useful.)
> Or, if it's possible to implement that the graceful shutdown can wait for access-log processing, it would be better. (This might be RFE?).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (DROOLS-5692) Inaccurate rule execution in executable model in RHDM 7
by Abhijit Humbe (Jira)
[ https://issues.redhat.com/browse/DROOLS-5692?page=com.atlassian.jira.plug... ]
Abhijit Humbe updated DROOLS-5692:
----------------------------------
Description:
Model compile generate code that inaccurately fires the rule in comparison to non executable model code created rulebase or in 6.x.
{code:java}
rule "test_rule"
dialect "java"
when
$nanTest : DoubleNaNTest( $testDouble1 : testDouble1 , $testDouble2 : testDouble2 , $testDouble1 + 10 > $testDouble2 , testBoolean!=null, testBoolean==false)
then
System.out.println("rule_a fired ");
$nanTest.setTestBoolean(true);
update($nanTest);
end
DoubleNaNTest nan = new DoubleNaNTest();
nan.setTestBoolean(false);
nan.setTestDouble1(Double.NaN);//Double.NaN
nan.setTestDouble2(100.0);
KieSession ksession = sumKieBaseShort.newKieSession();
ksession.insert(nan);
{code}
Expected:
Above rule should not fired in executable model.
Actual result:
Above rule fired in executable model.
was:
Model compile generate code that inaccurately fires the rule in comparison to non executable model code created rulebase or in 6.x.
{code:java}
rule "test_rule"
dialect "java"
when
$nanTest : NanTest( $testDouble1 : testDouble1 , $testDouble2 : testDouble2 , $testDouble1 + 10 > $testDouble2 , testBoolean!=null, testBoolean==false)
then
System.out.println("rule_a fired ");
$nanTest.setTestBoolean(true);
update($nanTest);
end
DoubleNaNTest nan = new DoubleNaNTest();
nan.setTestBoolean(false);
nan.setTestDouble1(Double.NaN);//Double.NaN
nan.setTestDouble2(100.0);
KieSession ksession = sumKieBaseShort.newKieSession();
ksession.insert(nan);
{code}
Expected:
Above rule should not fired in executable model.
Actual result:
Above rule fired in executable model.
> Inaccurate rule execution in executable model in RHDM 7
> --------------------------------------------------------
>
> Key: DROOLS-5692
> URL: https://issues.redhat.com/browse/DROOLS-5692
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.44.0.Final
> Reporter: Abhijit Humbe
> Assignee: Mario Fusco
> Priority: Major
>
> Model compile generate code that inaccurately fires the rule in comparison to non executable model code created rulebase or in 6.x.
> {code:java}
> rule "test_rule"
> dialect "java"
> when
> $nanTest : DoubleNaNTest( $testDouble1 : testDouble1 , $testDouble2 : testDouble2 , $testDouble1 + 10 > $testDouble2 , testBoolean!=null, testBoolean==false)
> then
> System.out.println("rule_a fired ");
> $nanTest.setTestBoolean(true);
> update($nanTest);
> end
> DoubleNaNTest nan = new DoubleNaNTest();
> nan.setTestBoolean(false);
> nan.setTestDouble1(Double.NaN);//Double.NaN
> nan.setTestDouble2(100.0);
> KieSession ksession = sumKieBaseShort.newKieSession();
> ksession.insert(nan);
> {code}
>
> Expected:
> Above rule should not fired in executable model.
> Actual result:
> Above rule fired in executable model.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (DROOLS-5692) Inaccurate rule execution in executable model in RHDM 7
by Abhijit Humbe (Jira)
[ https://issues.redhat.com/browse/DROOLS-5692?page=com.atlassian.jira.plug... ]
Abhijit Humbe moved RHDM-1466 to DROOLS-5692:
---------------------------------------------
Project: Drools (was: Red Hat Decision Manager)
Key: DROOLS-5692 (was: RHDM-1466)
Workflow: GIT Pull Request workflow (was: CDW with docs v1)
Docs QE Status: NEW
Component/s: core engine
(was: BRE)
Affects Version/s: 7.44.0.Final
(was: 7.8.0.GA)
QE Status: NEW
> Inaccurate rule execution in executable model in RHDM 7
> --------------------------------------------------------
>
> Key: DROOLS-5692
> URL: https://issues.redhat.com/browse/DROOLS-5692
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.44.0.Final
> Reporter: Abhijit Humbe
> Assignee: Mario Fusco
> Priority: Major
>
> Model compile generate code that inaccurately fires the rule in comparison to non executable model code created rulebase or in 6.x.
> {code:java}
> rule "test_rule"
> dialect "java"
> when
> $nanTest : NanTest( $testDouble1 : testDouble1 , $testDouble2 : testDouble2 , $testDouble1 + 10 > $testDouble2 , testBoolean!=null, testBoolean==false)
> then
> System.out.println("rule_a fired ");
> $nanTest.setTestBoolean(true);
> update($nanTest);
> end
> DoubleNaNTest nan = new DoubleNaNTest();
> nan.setTestBoolean(false);
> nan.setTestDouble1(Double.NaN);//Double.NaN
> nan.setTestDouble2(100.0);
> KieSession ksession = sumKieBaseShort.newKieSession();
> ksession.insert(nan);
> {code}
>
> Expected:
> Above rule should not fired in executable model.
> Actual result:
> Above rule fired in executable model.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months