[arquillian-issues] [JBoss JIRA] (ARQ-1868) JVM waits for Spacelift's cached threads to timeout causing its termination delay
[
https://issues.jboss.org/browse/ARQ-1868?page=com.atlassian.jira.plugin.s...
]
Stefan Miklosovic commented on ARQ-1868:
----------------------------------------
Basically yes. When I use ExecutorSevice and put there callables, these are executed but
underlying thread(s) which run them are not stopped immediately but they are cached so
that mean even whole program is at its end and has nothing else to do, for JVM, in order
to be stopped, it has to wait for that cached thread to timeout.
JVM waits for Spacelift's cached threads to timeout causing its
termination delay
---------------------------------------------------------------------------------
Key: ARQ-1868
URL: https://issues.jboss.org/browse/ARQ-1868
Project: Arquillian
Issue Type: Bug
Components: Extension - Spacelift
Affects Versions: spacelift_1.0.0.Alpha2
Reporter: Stefan Miklosovic
Assignee: Karel Piwko
In the current implementation of ExecutorService there is this constructor:;
{code}
public ExecutionServiceImpl() {
this.service = Executors.newCachedThreadPool();
this.scheduledService = Executors.newScheduledThreadPool(1);
}
{code}
JavaDoc for cachedThreadPool says:
{quote}
Threads that have not been used for sixty seconds are terminated and removed from the
cache. Thus, a pool that remains idle for long enough will not consume any resources.
{quote}
While this is indeed useful, it seems that even JVM has nothing to do, it waits for these
cached threads to timeout (so they are not used some time (60 seconds by default) so they
are destroyed eventually) and only after their destruction whole JVM terminates properly.
Please consider to lower the timeout so user does not have to wait or figure out other
pooling mechanism.
This issue effects mainly command line tools which hangs without obvious reason and
debugging it why is a nightmare.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)