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 17:10:54 GMT
On 10 July 2012 17:49, Nicholas Jasieniecki <nastharl@gmail.com> 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 <sebbaz@gmail.com> wrote:
>
>> 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
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org


Mime
View raw message