You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by jarboejo <ja...@gmail.com> on 2011/03/26 00:17:43 UTC
Trouble with JMeter proxy on file upload, work around seems to fail
Hello all,
I'm using JMeter's proxy feature to record scenarios that I plan to use to
run stress against our web service later. This requires me to upload a
file. As the JMeter documentation predicts, the browser isn't sending the
full path and file name to the server and JMeter is getting confused. The
classic workaround is to put the file you want to upload in the JMeter bin
directory where JMeter will most certainly see it and be happy.
I tried that. It isn't working for me. It isn't working in Ubuntu. It
isn't working in Windows. I'm at wit's end. It seems that there is no way
to configure JMeter to snag files from a specific directory in such a way as
I can record unimpeded. And unfortunately, the scenario is more complicated
than a simple POST (such that I could simply modify the sampler and expect
success in the future); in the normal flow, there are requests and responses
that follow the initial POST that are not invoked if the first POST fails.
Has anyone else seen the workaround above fail? I haven't ruled out that
the workaround is succeeding but that some other change is being made to the
request that causes our server to reject it. That said, the current working
directory story in Java is a little convoluted and time is a factor here.
Advice?
~Joshua
--
View this message in context: http://jmeter.512774.n5.nabble.com/Trouble-with-JMeter-proxy-on-file-upload-work-around-seems-to-fail-tp4265007p4265007.html
Sent from the JMeter - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: Trouble with JMeter proxy on file upload, work around seems to fail
Posted by sebb <se...@gmail.com>.
On 25 March 2011 23:17, jarboejo <ja...@gmail.com> wrote:
> Hello all,
>
> I'm using JMeter's proxy feature to record scenarios that I plan to use to
> run stress against our web service later. This requires me to upload a
> file. As the JMeter documentation predicts, the browser isn't sending the
> full path and file name to the server and JMeter is getting confused. The
> classic workaround is to put the file you want to upload in the JMeter bin
> directory where JMeter will most certainly see it and be happy.
>
> I tried that. It isn't working for me. It isn't working in Ubuntu. It
> isn't working in Windows. I'm at wit's end. It seems that there is no way
> to configure JMeter to snag files from a specific directory in such a way as
> I can record unimpeded. And unfortunately, the scenario is more complicated
> than a simple POST (such that I could simply modify the sampler and expect
> success in the future); in the normal flow, there are requests and responses
> that follow the initial POST that are not invoked if the first POST fails.
>
> Has anyone else seen the workaround above fail? I haven't ruled out that
> the workaround is succeeding but that some other change is being made to the
> request that causes our server to reject it. That said, the current working
> directory story in Java is a little convoluted and time is a factor here.
>
> Advice?
Have you checked the jmeter log file for error messages? That should
show whether or not JMeter can find the file.
Try using a different browser.
> ~Joshua
>
> --
> View this message in context: http://jmeter.512774.n5.nabble.com/Trouble-with-JMeter-proxy-on-file-upload-work-around-seems-to-fail-tp4265007p4265007.html
> Sent from the JMeter - User mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Out of memory almost immediately after start
Posted by Cor-Paul Bezemer <c....@tudelft.nl>.
I'm investigating a problem I have with one of my testcases and when I
inspect the log file, I see the following happen:
2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
Stepping Thread Group 1-2
2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
Stepping Thread Group 1-6
2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
Stepping Thread Group 1-8
2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
Stepping Thread Group 1-10
2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
Stepping Thread Group 1-1
2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
Stepping Thread Group 1-4
2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
Stepping Thread Group 1-3
2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
Stepping Thread Group 1-5
2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
Stepping Thread Group 1-7
2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
Stepping Thread Group 1-9
2011/03/28 13:30:38 ERROR - jmeter.engine.StandardJMeterEngine: Uncaught
exception: java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Unknown Source)
at
org.apache.jmeter.engine.StandardJMeterEngine.run(StandardJMeterEngine.java:
484)
at java.lang.Thread.run(Unknown Source)
So an outofmemory exception is thrown almost immediately after starting the
tests... Does anyone have any idea what causes this?
It doesn't really seem to affect the test run but I want to make sure it
isn't.
Thanks! CP
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
RE: Out of memory almost immediately after start
Posted by Cor-Paul Bezemer <c....@tudelft.nl>.
Well actually this always happens after creating the first 10 threads,
after this hundreds of threads may be created without error messages.
CP
-----Original Message-----
From: Anthony Johnson [mailto:ansoni@gmail.com]
Sent: maandag 28 maart 2011 14:05
To: JMeter Users List
Cc: Cor-Paul Bezemer
Subject: Re: Out of memory almost immediately after start
We just had a similar thread related to this, but the problem is that
Java itself does not have enough native memory left to create a
thread.
This is going to be related to your -Xmx -Xms settings and the amount
of threads that you are asking JMeter to run.
Try lowering your thread count, setting -Xms JVM setting and/or
lowering the -Xmx value to allow for more native memory.
Their are other tricks as well, but the ones above should get you back on
track.
Good luck,
Anthony
On Mon, Mar 28, 2011 at 7:34 AM, Cor-Paul Bezemer <c....@tudelft.nl>
wrote:
> I'm investigating a problem I have with one of my testcases and when I
> inspect the log file, I see the following happen:
>
> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
> Stepping Thread Group 1-2
> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
> Stepping Thread Group 1-6
> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
> Stepping Thread Group 1-8
> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
> Stepping Thread Group 1-10
> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
> Stepping Thread Group 1-1
> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
> Stepping Thread Group 1-4
> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
> Stepping Thread Group 1-3
> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
> Stepping Thread Group 1-5
> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
> Stepping Thread Group 1-7
> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
> Stepping Thread Group 1-9
> 2011/03/28 13:30:38 ERROR - jmeter.engine.StandardJMeterEngine: Uncaught
> exception: java.lang.OutOfMemoryError: unable to create new native thread
> at java.lang.Thread.start0(Native Method)
> at java.lang.Thread.start(Unknown Source)
> at
>
org.apache.jmeter.engine.StandardJMeterEngine.run(StandardJMeterEngine.java:
> 484)
> at java.lang.Thread.run(Unknown Source)
>
> So an outofmemory exception is thrown almost immediately after starting
the
> tests... Does anyone have any idea what causes this?
> It doesn't really seem to affect the test run but I want to make sure it
> isn't.
>
> Thanks! CP
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
RE: Out of memory almost immediately after start
Posted by Cor-Paul Bezemer <c....@tudelft.nl>.
Thanks for the help everyone! After tweaking and playing around with some
stuff, I was able to run my tests the way they should.
I found that one of the problems was the proxy which seemed to delay the
requests in sort of a random fashion at large volumes.
In addition, the main thing I changed is increasing the load much slower, so
add 25 threads per 10 secs instead of 100 threads per 5 secs. Both JMeter
and and the proxy seem to respond in a more 'natural' way to this. Now let's
hope my other test cases will run smoothly after this.
Thanks again everyone :)
CP
-----Original Message-----
From: Anthony Johnson [mailto:ansoni@gmail.com]
Sent: woensdag 30 maart 2011 23:29
To: JMeter Users List
Cc: Kirk
Subject: Re: Out of memory almost immediately after start
Hi Kirk,
Java heap allocations will fragment the C Heap. PermGen memory
will fragment the C Heap. JIT Compilations will fragment the C Heap.
Java Thread creations/destruction will fragment the C Heap.
PermGen and Java Heap I can do something about. Sorry, but my answer
is still that for a memory intensive application you should be setting
your memory settings properly to get the most out of your 32 bit
memory space.
When setting the -Xms -Xmx to be the same at startup, I get 2-3 very
clean 1GB memory allocations in my process memory space. If you don't
set -Xms, then your process memory space is littered with smaller
memory allocations over the course of the process runtime. If your
blog doesn't tackle why keeping my memory space ultra clean is a bad
idea then it will not win me over.
We are both entitled to our opinion:-) I don't think we need to
continue to hi-jack this thread any further. Hopefully the parent
resolved his issue.
Thanks,
Anthony
On Tue, Mar 29, 2011 at 6:34 PM, Kirk <ki...@gmail.com> wrote:
> Hi Anthony,
>
> Setting ms to mx is a tuning/configuration mistake in most cases. I have a
blog entry that explains this (Keep your hands off of the switches iirc)
and I've another one in the pipe that very clearly exposes why you should
rarely set mx == ms.
>
> Java heap is taken from C heap. C heap is stacked on the back of stack
space in Windows and Linux. That means stack and text areas are fixed in
size at startup. If by native memory you are talking about C heap, then
point taken. That said, most Java applications should not require a lot of
native space unless they are using direct byte buffers (aka the newest
version of EHCache) or objects that create structures in C heap (eg.
file/socket descriptors).
>
>>
>> The fact that the 10th thread gets an error and thread creation is
>> fine after that does sound like some sort of OS or Java bug as sebb
>> mentioned. Hopefully the parent can make sure that he is using the
>> most recent JVM and see if the problem still occurs.
>
> This is a strange one for sure. I'd be looking in the bug database to see
whats going on. One of the things that sometimes happens is that problems
with the LD_LIBRARY_PATH case the JVM to be constructed with the wrong
versions of shared libraries. Though normally this causes the JVM to core
dump, I guess it could cause other (strange) behaviors in the JVM.
>
> Regards,
> Kirk
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: Out of memory almost immediately after start
Posted by Anthony Johnson <an...@gmail.com>.
Hi Kirk,
Java heap allocations will fragment the C Heap. PermGen memory
will fragment the C Heap. JIT Compilations will fragment the C Heap.
Java Thread creations/destruction will fragment the C Heap.
PermGen and Java Heap I can do something about. Sorry, but my answer
is still that for a memory intensive application you should be setting
your memory settings properly to get the most out of your 32 bit
memory space.
When setting the -Xms -Xmx to be the same at startup, I get 2-3 very
clean 1GB memory allocations in my process memory space. If you don't
set -Xms, then your process memory space is littered with smaller
memory allocations over the course of the process runtime. If your
blog doesn't tackle why keeping my memory space ultra clean is a bad
idea then it will not win me over.
We are both entitled to our opinion:-) I don't think we need to
continue to hi-jack this thread any further. Hopefully the parent
resolved his issue.
Thanks,
Anthony
On Tue, Mar 29, 2011 at 6:34 PM, Kirk <ki...@gmail.com> wrote:
> Hi Anthony,
>
> Setting ms to mx is a tuning/configuration mistake in most cases. I have a blog entry that explains this (Keep your hands off of the switches iirc) and I've another one in the pipe that very clearly exposes why you should rarely set mx == ms.
>
> Java heap is taken from C heap. C heap is stacked on the back of stack space in Windows and Linux. That means stack and text areas are fixed in size at startup. If by native memory you are talking about C heap, then point taken. That said, most Java applications should not require a lot of native space unless they are using direct byte buffers (aka the newest version of EHCache) or objects that create structures in C heap (eg. file/socket descriptors).
>
>>
>> The fact that the 10th thread gets an error and thread creation is
>> fine after that does sound like some sort of OS or Java bug as sebb
>> mentioned. Hopefully the parent can make sure that he is using the
>> most recent JVM and see if the problem still occurs.
>
> This is a strange one for sure. I'd be looking in the bug database to see whats going on. One of the things that sometimes happens is that problems with the LD_LIBRARY_PATH case the JVM to be constructed with the wrong versions of shared libraries. Though normally this causes the JVM to core dump, I guess it could cause other (strange) behaviors in the JVM.
>
> Regards,
> Kirk
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: Out of memory almost immediately after start
Posted by Kirk <ki...@gmail.com>.
Hi Anthony,
Setting ms to mx is a tuning/configuration mistake in most cases. I have a blog entry that explains this (Keep your hands off of the switches iirc) and I've another one in the pipe that very clearly exposes why you should rarely set mx == ms.
Java heap is taken from C heap. C heap is stacked on the back of stack space in Windows and Linux. That means stack and text areas are fixed in size at startup. If by native memory you are talking about C heap, then point taken. That said, most Java applications should not require a lot of native space unless they are using direct byte buffers (aka the newest version of EHCache) or objects that create structures in C heap (eg. file/socket descriptors).
>
> The fact that the 10th thread gets an error and thread creation is
> fine after that does sound like some sort of OS or Java bug as sebb
> mentioned. Hopefully the parent can make sure that he is using the
> most recent JVM and see if the problem still occurs.
This is a strange one for sure. I'd be looking in the bug database to see whats going on. One of the things that sometimes happens is that problems with the LD_LIBRARY_PATH case the JVM to be constructed with the wrong versions of shared libraries. Though normally this causes the JVM to core dump, I guess it could cause other (strange) behaviors in the JVM.
Regards,
Kirk
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: Out of memory almost immediately after start
Posted by Anthony Johnson <an...@gmail.com>.
Hey Kirk,
Just to clarify
If you set -Xms and -Xmx both to the same value which most people like
to do to prevent on-the-fly allocations and memory fragmentation then
you take that memory from being used as native memory. A 3GB heap
leaves 1 GB for native at most on a 32 bit system. This is one of the
major reasons that people run out of native space so quickly like the
parent is having is because they take so much memory away from native
space before the first thread is even started.
The fact that the 10th thread gets an error and thread creation is
fine after that does sound like some sort of OS or Java bug as sebb
mentioned. Hopefully the parent can make sure that he is using the
most recent JVM and see if the problem still occurs.
Thanks,
Anthony
On Mon, Mar 28, 2011 at 8:51 PM, Kirk <ki...@gmail.com> wrote:
> -Xmx sets max Java heap size where as -Xms set min Java heap size. Java threads take both Java heap and native stack space. Fiddling with these values is unlikely to have any effect on the number of threads being started. 10 threads should start without issue unless someone is consuming a ton of memory or the default JMeter memory settings have been fiddled with (like stack size).
>
> Regards,
> Kirk
>
> On Mar 28, 2011, at 2:04 PM, Anthony Johnson wrote:
>
>> We just had a similar thread related to this, but the problem is that
>> Java itself does not have enough native memory left to create a
>> thread.
>>
>> This is going to be related to your -Xmx -Xms settings and the amount
>> of threads that you are asking JMeter to run.
>>
>> Try lowering your thread count, setting -Xms JVM setting and/or
>> lowering the -Xmx value to allow for more native memory.
>>
>> Their are other tricks as well, but the ones above should get you back on track.
>>
>> Good luck,
>>
>> Anthony
>>
>> On Mon, Mar 28, 2011 at 7:34 AM, Cor-Paul Bezemer <c....@tudelft.nl> wrote:
>>> I'm investigating a problem I have with one of my testcases and when I
>>> inspect the log file, I see the following happen:
>>>
>>> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
>>> Stepping Thread Group 1-2
>>> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
>>> Stepping Thread Group 1-6
>>> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
>>> Stepping Thread Group 1-8
>>> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
>>> Stepping Thread Group 1-10
>>> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
>>> Stepping Thread Group 1-1
>>> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
>>> Stepping Thread Group 1-4
>>> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
>>> Stepping Thread Group 1-3
>>> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
>>> Stepping Thread Group 1-5
>>> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
>>> Stepping Thread Group 1-7
>>> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
>>> Stepping Thread Group 1-9
>>> 2011/03/28 13:30:38 ERROR - jmeter.engine.StandardJMeterEngine: Uncaught
>>> exception: java.lang.OutOfMemoryError: unable to create new native thread
>>> at java.lang.Thread.start0(Native Method)
>>> at java.lang.Thread.start(Unknown Source)
>>> at
>>> org.apache.jmeter.engine.StandardJMeterEngine.run(StandardJMeterEngine.java:
>>> 484)
>>> at java.lang.Thread.run(Unknown Source)
>>>
>>> So an outofmemory exception is thrown almost immediately after starting the
>>> tests... Does anyone have any idea what causes this?
>>> It doesn't really seem to affect the test run but I want to make sure it
>>> isn't.
>>>
>>> Thanks! CP
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: Out of memory almost immediately after start
Posted by Kirk <ki...@gmail.com>.
-Xmx sets max Java heap size where as -Xms set min Java heap size. Java threads take both Java heap and native stack space. Fiddling with these values is unlikely to have any effect on the number of threads being started. 10 threads should start without issue unless someone is consuming a ton of memory or the default JMeter memory settings have been fiddled with (like stack size).
Regards,
Kirk
On Mar 28, 2011, at 2:04 PM, Anthony Johnson wrote:
> We just had a similar thread related to this, but the problem is that
> Java itself does not have enough native memory left to create a
> thread.
>
> This is going to be related to your -Xmx -Xms settings and the amount
> of threads that you are asking JMeter to run.
>
> Try lowering your thread count, setting -Xms JVM setting and/or
> lowering the -Xmx value to allow for more native memory.
>
> Their are other tricks as well, but the ones above should get you back on track.
>
> Good luck,
>
> Anthony
>
> On Mon, Mar 28, 2011 at 7:34 AM, Cor-Paul Bezemer <c....@tudelft.nl> wrote:
>> I'm investigating a problem I have with one of my testcases and when I
>> inspect the log file, I see the following happen:
>>
>> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
>> Stepping Thread Group 1-2
>> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
>> Stepping Thread Group 1-6
>> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
>> Stepping Thread Group 1-8
>> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
>> Stepping Thread Group 1-10
>> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
>> Stepping Thread Group 1-1
>> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
>> Stepping Thread Group 1-4
>> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
>> Stepping Thread Group 1-3
>> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
>> Stepping Thread Group 1-5
>> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
>> Stepping Thread Group 1-7
>> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
>> Stepping Thread Group 1-9
>> 2011/03/28 13:30:38 ERROR - jmeter.engine.StandardJMeterEngine: Uncaught
>> exception: java.lang.OutOfMemoryError: unable to create new native thread
>> at java.lang.Thread.start0(Native Method)
>> at java.lang.Thread.start(Unknown Source)
>> at
>> org.apache.jmeter.engine.StandardJMeterEngine.run(StandardJMeterEngine.java:
>> 484)
>> at java.lang.Thread.run(Unknown Source)
>>
>> So an outofmemory exception is thrown almost immediately after starting the
>> tests... Does anyone have any idea what causes this?
>> It doesn't really seem to affect the test run but I want to make sure it
>> isn't.
>>
>> Thanks! CP
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: Out of memory almost immediately after start
Posted by sebb <se...@gmail.com>.
On 28 March 2011 14:10, Cor-Paul Bezemer <c....@tudelft.nl> wrote:
> Well actually this always happens after creating the first 10 threads,
> after this hundreds of threads may be created without error messages.
Is there some one-time initialisation being performed by one of the
early threads?
If so, perhaps this uses up lots of memory which is then released.
Otherwise, it sounds like a Java or OS bug.
I assume this only happens for specific test plans?
Have you tried seeing if disabling some test elements changes the behaviour?
>
> CP
>
> -----Original Message-----
> From: Anthony Johnson [mailto:ansoni@gmail.com]
> Sent: maandag 28 maart 2011 14:05
> To: JMeter Users List
> Cc: Cor-Paul Bezemer
> Subject: Re: Out of memory almost immediately after start
>
> We just had a similar thread related to this, but the problem is that
> Java itself does not have enough native memory left to create a
> thread.
>
> This is going to be related to your -Xmx -Xms settings and the amount
> of threads that you are asking JMeter to run.
>
> Try lowering your thread count, setting -Xms JVM setting and/or
> lowering the -Xmx value to allow for more native memory.
>
> Their are other tricks as well, but the ones above should get you back on
> track.
>
> Good luck,
>
> Anthony
>
> On Mon, Mar 28, 2011 at 7:34 AM, Cor-Paul Bezemer <c....@tudelft.nl>
> wrote:
>> I'm investigating a problem I have with one of my testcases and when I
>> inspect the log file, I see the following happen:
>>
>> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
>> Stepping Thread Group 1-2
>> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
>> Stepping Thread Group 1-6
>> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
>> Stepping Thread Group 1-8
>> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
>> Stepping Thread Group 1-10
>> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
>> Stepping Thread Group 1-1
>> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
>> Stepping Thread Group 1-4
>> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
>> Stepping Thread Group 1-3
>> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
>> Stepping Thread Group 1-5
>> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
>> Stepping Thread Group 1-7
>> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
>> Stepping Thread Group 1-9
>> 2011/03/28 13:30:38 ERROR - jmeter.engine.StandardJMeterEngine: Uncaught
>> exception: java.lang.OutOfMemoryError: unable to create new native thread
>> at java.lang.Thread.start0(Native Method)
>> at java.lang.Thread.start(Unknown Source)
>> at
>>
> org.apache.jmeter.engine.StandardJMeterEngine.run(StandardJMeterEngine.java:
>> 484)
>> at java.lang.Thread.run(Unknown Source)
>>
>> So an outofmemory exception is thrown almost immediately after starting
> the
>> tests... Does anyone have any idea what causes this?
>> It doesn't really seem to affect the test run but I want to make sure it
>> isn't.
>>
>> Thanks! CP
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: Out of memory almost immediately after start
Posted by Anthony Johnson <an...@gmail.com>.
We just had a similar thread related to this, but the problem is that
Java itself does not have enough native memory left to create a
thread.
This is going to be related to your -Xmx -Xms settings and the amount
of threads that you are asking JMeter to run.
Try lowering your thread count, setting -Xms JVM setting and/or
lowering the -Xmx value to allow for more native memory.
Their are other tricks as well, but the ones above should get you back on track.
Good luck,
Anthony
On Mon, Mar 28, 2011 at 7:34 AM, Cor-Paul Bezemer <c....@tudelft.nl> wrote:
> I'm investigating a problem I have with one of my testcases and when I
> inspect the log file, I see the following happen:
>
> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
> Stepping Thread Group 1-2
> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
> Stepping Thread Group 1-6
> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
> Stepping Thread Group 1-8
> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
> Stepping Thread Group 1-10
> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
> Stepping Thread Group 1-1
> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
> Stepping Thread Group 1-4
> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
> Stepping Thread Group 1-3
> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
> Stepping Thread Group 1-5
> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
> Stepping Thread Group 1-7
> 2011/03/28 13:30:38 INFO - jmeter.threads.JMeterThread: Thread started:
> Stepping Thread Group 1-9
> 2011/03/28 13:30:38 ERROR - jmeter.engine.StandardJMeterEngine: Uncaught
> exception: java.lang.OutOfMemoryError: unable to create new native thread
> at java.lang.Thread.start0(Native Method)
> at java.lang.Thread.start(Unknown Source)
> at
> org.apache.jmeter.engine.StandardJMeterEngine.run(StandardJMeterEngine.java:
> 484)
> at java.lang.Thread.run(Unknown Source)
>
> So an outofmemory exception is thrown almost immediately after starting the
> tests... Does anyone have any idea what causes this?
> It doesn't really seem to affect the test run but I want to make sure it
> isn't.
>
> Thanks! CP
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: Trouble with JMeter proxy on file upload, work around seems to fail
Posted by David Patrick <da...@mac.com>.
As Sebb suggests, do you have the right path for the file?
I presume you are passing the file name as a Post parameter to a web request and using a variable in JMeter to define that path and filename? (e.g. Upload.HTML?file=${fileVar} ) Checking the details here would be my first port of call.
Sent from my iPhone
On 25 Mar 2011, at 23:17, jarboejo <ja...@gmail.com> wrote:
> Hello all,
>
> I'm using JMeter's proxy feature to record scenarios that I plan to use to
> run stress against our web service later. This requires me to upload a
> file. As the JMeter documentation predicts, the browser isn't sending the
> full path and file name to the server and JMeter is getting confused. The
> classic workaround is to put the file you want to upload in the JMeter bin
> directory where JMeter will most certainly see it and be happy.
>
> I tried that. It isn't working for me. It isn't working in Ubuntu. It
> isn't working in Windows. I'm at wit's end. It seems that there is no way
> to configure JMeter to snag files from a specific directory in such a way as
> I can record unimpeded. And unfortunately, the scenario is more complicated
> than a simple POST (such that I could simply modify the sampler and expect
> success in the future); in the normal flow, there are requests and responses
> that follow the initial POST that are not invoked if the first POST fails.
>
> Has anyone else seen the workaround above fail? I haven't ruled out that
> the workaround is succeeding but that some other change is being made to the
> request that causes our server to reject it. That said, the current working
> directory story in Java is a little convoluted and time is a factor here.
>
> Advice?
>
> ~Joshua
>
> --
> View this message in context: http://jmeter.512774.n5.nabble.com/Trouble-with-JMeter-proxy-on-file-upload-work-around-seems-to-fail-tp4265007p4265007.html
> Sent from the JMeter - User mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org