AFAIK, Green threads have been replaced/superseded by native OS threads since version 1.2... And the native OS threading now used has solved the reliability (well, some anyway) issues.
Now: We're experiencing the same problem here - our platform is as follows: testing a JSP based app on a WAS v5 server linking to an AS/400 RPG back end; with 9 remote agents for the stress tests (currently running around 10 threads/agent). We've done some investigation and for us it turns out that the threads were hanging in the appserver: like you this was only experienced when using a thread count in the hundreds - which is awkward as that's only a thread count of 11 if, like us, you have 9 remote agents. Considering each box is a dual 4ghz/5gb ram etc. that's quite annoying! We're going to add dealys/waits to 'ape' human interraction, anyway, so with any luck this may solve the problem as they're going to be random timings - will let you know. Not sure if this [websphere etc] is another red-herring, however. Watch this space I guess? Glad we're not alone ;-) Cheers, Al. git wrote: > > 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 > > > > > -- View this message in context: http://www.nabble.com/Thread-won%27t-die-issue-tf3059035.html#a8845300 Sent from the JMeter - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
