On 10 July 2012 17:49, Nicholas Jasieniecki <[email protected]> wrote: > Would it be a feasible request long term to have that functionality baked > into jmeter itself, rather than an external script?
The stoptest/shutdown functionality is already in JMeter. The stoptest script is just a means of triggering it remotely. For tests that are started from the command-line, it's obviously necessary to do it this way. For tests that are run embedded, the application can call the method StandardJMeterEngine.stopEngineNow() Or indeed the calling application can just call System.exit() itself. > On Tue, Jul 10, 2012 at 11:46 AM, sebb <[email protected]> wrote: > >> On 10 July 2012 17:11, Nicholas Jasieniecki <[email protected]> wrote: >> > Greetings! >> > >> > Has anyone else run into this issue? >> > >> > I'm running jmeter using a command line (java –jar) invoked by gradle. >> Its >> > a stupid system but I cant really change it at the moment. The problem >> I'm >> > having is that for some tests, when they end I get a message saying >> > >> > >> > The JVM should have exitted but did not. >> > >> > The following non-daemon threads are still running (DestroyJavaVM is OK): >> > >> > Thread[DestroyJavaVM,5,main], stackTrace: >> > >> > Thread[pool-7-thread-1,5,main], stackTrace:sun.misc.Unsafe#park >> > >> > java.util.concurrent.locks.LockSupport#park at line:156 >> > >> > >> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject#await >> > at line:1987 >> > >> > java.util.concurrent.LinkedBlockingQueue#take at line:399 >> > >> > java.util.concurrent.ThreadPoolExecutor#getTask at line:947 >> > >> > java.util.concurrent.ThreadPoolExecutor$Worker#run at line:907 >> > >> > java.lang.Thread#run at line:680 >> > >> > >> > Thread[pool-6-thread-1,5,main], stackTrace:sun.misc.Unsafe#park >> > >> > java.util.concurrent.locks.LockSupport#parkNanos at line:196 >> > >> > java.util.concurrent.SynchronousQueue$TransferStack#awaitFulfill at >> line:424 >> > >> > java.util.concurrent.SynchronousQueue$TransferStack#transfer at line:323 >> > >> > java.util.concurrent.SynchronousQueue#poll at line:874 >> > >> > java.util.concurrent.ThreadPoolExecutor#getTask at line:945 >> > >> > java.util.concurrent.ThreadPoolExecutor$Worker#run at line:907 >> > >> > java.lang.Thread#run at line:680 >> > >> > >> > I'm not sure whether these are threads created by my test case (launches >> a >> > spring container via beanshell and calls some remote java services), or >> by >> > jmeter itself. >> > >> >> Does not look like the sort of threads created by JMeter. >> >> > Is there a way to force jmeter to kill the JVM? >> >> Run the stoptest script. >> If this fails to kill the threads it will call System.exit(1) by default. >> >> Note: this can be overridden by defining the JMeter property >> >> jmeterengine.stopfail.system.exit=false >> >> > My backup plan up until now >> > has been to set a timeout longer than the duration of the test and then >> > tell the build system to kill the process it spawned (the jmeter >> process). >> > This isn't really sustainable long term, and I'm trying to see if there >> is >> > any better way around the issue. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
