Daniel, I would doubt that the thread.stop would cause any trouble anyway as it is caused by possible deadlocking between interdependent threads. Back in the late nineties when I first started messing with Java Threads was about the same time that native threads came in. Back the you could tell the JVM to use green threads (non native) or native. Under very heavy thread load, green threads were more stable.
But - that was 8 years ago - and things have moved on. I have no idea if you can even use green threads any more. Cheers AJ On Mon, 2007-01-29 at 12:17 -0600, Daniel Kurtz wrote: > AJ; > > Well, as I mentioned the best that we've been able to work out so far is to > just limit the number of threads you run on one agent. Our target is > ultimately 500 users, and we're just going use 5 100-user agents to get > there, for this round at least. > > I'm not a Java developer, but I had a look at the source to see what's going > on when the "thread won't die" is being logged and found the thread.stop. I > thought I might have stumbled on something when I read in the Java reference > that thread.stop is considered unsafe and shouldn't be used any more. But in > looking further I've realized that this isn't where the failure's occurring. > These threads are already toast at this point. They're so toasty the > thread.stop can't even kill them, which is why JMeter throws the message. > > Daniel Kurtz > > > ________________________________ > > From: git [mailto:[EMAIL PROTECTED] > Sent: Mon 1/29/2007 10:25 AM > To: JMeter Users List > Subject: RE: Thread won't die issue > > > > Daniel, > > I've seen this - but have no idea what causes it or what to do about it! > > You're not being ignored... > > Cheers > > AJ > > On Mon, 2007-01-29 at 09:40 -0600, Daniel Kurtz wrote: > > > Well, since no one responded to this I guess that no one else is seeing it. > > What we're seeing here is that the threads are actually dying in some way. > > They stop returning samples and for all practical intents and purposes are > > 'hung' after that point. When we issue the 'stop' from the console, JMeter > > sees all these threads still running and issues a thread.stop command for > > each. It comes back a little later to each thread to see if it has, indeed, > > stopped. It hasn't, so JMeter returns the "thread won't die" message. > > > > What we've found is that, on any of the hardware we've tried it on (which > > represents a pretty broad range of capabilities) this appears to be related > > to an upper threshold on the number of threads that can be run per agent. I > > place the figure at about 150, though for safety's sake we're recommending > > to our users that they try not to go above 100 threads per agent. That > > includes the console itself when running local tests. > > > > Daniel Kurtz > > > > > > ________________________________ > > > > From: Daniel Kurtz [mailto:[EMAIL PROTECTED] > > Sent: Mon 1/22/2007 11:10 AM > > To: [email protected] > > Subject: Thread won't die issue > > > > > > > > We find that invariably we end up with more or less a number of threads > > that don't go into an 'ending' status. Of course the test itself does not > > end in these circumstances, but will just hang out there forever. When we > > force a stop from the console, the end of jmeter.log ends up looking like: > > > > ... > > 2007/01/22 10:52:44 INFO - jmeter.threads.JMeterThread: Thread Thread Group > > 1-500 is done > > > > 2007/01/22 10:52:44 INFO - jmeter.engine.StandardJMeterEngine: Ending > > thread 499 > > > > 2007/01/22 10:59:10 INFO - jmeter.threads.JMeterThread: Stopping Thread > > Group 1-271 > > > > 2007/01/22 10:59:15 INFO - jmeter.engine.StandardJMeterEngine: Thread won't > > die: Thread Group 1-271 > > > > 2007/01/22 10:59:15 INFO - jmeter.engine.StandardJMeterEngine: Notifying > > test listeners of end of test > > > > 2007/01/22 10:59:15 INFO - jmeter.gui.util.JMeterMenuBar: > > setRunning(false,local) > > > > 2007/01/22 10:59:15 INFO - jmeter.engine.StandardJMeterEngine: Test has > > ended > > > > Suggestions as to what we should look at to resolve this? > > > > Thanks. > > > > Daniel Kurtz > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > www.cubicalland.com > www.nerds-central.blogspot.com > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] www.cubicalland.com www.nerds-central.blogspot.com
