October 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13633) Undeployed CMR resource JNDI names are not deregisted as needing to be treated as CMR

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/WFLY-13633?page=com.atlassian.jira.plugi... ] Michael Musgrove reassigned WFLY-13633: --------------------------------------- Assignee: Lin Gao (was: Michael Musgrove) > Undeployed CMR resource JNDI names are not deregisted as needing to be treated as CMR > ------------------------------------------------------------------------------------- > > Key: WFLY-13633 > URL: https://issues.redhat.com/browse/WFLY-13633 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Thomas Jenkinson > Assignee: Lin Gao > Priority: Blocker > Labels: downstream_dependency > Fix For: 21.0.0.Final > > > https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java... does not remove the JNDI name from the list of names that Narayana will treat as CMR resources as it is removed from a copy of the map: https://github.com/jbosstm/narayana/blob/48818111d12d2e51b52082a00bcb6060... > This means that if Narayana encounters another resource at a later time with the same JNDI name it will consider it is a CMR resource. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[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: ---------------------------------- Attachment: DoubleNaNIssue.java > 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 > Attachments: DoubleNaNIssue.java > > > 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, 3 months

1
0
0 / 0

[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: ------------------------------------------- [~flavia.rainone], [~ropalka] ^^ > 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, 3 months

1
0
0 / 0

[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, 3 months

1
0
0 / 0

[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, 3 months

1
0
0 / 0

[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, 3 months

1
0
0 / 0

[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, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13934) adjust licenses for smallrye-open-api artifacts in microprofile-feature-pack-licenses.xml

by Roberto Oliveira (Jira)

[ https://issues.redhat.com/browse/WFLY-13934?page=com.atlassian.jira.plugi... ] Roberto Oliveira updated WFLY-13934: ------------------------------------ Affects Version/s: 21.0.0.Beta1 > adjust licenses for smallrye-open-api artifacts in microprofile-feature-pack-licenses.xml > ----------------------------------------------------------------------------------------- > > Key: WFLY-13934 > URL: https://issues.redhat.com/browse/WFLY-13934 > Project: WildFly > Issue Type: Bug > Affects Versions: 21.0.0.Beta1 > Reporter: Roberto Oliveira > Assignee: Roberto Oliveira > Priority: Minor > > smallrye-open-api dependency was replaced by smallrye-open-api-core and smallrye-open-api-jaxrs (see WFLY-13546) -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13934) adjust licenses for smallrye-open-api artifacts in microprofile-feature-pack-licenses.xml

by Roberto Oliveira (Jira)

Roberto Oliveira created WFLY-13934: --------------------------------------- Summary: adjust licenses for smallrye-open-api artifacts in microprofile-feature-pack-licenses.xml Key: WFLY-13934 URL: https://issues.redhat.com/browse/WFLY-13934 Project: WildFly Issue Type: Bug Reporter: Roberto Oliveira Assignee: Roberto Oliveira smallrye-open-api dependency was replaced by smallrye-open-api-core and smallrye-open-api-jaxrs (see WFLY-13546) -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[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, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2020