[Red Hat JIRA] (WFLY-13043) ManagedScheduledExecutorService keeps executing tasks after an exception is thrown
4:40 a.m.
[
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)
1982
days inactive
1982
days old
0 comments
1 participants
participants (1)
-
Bartosz Baranowski (Jira)