October 2014 - arquillian-issues - Jboss List Archives

[JBoss JIRA] (ARQ-1865) Undeploy arquillian bundle after the test suite in JMXDeployableContainer

by Martin Basovnik (JIRA)

[ https://issues.jboss.org/browse/ARQ-1865?page=com.atlassian.jira.plugin.s... ] Martin Basovnik updated ARQ-1865: --------------------------------- Status: Pull Request Sent (was: Pull Request Sent) Git Pull Request: https://github.com/arquillian/arquillian-container-osgi/pull/32, https://github.com/arquillian/arquillian-container-osgi/pull/33 (was: https://github.com/arquillian/arquillian-container-osgi/pull/32) > Undeploy arquillian bundle after the test suite in JMXDeployableContainer > ------------------------------------------------------------------------- > > Key: ARQ-1865 > URL: https://issues.jboss.org/browse/ARQ-1865 > Project: Arquillian > Issue Type: Bug > Components: OSGi Containers > Reporter: Martin Basovnik > > Undeploy arquillian bundle after the test suite in JMXDeployableContainer -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1870) Method KarafRemoteContainerConfiguration.validate() does not call super method

by Martin Basovnik (JIRA)

[ https://issues.jboss.org/browse/ARQ-1870?page=com.atlassian.jira.plugin.s... ] Martin Basovnik updated ARQ-1870: --------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-container-osgi/pull/34, https://github.com/arquillian/arquillian-container-osgi/pull/35 > Method KarafRemoteContainerConfiguration.validate() does not call super method > ------------------------------------------------------------------------------ > > Key: ARQ-1870 > URL: https://issues.jboss.org/browse/ARQ-1870 > Project: Arquillian > Issue Type: Bug > Components: OSGi Containers > Reporter: Martin Basovnik > Assignee: Thomas Diesler > > Method {{KarafRemoteContainerConfiguration.validate()}} does not call super method. > Neither {{JMXContainerConfiguration.validate()}} nor {{CommonContainerConfiguration.validate()}} is called. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1870) Method KarafRemoteContainerConfiguration.validate() does not call super method

by Martin Basovnik (JIRA)

Martin Basovnik created ARQ-1870: ------------------------------------ Summary: Method KarafRemoteContainerConfiguration.validate() does not call super method Key: ARQ-1870 URL: https://issues.jboss.org/browse/ARQ-1870 Project: Arquillian Issue Type: Bug Components: OSGi Containers Reporter: Martin Basovnik Assignee: Thomas Diesler Method {{KarafRemoteContainerConfiguration.validate()}} does not call super method. Neither {{JMXContainerConfiguration.validate()}} nor {{CommonContainerConfiguration.validate()}} is called. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1869) Adds overwrite flag to DownloadTool

by Alex Soto (JIRA)

Alex Soto created ARQ-1869: ------------------------------ Summary: Adds overwrite flag to DownloadTool Key: ARQ-1869 URL: https://issues.jboss.org/browse/ARQ-1869 Project: Arquillian Issue Type: Feature Request Components: Extension - Spacelift Reporter: Alex Soto Assignee: Alex Soto Priority: Minor Adds overwrite flag to DownloadTool. By default the flag will be true for back compatibility, but if is set to false and the archive is already downloaded, then the file will not be downloaded. Related with https://github.com/arquillian/arquillian-spacelift/issues/14 -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1868) JVM waits for Spacelift's cached threads to timeout causing its termination delay

by Stefan Miklosovic (JIRA)

[ https://issues.jboss.org/browse/ARQ-1868?page=com.atlassian.jira.plugin.s... ] Stefan Miklosovic updated ARQ-1868: ----------------------------------- Attachment: spacelift_thread_dump.txt > 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 > 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 (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1868) JVM waits for Spacelift's cached threads to timeout causing its termination delay

by Stefan Miklosovic (JIRA)

[ https://issues.jboss.org/browse/ARQ-1868?page=com.atlassian.jira.plugin.s... ] Stefan Miklosovic commented on ARQ-1868: ---------------------------------------- I have tripple checked that the thread which needs to be timeouted does not hold any file descriptors to be closed and so on ... thread dump while it is hanging confirms my theory and jvisualvm proofs. Beer on me if you proof me to be wrong :) > 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)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1868) JVM waits for Spacelift's cached threads to timeout causing its termination delay

by Stefan Miklosovic (JIRA)

[ 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)

10 years, 2 months

1
0
0 / 0

[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: ---------------------------------- Not sure if I understand the issue. Is that about JVM shutdown taking extra 60 seconds? > 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)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ARQGRA-463) JavaScript resource loader should use JavaScript.class.getClassLoader()

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQGRA-463?page=com.atlassian.jira.plugin... ] Lukáš Fryč updated ARQGRA-463: ------------------------------ Fix Version/s: 2.1.0.Alpha2 > JavaScript resource loader should use JavaScript.class.getClassLoader() > ----------------------------------------------------------------------- > > Key: ARQGRA-463 > URL: https://issues.jboss.org/browse/ARQGRA-463 > Project: Arquillian Graphene > Issue Type: Enhancement > Affects Versions: 2.0.3.Final, 2.1.0.Alpha1 > Reporter: Lukáš Fryč > Fix For: 2.1.0.Alpha2 > > > It uses ClassLoader.getSystemResourceAsStream(resourceName); -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ARQGRA-463) JavaScript resource loader should use JavaScript.class.getClassLoader()

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQGRA-463?page=com.atlassian.jira.plugin... ] Lukáš Fryč commented on ARQGRA-463: ----------------------------------- https://github.com/arquillian/arquillian-graphene/commit/755f1718ab8cefa1... > JavaScript resource loader should use JavaScript.class.getClassLoader() > ----------------------------------------------------------------------- > > Key: ARQGRA-463 > URL: https://issues.jboss.org/browse/ARQGRA-463 > Project: Arquillian Graphene > Issue Type: Enhancement > Affects Versions: 2.0.3.Final, 2.1.0.Alpha1 > Reporter: Lukáš Fryč > Fix For: 2.1.0.Alpha2 > > > It uses ClassLoader.getSystemResourceAsStream(resourceName); -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

arquillian-issues October 2014