Would it be a feasible request long term to have that functionality baked into jmeter itself, rather than an external script?
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] > >
