RE: Thread won't die issue
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: jmeter-user@jakarta.apache.org 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 -
JMeterMonitor Results for WebLogic 9.1,JBoss 4.0.X
Hi, We are trying to configure Monitor Results for our Web Application JPetstore.war deployed with JBOss 4.0.5 and WebLogic 9.1 appservers. We were able to successfully configure. But when we try to run the application,The Health Tab shows Status as DEAD. Is there any other configuration required to be made to get the Monitor Results.Can you please help us in this regard and suggest us any documents/links for the same. Your quick response is appreciated. Thanks in advance, :-)
Default request parameters wrapped up in multipart
Hi all I have a HTTPRequest POST which is attempting to upload a file to my server. It seems that when I define a file to be sent with the POST, JMeter is wrapping up my default request parameters in the multipart section of the post. This is causing the upload to fail. Any ideas if this is by design or a bug. If the latter is there a known workaround? Thanks, Stuart - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Default request parameters wrapped up in multipart
I should add that the default parameters are not needed in the POST as they in the URL so a possible workaround would be to disable the default parameters from this post if possible. Stuart Findlay wrote: Hi all I have a HTTPRequest POST which is attempting to upload a file to my server. It seems that when I define a file to be sent with the POST, JMeter is wrapping up my default request parameters in the multipart section of the post. This is causing the upload to fail. Any ideas if this is by design or a bug. If the latter is there a known workaround? Thanks, Stuart - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Default request parameters wrapped up in multipart
As a work-round, try adding the parameters to the path instead. On 07/02/07, Stuart Findlay [EMAIL PROTECTED] wrote: I should add that the default parameters are not needed in the POST as they in the URL so a possible workaround would be to disable the default parameters from this post if possible. Stuart Findlay wrote: Hi all I have a HTTPRequest POST which is attempting to upload a file to my server. It seems that when I define a file to be sent with the POST, JMeter is wrapping up my default request parameters in the multipart section of the post. This is causing the upload to fail. Any ideas if this is by design or a bug. If the latter is there a known workaround? Thanks, Stuart - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Default request parameters wrapped up in multipart
Yes that's what I tried but because they're defined in the defaults then they still get wrapped in the multipart. Would my only option be to remove them from the defaults? sebb wrote: As a work-round, try adding the parameters to the path instead. On 07/02/07, Stuart Findlay [EMAIL PROTECTED] wrote: I should add that the default parameters are not needed in the POST as they in the URL so a possible workaround would be to disable the default parameters from this post if possible. Stuart Findlay wrote: Hi all I have a HTTPRequest POST which is attempting to upload a file to my server. It seems that when I define a file to be sent with the POST, JMeter is wrapping up my default request parameters in the multipart section of the post. This is causing the upload to fail. Any ideas if this is by design or a bug. If the latter is there a known workaround? Thanks, Stuart - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Stuart Findlay Senior QA Engineer - Stability Critical Path Critical Path Ireland 42-47, Lower Mount St., Dublin 2, Ireland Phone: +353 1 241 5000 Fax:+353 1 241 5170 Yahoo IM: stufindlay www.criticalpath.net http://www.criticalpath.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jmeter mail sampler QA
Anyone out there know how to increase the logging of my error so that i get
a StackTrace on this err.toString() from JMeter. It should be a
printStackTrace(errorfiles) I think but its not.
Sample Start: Tue Feb 06 13:06:15 PST 2007
Load time: 47
HTTP response code: 500
HTTP response message: java.io.IOException : Unknown encoding:
I turned on all the debugs but I cant get the stackTrace, pls send help.
./b
On 2/6/07, Mr. B Obst [EMAIL PROTECTED] wrote:
I would like to debug my errors, can anyone show me a way to see more
logs, or enable more logging, or re-direct the output of error messages FULL
to the console, or files.
I want the full errors, from my IMAP problem, so that I can see if the
Java.IO exception is a getStream or close, or die or whatever method is
failing. I can only look so much at the network traffic. I know the port is
being clobbered, but how?
Thank you in advance,
./b
On 2/6/07, Mr. B Obst [EMAIL PROTECTED] wrote:
Please suggest a method to increase my ability to troubleshoot this
error.
/b
On 2/6/07, sebb [EMAIL PROTECTED] wrote:
Yes it does work, but not all test elements have debugging in them.
On 06/02/07, Mr. B Obst [EMAIL PROTECTED] wrote:
Actually, does the GUI--Help--Enable Debug actually have any
effect? If
so what is it?
On 2/6/07, Mr. B Obst [EMAIL PROTECTED] wrote:
Here is the web documentation to which I was referring when I
said,
vague, what I meant was too vague, and seemingly inconsistent.
For me
this information is not detailed enough to understand how the
following
debug options are used. In the following examples;
{argument}={value} and e.g. jorphan=INFO or
jmeter.util=DEBUGjmeter-LDEBUG
* I was unable to set options with that data as I do not know
enough where
to find such debug magic variables information. Additionally they
do not
match up to the previous example and there is no list of supported
options
or arguments linked to there either.
page --
http://jakarta.apache.org/jmeter/usermanual/get-started.html
* 2.4.5 Overriding Properties Via The Command Line*
jmeter -Duser.dir=/home/mstover/jmeter_stuff \
-Jremote_hosts=
127.0.0.1 -Ljmeter.engine=DEBUG
jmeter -LDEBUG
2.4.7 Full list of command-line options
-L, --loglevel {argument}={value}
Define loglevel: [category=]level
e.g. jorphan=INFO or jmeter.util=DEBUG
**
On 2/6/07, Mr. B Obst [EMAIL PROTECTED] wrote:
Ok that is good to know that its not a HTTP error.
I have run this configuration on various machines, so I know its
not the
hardware anymore.
I know there is a debug mode under help. But how to I extend the
logging? I have read many pages of docs, but they are too vague
to get this
setting to push the real java.io exception to a log file or
screen.
1170802459721,62,Mail Reader Sampler,500, java.io.IOException:
Unknown
encoding: ,Thread Group 1-1,,false
Thats the only log I get. Its impossible to tell where the IO
method
that failed is. How can I get the logging?
thanks again,
./b
On 2/6/07, sebb [EMAIL PROTECTED] wrote:
JMeter often reports errors as HTTP even though they aren't -
it
started as an HTTP test tool and grew...
As far as I know the packet checksum errors are nothing to do
with
JMeter or even Java; they are generated at a much lower level.
Perhaps there is a network problem or hardware fault on the
ethernet
card.
On 06/02/07, Mr. B Obst [EMAIL PROTECTED] wrote:
Error
--
Thread Name: Thread Group 1-1
Sample Start: Tue Feb 06 13:06:15 PST 2007
Load time: 47
HTTP response code: 500
HTTP response message: java.io.IOException : Unknown
encoding:
HTTP response headers:
On 2/6/07, Mr. B Obst [EMAIL PROTECTED] wrote:
Thanks Sebb,
I have tried the suggested methods and there are a few
things now;
Packets
--
- JMeter Reports Http Errors? This is IMAP, why do i get
an HTTP
500.
Once this error is reported JMeter stops, but there is no
HTTP
trafic in the
packet sniff. IMAP Connection Left Abandon.
- EtherReal packet analysis indicates ALL the ACK packets
from
JMeter have
invalid checksum errors.
Real Clients
-
- ThunderBird/Outlooks works properly with our goodserver
IMAP,
and with
debug options enabled, there are no errors/warnings
Please Advise,
.b
Packet Trace
---
available upon request
Re: Default request parameters wrapped up in multipart
If by defaults, you mean that you have an HTTP Request Defaults Configuration element in scope, then yes, you will have to ensure that it is no longer in scope. You may be able to do this by judicious use of an extra Simple Controller - put the Defaults there, as well as all the samplers that need them. But that may just make the test plan horribly complicated... You could also file a Bugzilla enhancement request, but that will take rather longer, though still worth doing ... S. On 07/02/07, Stuart Findlay [EMAIL PROTECTED] wrote: Yes that's what I tried but because they're defined in the defaults then they still get wrapped in the multipart. Would my only option be to remove them from the defaults? sebb wrote: As a work-round, try adding the parameters to the path instead. On 07/02/07, Stuart Findlay [EMAIL PROTECTED] wrote: I should add that the default parameters are not needed in the POST as they in the URL so a possible workaround would be to disable the default parameters from this post if possible. Stuart Findlay wrote: Hi all I have a HTTPRequest POST which is attempting to upload a file to my server. It seems that when I define a file to be sent with the POST, JMeter is wrapping up my default request parameters in the multipart section of the post. This is causing the upload to fail. Any ideas if this is by design or a bug. If the latter is there a known workaround? Thanks, Stuart - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Stuart Findlay Senior QA Engineer - Stability Critical Path Critical Path Ireland 42-47, Lower Mount St., Dublin 2, Ireland Phone: +353 1 241 5000 Fax:+353 1 241 5170 Yahoo IM: stufindlay www.criticalpath.net http://www.criticalpath.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMeterMonitor Results for WebLogic 9.1,JBoss 4.0.X
did you make sure to send the right parameters to jboss? for it to work, you need to have XML=true in the request parameters. if you're passing that, look in the server logs to see if there's any errors. peter On 2/7/07, nisha yadav [EMAIL PROTECTED] wrote: Hi, We are trying to configure Monitor Results for our Web Application JPetstore.war deployed with JBOss 4.0.5 and WebLogic 9.1 appservers. We were able to successfully configure. But when we try to run the application,The Health Tab shows Status as DEAD. Is there any other configuration required to be made to get the Monitor Results.Can you please help us in this regard and suggest us any documents/links for the same. Your quick response is appreciated. Thanks in advance, :-)
Jmeter-Python
Hi.. Can any one help me regarding How to run multiple Jmeter testplans using Python I could accomplish this using Jmeter-Ant Task. But i need to do this using Python.. Any help in this regard is much appriciated :) -Thanks -Srikanth.G -SQA
