jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Issue with threads not closing
Date Tue, 10 Jul 2012 16:46:09 GMT
On 10 July 2012 17:11, Nicholas Jasieniecki <nastharl@gmail.com> 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: user-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org


Mime
View raw message