On 5 October 2011 18:14, Basim Baassiri <ba...@baassiri.ca> wrote:
> my comments inline.  I have a workaround and wanted to share my findings
>
> On Tue, Oct 4, 2011 at 8:09 PM, sebb <seb...@gmail.com> wrote:
>
>> On 4 October 2011 23:31, Basim Baassiri <ba...@baassiri.ca> wrote:
>> > my current observations are the initial 90 threads start and finish and
>> the
>> > remainder appear to be not shutting down
>> >
>> > There is a period of almost 55 mins where the logs are not being written
>> to
>> > at which point i see another thread shutdown message
>>
>> So?
>>
>> That just means that some threads are not completing, or are taking a
>> long time to do so.
>>
>> You need to find out why.
>>
>
>
> I have retrieve all embedded resources from html files set to true for the
> config element http request. Setting it to false made my test plan finish.
> I.e. i did not encounter threads not completing
>

OK, so one or more embedded resources are not being retrieved in
reasonable time.

>
>>
>> A thread dump should indicate why the threads have not finished.
>> Most likely they are waiting for a sample to complete.
>>
>> However, there are other possibilities, e.g. deadlock.
>>
>> Thread dumps tend to be very large, so save it to a file on a public
>> server and send the URL rather than posting here.
>>
>
>
> I generated a thread dump (ctrl-break) in windows
> Here it is
> http://pastie.org/pastes/2644312/text
>

Looks like several samplers are waiting for a response from the remote system.

>
>>
>> [Also, it's much harder reading long logs etc in mail messages,
>> because wrapping destroys the formatting.]
>>
>>
> agreed.
>
>
>> If the sampler supports it, you might wish to consider adding a
>> timeout; make this somewhat longer than the longest expected response
>> so you don't lose any valid responses. A few minutes might be
>> suitable, or it might have to be longer.
>>
>>
> I placed a timeout on the http response and my problem of the tests not
> finishing went away but the number of fails increased

And what were the failed samples?

Is there a pattern to them?
Can you download them with a browser?

There is no sign that JMeter is at fault here, merely that some of the
HTTP resources it has detected and tries to download are not
responding, or are responding extremely slowly.

If necessary, exclude those resources from the ones JMeter downloads.

>
>> <snip log file entries>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org
>> For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org
For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org

Reply via email to