February 2021 - jboss-jira - Jboss List Archives

[Red Hat JIRA] (WFLY-13043) ManagedScheduledExecutorService keeps executing tasks after an exception is thrown

by Bartosz Baranowski (Jira)

[ https://issues.redhat.com/browse/WFLY-13043?page=com.atlassian.jira.plugi... ] Bartosz Baranowski reassigned WFLY-13043: ----------------------------------------- Assignee: Bartosz Baranowski (was: Eduardo Martins) > ManagedScheduledExecutorService keeps executing tasks after an exception is thrown > ----------------------------------------------------------------------------------- > > Key: WFLY-13043 > URL: https://issues.redhat.com/browse/WFLY-13043 > Project: WildFly > Issue Type: Bug > Components: Concurrency Utilities > Affects Versions: 18.0.1.Final, 22.0.1.Final > Reporter: Vinicius Kopcheski > Assignee: Bartosz Baranowski > Priority: Major > > There is apparently a bug in the implementation of the ManagedScheduledExecutorService, more specifically when using the inherited method of the ScheduledExecutorService, [scheduleWithFixedDelay|https://docs.oracle.com/javase/7/docs/api/java/uti...]. On its javadoc it is stated "If any execution of the task encounters an exception, subsequent executions are suppressed.". > When [this code|https://github.com/kopcheski/managed-scheduled-executor/blob/master/...] is executed in any Wildfly from 10 to 18, the task is kept alive in the scheduler after an exception is thrown and subsequent calls will happen anyway, contradicting the javadoc. > To add evidences of a misbehavior, I did two extra checks: > 1. Running the exact same code in another JavaEE server (Payara); > 2. Using plain JavaSE with the ScheduledExecutorService. > In both cases, after an exception being thrown, subsequent executions of it are - as the javadoc states - suppressed. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14421) Too many open file Descriptors in Wildfly-18

by Manas Panda (Jira)

[ https://issues.redhat.com/browse/WFLY-14421?page=com.atlassian.jira.plugi... ] Manas Panda commented on WFLY-14421: ------------------------------------ we are referring below java InputStream. InputStream in = Thread._currentThread_().getContextClassLoader().getResourceAsStream("/file.properties"); > Too many open file Descriptors in Wildfly-18 > -------------------------------------------- > > Key: WFLY-14421 > URL: https://issues.redhat.com/browse/WFLY-14421 > Project: WildFly > Issue Type: Task > Reporter: Manas Panda > Assignee: Brian Stansberry > Priority: Major > > In the application code deployed in wildfly10, if the fileinputstream is not closed programmatically (its a miss in the code), during the GC (G1GC) cycle, the orphan references of the opened file input streams are closed, so the number of open file descriptor is not growing. > However, after the upgrade of the wildfly10 to wildfly18, the file input streams which are not closed programmatically are not getting closed during the GC (G1GC) cycle due to which the number of open file descriptors are growing. > We agree that the input streams have to be closed programmatically in the application code which we did now, but would like to understand the reason behind this behavior change in wildfly18. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

1
0
0 / 0

[Red Hat JIRA] (WFCORE-5286) Remove deprecated javax.api usage from modules

by Boris Unckel (Jira)

Boris Unckel created WFCORE-5286: ------------------------------------ Summary: Remove deprecated javax.api usage from modules Key: WFCORE-5286 URL: https://issues.redhat.com/browse/WFCORE-5286 Project: WildFly Core Issue Type: Task Components: Modules Affects Versions: 14.0.1.Final Reporter: Boris Unckel Assignee: Richard Opalka A few modules with javax.api are still in WildFly-Core. They shall be replaced with the correct JBoss Modules/Java modules corresponding to jdeps of their jars. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

1
0
0 / 0

[Red Hat JIRA] (WFCORE-5285) Improve Fail-Fast with Objects.requireNonNull

by Boris Unckel (Jira)

[ https://issues.redhat.com/browse/WFCORE-5285?page=com.atlassian.jira.plug... ] Boris Unckel commented on WFCORE-5285: -------------------------------------- [~jmesnil] The first part - improve existing usage - is ready: [https://github.com/boris-unckel/wildfly-core/commit/b6282ebb7cc379266cd49...] What is you're oppionion to the approach? Does it conform to the overall strategy to deal with null / null checks? If you like the approach - what is your preferred way to get changes which affect classes all over the codebase? Single PR, one PR per module? > Improve Fail-Fast with Objects.requireNonNull > --------------------------------------------- > > Key: WFCORE-5285 > URL: https://issues.redhat.com/browse/WFCORE-5285 > Project: WildFly Core > Issue Type: Enhancement > Affects Versions: 14.0.1.Final > Reporter: Boris Unckel > Assignee: Jeff Mesnil > Priority: Minor > > In the current WildFly-Core code are very few cases where Objects.requireNonNull is in use, 61 occurrences. Some of them can be improved with a message ("Parameter xyz cannot be null"). > The idea is to add Objects.requireNonNull in more cases. The check shall not pollute at any place and shall occur only once (i.e. at the top of a class hierarchy for a specific attribute). > Candidates would be: > a) Constructors with object parameters without setter (single check at point of assignment to instance variable). NullPointer would raise at instantiation, not at usage. > b) Factory methods which creates objects in terms of a) > c) Public methods with two or more object parameters where null pointer would occur in the direct method code. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-13043) ManagedScheduledExecutorService keeps executing tasks after an exception is thrown

by Bartosz Baranowski (Jira)

[ https://issues.redhat.com/browse/WFLY-13043?page=com.atlassian.jira.plugi... ] Bartosz Baranowski updated WFLY-13043: -------------------------------------- Affects Version/s: 22.0.1.Final > ManagedScheduledExecutorService keeps executing tasks after an exception is thrown > ----------------------------------------------------------------------------------- > > Key: WFLY-13043 > URL: https://issues.redhat.com/browse/WFLY-13043 > Project: WildFly > Issue Type: Bug > Components: Concurrency Utilities > Affects Versions: 18.0.1.Final, 22.0.1.Final > Reporter: Vinicius Kopcheski > Assignee: Eduardo Martins > Priority: Major > > There is apparently a bug in the implementation of the ManagedScheduledExecutorService, more specifically when using the inherited method of the ScheduledExecutorService, [scheduleWithFixedDelay|https://docs.oracle.com/javase/7/docs/api/java/uti...]. On its javadoc it is stated "If any execution of the task encounters an exception, subsequent executions are suppressed.". > When [this code|https://github.com/kopcheski/managed-scheduled-executor/blob/master/...] is executed in any Wildfly from 10 to 18, the task is kept alive in the scheduler after an exception is thrown and subsequent calls will happen anyway, contradicting the javadoc. > To add evidences of a misbehavior, I did two extra checks: > 1. Running the exact same code in another JavaEE server (Payara); > 2. Using plain JavaSE with the ScheduledExecutorService. > In both cases, after an exception being thrown, subsequent executions of it are - as the javadoc states - suppressed. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-13043) ManagedScheduledExecutorService keeps executing tasks after an exception is thrown

by Bartosz Baranowski (Jira)

[ https://issues.redhat.com/browse/WFLY-13043?page=com.atlassian.jira.plugi... ] Bartosz Baranowski commented on WFLY-13043: ------------------------------------------- 11:38:46,125 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990 11:38:48,006 INFO [stdout] (EE-ManagedScheduledExecutorService-default-Thread-2) Current count is 1 11:38:50,008 INFO [stdout] (EE-ManagedScheduledExecutorService-default-Thread-1) Current count is 2 11:38:52,010 INFO [stdout] (EE-ManagedScheduledExecutorService-default-Thread-2) Current count is 3 11:38:52,010 ERROR [org.jboss.as.ee] (EE-ManagedScheduledExecutorService-default-Thread-2) WFLYEE0110: Failed to run scheduled task: java.lang.RuntimeException: Throwing exception to suppress subsequent executions. at deployment.managed-scheduled-executor.war//org.example.MyExecutor.lambda$new$0(MyExecutor.java:27) at org.jboss.as.ee@23.0.0.Beta1-SNAPSHOT//org.jboss.as.ee.concurrent.ControlPointUtils$ControlledScheduledRunnable.run(ControlPointUtils.java:178) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) at org.glassfish.javax.enterprise.concurrent//org.glassfish.enterprise.concurrent.internal.ManagedScheduledThreadPoolExecutor$ManagedScheduledFutureTask.access$201(ManagedScheduledThreadPoolExecutor.java:360) at org.glassfish.javax.enterprise.concurrent//org.glassfish.enterprise.concurrent.internal.ManagedScheduledThreadPoolExecutor$ManagedScheduledFutureTask.run(ManagedScheduledThreadPoolExecutor.java:511) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:834) at org.glassfish.javax.enterprise.concurrent//org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:227) 11:38:54,011 INFO [stdout] (EE-ManagedScheduledExecutorService-default-Thread-3) Current count is 4 11:38:54,012 ERROR [org.jboss.as.ee] (EE-ManagedScheduledExecutorService-default-Thread-3) WFLYEE0110: Failed to run scheduled task: java.lang.RuntimeException: So it should never get here. at deployment.managed-scheduled-executor.war//org.example.MyExecutor.lambda$new$0(MyExecutor.java:31) at org.jboss.as.ee@23.0.0.Beta1-SNAPSHOT//org.jboss.as.ee.concurrent.ControlPointUtils$ControlledScheduledRunnable.run(ControlPointUtils.java:178) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) at org.glassfish.javax.enterprise.concurrent//org.glassfish.enterprise.concurrent.internal.ManagedScheduledThreadPoolExecutor$ManagedScheduledFutureTask.access$201(ManagedScheduledThreadPoolExecutor.java:360) at org.glassfish.javax.enterprise.concurrent//org.glassfish.enterprise.concurrent.internal.ManagedScheduledThreadPoolExecutor$ManagedScheduledFutureTask.run(ManagedScheduledThreadPoolExecutor.java:511) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:834) at org.glassfish.javax.enterprise.concurrent//org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:227) 11:38:56,012 INFO [stdout] (EE-ManagedScheduledExecutorService-default-Thread-1) Current count is 5 11:38:58,013 INFO [stdout] (EE-ManagedScheduledExecutorService-default-Thread-4) Current count is 6 11:39:00,013 INFO [stdout] (EE-ManagedScheduledExecutorService-default-Thread-2) Current count is 7 11:39:02,014 INFO [stdout] (EE-ManagedScheduledExecutorService-default-Thread-5) Current count is 8 11:39:04,015 INFO [stdout] (EE-ManagedScheduledExecutorService-default-Thread-3) Current count is 9 11:39:06,016 INFO [stdout] (EE-ManagedScheduledExecutorService-default-Thread-6) Current count is 10 11:39:08,016 INFO [stdout] (EE-ManagedScheduledExecutorService-default-Thread-1) Current count is 11 11:39:10,017 INFO [stdout] (EE-ManagedScheduledExecutorService-default-Thread-7) Current count is 12 11:39:12,018 INFO [stdout] (EE-ManagedScheduledExecutorService-default-Thread-4) Current count is 13 11:39:14,018 INFO [stdout] (EE-ManagedScheduledExecutorService-default-Thread-8) Current count is 14 11:39:16,019 INFO [stdout] (EE-ManagedScheduledExecutorService-default-Thread-2) Current count is 15 > ManagedScheduledExecutorService keeps executing tasks after an exception is thrown > ----------------------------------------------------------------------------------- > > Key: WFLY-13043 > URL: https://issues.redhat.com/browse/WFLY-13043 > Project: WildFly > Issue Type: Bug > Components: Concurrency Utilities > Affects Versions: 18.0.1.Final > Reporter: Vinicius Kopcheski > Assignee: Eduardo Martins > Priority: Major > > There is apparently a bug in the implementation of the ManagedScheduledExecutorService, more specifically when using the inherited method of the ScheduledExecutorService, [scheduleWithFixedDelay|https://docs.oracle.com/javase/7/docs/api/java/uti...]. On its javadoc it is stated "If any execution of the task encounters an exception, subsequent executions are suppressed.". > When [this code|https://github.com/kopcheski/managed-scheduled-executor/blob/master/...] is executed in any Wildfly from 10 to 18, the task is kept alive in the scheduler after an exception is thrown and subsequent calls will happen anyway, contradicting the javadoc. > To add evidences of a misbehavior, I did two extra checks: > 1. Running the exact same code in another JavaEE server (Payara); > 2. Using plain JavaSE with the ScheduledExecutorService. > In both cases, after an exception being thrown, subsequent executions of it are - as the javadoc states - suppressed. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

1
0
0 / 0

[Red Hat JIRA] (WFCORE-5285) Improve Fail-Fast with Objects.requireNonNull

by Boris Unckel (Jira)

Boris Unckel created WFCORE-5285: ------------------------------------ Summary: Improve Fail-Fast with Objects.requireNonNull Key: WFCORE-5285 URL: https://issues.redhat.com/browse/WFCORE-5285 Project: WildFly Core Issue Type: Enhancement Affects Versions: 14.0.1.Final Reporter: Boris Unckel Assignee: Jeff Mesnil In the current WildFly-Core code are very few cases where Objects.requireNonNull is in use, 61 occurrences. Some of them can be improved with a message ("Parameter xyz cannot be null"). The idea is to add Objects.requireNonNull in more cases. The check shall not pollute at any place and shall occur only once (i.e. at the top of a class hierarchy for a specific attribute). Candidates would be: a) Constructors with object parameters without setter (single check at point of assignment to instance variable). NullPointer would raise at instantiation, not at usage. b) Factory methods which creates objects in terms of a) c) Public methods with two or more object parameters where null pointer would occur in the direct method code. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14424) Add EJB client test case for interacting with two non-overlapping clusters

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-14424?page=com.atlassian.jira.plugi... ] Radoslav Husar commented on WFLY-14424: --------------------------------------- I would recommend starting with {{org.jboss.as.test.clustering.cluster.ejb.forwarding.AbstractRemoteEJBForwardingTestCase}} which already configured two clusters and see how much that can be generalized and reused. > Add EJB client test case for interacting with two non-overlapping clusters > --------------------------------------------------------------------------- > > Key: WFLY-14424 > URL: https://issues.redhat.com/browse/WFLY-14424 > Project: WildFly > Issue Type: Task > Components: Clustering > Affects Versions: 22.0.0.Final > Reporter: Richard Achmatowicz > Assignee: Richard Achmatowicz > Priority: Major > Fix For: 23.0.0.Beta1 > > > Write a test case which shows: > * how to configure two non-overlapping clusters > * how to specify the cluster affinity value which will be generated by the cluster for use in topology updates > * the creation of EJB client proxies which can interact with those clusters via the cluster specification > * creation of proxies using EJBClient API and JNDI lookup for both stateful and stateless bean deployments -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

1
0
0 / 0

[Red Hat JIRA] (DROOLS-6018) Enable exec-model for moved tests in drools-test-coverage

by Toshiya Kobayashi (Jira)

Toshiya Kobayashi created DROOLS-6018: ----------------------------------------- Summary: Enable exec-model for moved tests in drools-test-coverage Key: DROOLS-6018 URL: https://issues.redhat.com/browse/DROOLS-6018 Project: Drools Issue Type: Task Components: executable model Affects Versions: 7.49.0.Final Reporter: Toshiya Kobayashi Assignee: Toshiya Kobayashi DROOLS-5972 and DROOLS-6017 moved/moves unit tests from drools-mvel but these tests are still tested only for standard-drl. This JIRA is to ensure those moved tests to be run against exec-model so we can enhance the test coverage. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

1
0
0 / 0

[Red Hat JIRA] (DROOLS-6017) Move test cases from drools-mvel to drools-test-coverage : 3rd round

by Toshiya Kobayashi (Jira)

Toshiya Kobayashi created DROOLS-6017: ----------------------------------------- Summary: Move test cases from drools-mvel to drools-test-coverage : 3rd round Key: DROOLS-6017 URL: https://issues.redhat.com/browse/DROOLS-6017 Project: Drools Issue Type: Task Components: core engine, executable model Affects Versions: 7.49.0.Final Reporter: Toshiya Kobayashi Assignee: Toshiya Kobayashi DROOLS-5972 moved most of CommonTestMethodBase based tests (81 tests) from drools-mvel to drools-test-coverage. This JIRA is to evaluate remaining tests in drools-mvel and probably some DRL based tests can be moved to drools-test-coverage. Also we may discuss where the other tests should be moved to. (DROOLS-5866 will move some of them) -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 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 February 2021