1:58 a.m.
[
https://issues.jboss.org/browse/WFLY-11328?page=com.atlassian.jira.plugin...
]
Jiri Ondrusek edited comment on WFLY-11328 at 11/14/18 2:57 AM:
----------------------------------------------------------------
[~emmartins] Thank you for your analysis.
Comment belonging to current PR:
ad 1 - I think that synchronization could be omitted without any impact, additions to list
are called typically at server startup, iteration is called after 1 minute and then
periodically, so there should be no conflict
ad 2 - 10 seconds is really low value, originally I was using 1 minute - but with last
change, I've accidentally commited also this change (which is my ebg value). -> so
10 sec as mistake from my side, there should be 1 minute - which should be OK (as you are
suggesting it in b)
I agree that killing threads is rather strict. I can imagine logging some warnings for
user to know about hung treads as you are suggesting in b. But you last comment shows,
that in some cases, this threshold could be reconfigured to different values -> so even
logging will happen in wrong times.
From my point of view, much easier and consistent behavior will be
item *a*.
was (Author: jondruse):
[~emmartins] Thank you for your analysis.
Comment belonging to current PR:
ad 1 - I think that synchronization could be omitted without any impact, additions to list
are called typically at server startup, iteration is called after 1 minute and then
periodically, so there should be no conflict
ad 2 - 10 seconds is really low value, originally I was using 1 minute - but with last
change, I've accidentally commited also this change (which is my ebg value). -> so
10 sec as mistake from my side, there should be 1 minute - which should be OK (as you are
suggesting it in b)
I agree that killing threads is rather strict. I can imagine logging some warnings for
user to know about hung treads as you are suggesting in b. But you last comment shows,
that in some cases, this threshold could be reconfigured to different values -> so even
logging will happen in wrong times.
From my point of view, much easier and consistent behavior will be
item *a*.
@Masafumi Miura (reporter of the original issue -
https://issues.jboss.org/browse/JBEAP-13778) What do you think?
EE Concurency Utilities "hung-task-threshold" /
"long-running-tasks" do not work and are not implemented as explained
---------------------------------------------------------------------------------------------------------------------
Key: WFLY-11328
URL: https://issues.jboss.org/browse/WFLY-11328
Project: WildFly
Issue Type: Bug
Components: EE
Reporter: Jiri Ondrusek
Assignee: Jiri Ondrusek
Priority: Major
ee subsystem parameters "hung-task-threshold" and
"long-running-tasks" for managed-executor-service /
managed-scheduled-executor-service do not work and are not implemented as described in
[EAP 7 Development
Guide|https://access.redhat.com/documentation/en-us/red_hat_jboss_enterpr...]:
- hung-task-threshold: Defines the time, in milliseconds, after which tasks are
considered hung by the managed executor service and forcefully aborted. If the value is 0
(which is the default), tasks are never considered hung.
- long-running-tasks: Suggests optimizing the execution of long running tasks, and
defaults to false.
I tested with [EAP 7 QuickStarts managed-executor-service
example|https://github.com/jboss-developer/jboss-eap-quickstarts/tree/7.0...]
but these paremeters doe not take any effect:
- tasks exceeding hung-task-threshold are never forcefully aborted. And there's no
way to detect hung tasks exceeding hung-task-threshold.
- setting long-running-tasks to true does not change the behavior.
As far as I checked the source code, I noticed the following:
- EAP 7.x uses the EE Concurency Utilities RI
[org.glassfish.enterprise.concurrent|https://github.com/javaee/cu-ri] internally and just
passes the paramters to the RI.
- In the EE Concurency Utilities RI, these parameters are used in the methods
[ManagedThreadFactoryImpl#isTaskHung(long
now)|https://github.com/javaee/cu-ri/blob/master/src/main/java/org/glassf...],
[AbstractManagedExecutorService#getHungThreads()|https://github.com/javaee...]
and
[AbstractManagedExecutorService#isLongRunningTasks()|https://github.com/ja...]
(AbstractManagedExecutorService is the parent class of ManagedExecutorServiceImpl /
ManagedScheduledExecutorServiceImpl).
- However, these methods are never invoked from EAP 7.x. So, these parameters do not
take any effect in EAP 7.x.
- In addition, even if these methods are used, it looks the implementation is totally
different from the description in the documentation. The parameter
"long-running-tasks" is just used as a flag to skip from checking hung thread
detection. And the parameter "hung-task-threshold" never forcefully abort the
hung thread exceeding the threshold.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)