[JBoss JIRA] (ARQ-2061) Upgrade to Selenium 3
by Matous Jobanek (JIRA)
Matous Jobanek created ARQ-2061:
-----------------------------------
Summary: Upgrade to Selenium 3
Key: ARQ-2061
URL: https://issues.jboss.org/browse/ARQ-2061
Project: Arquillian
Issue Type: Component Upgrade
Components: Extension - Drone
Affects Versions: drone_2.0.1.Final
Reporter: Matous Jobanek
Assignee: Matous Jobanek
Fix For: drone_3.0.0.Alpha1
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month
[JBoss JIRA] (ARQ-1868) JVM waits for Spacelift's cached threads to timeout causing its termination delay
by Matous Jobanek (JIRA)
[ https://issues.jboss.org/browse/ARQ-1868?page=com.atlassian.jira.plugin.s... ]
Matous Jobanek commented on ARQ-1868:
-------------------------------------
Hi, to be honest, I haven't faced this issue in any project (where Spacelift is used) yet; so from my point of view it can be closed.
> 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
> Attachments: spacelift_thread_dump.txt
>
>
> 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
(v7.2.3#72005)
8 years, 1 month
[JBoss JIRA] (ARQ-1868) JVM waits for Spacelift's cached threads to timeout causing its termination delay
by Karel Piwko (JIRA)
[ https://issues.jboss.org/browse/ARQ-1868?page=com.atlassian.jira.plugin.s... ]
Karel Piwko commented on ARQ-1868:
----------------------------------
[~mjobanek] [~smikloso] do we still need this issue to be fixed? Otherwise I suggest to close it as won't fix / out of date.
> 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
> Attachments: spacelift_thread_dump.txt
>
>
> 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
(v7.2.3#72005)
8 years, 1 month
[JBoss JIRA] (ARQ-1868) JVM waits for Spacelift's cached threads to timeout causing its termination delay
by Karel Piwko (JIRA)
[ https://issues.jboss.org/browse/ARQ-1868?page=com.atlassian.jira.plugin.s... ]
Karel Piwko reassigned ARQ-1868:
--------------------------------
Assignee: (was: Karel Piwko)
> 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
> Attachments: spacelift_thread_dump.txt
>
>
> 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
(v7.2.3#72005)
8 years, 1 month