jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicholas Jasieniecki <nasth...@gmail.com>
Subject Re: Issue with threads not closing
Date Tue, 10 Jul 2012 16:49:27 GMT
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 <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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message