[prev in list] [next in list] [prev in thread] [next in thread] 

List:       grinder-use
Subject:    Re: [Grinder-use] What does it mean when Grinder threads die?
From:       <Tuvell_Walter () emc ! com>
Date:       2009-08-14 17:50:34
Message-ID: 0F3F903BA6B4A54984787888AF6EA5C403525739 () CORPUSMX40A ! corp ! emc ! com
[Download RAW message or body]

Understand.  There is "nowhere" (I claim) in my script where a worker
thread can throw an unhandled exception to the framework.  That's
because I handle all exceptions that can be thrown by the worker threads
myself, and turn them into my own error msgs and GUI columns.  Nothing
showed in the GUI.

Stack-blowing is a good idea, but probably not the answer.  I indeed
have no recursion (if you exclude a guaranteed single-level recursion in
a small function I have in one place, for convenience), but I do keep
the stack size at a nice compact -Xss96k.  That value was arrived at by
calibration experiments (plus a buffer), as you might expect, and if it
were insufficient I'd expect it to show up regularly even in short
tests.  Many multi-day tests succeed, only some fail (with the same
config params).  Since the code is highly deterministic (at least as
regards dynamic code paths including stack depth), it's hard to see how
that could be the problem.  But a re-calibration is in order.

 

-----Original Message-----
From: Philip Aston [mailto:philip.aston@oracle.com] 
Sent: Friday, August 14, 2009 1:32 PM
To: grinder-use
Subject: Re: [Grinder-use] What does it mean when Grinder threads die?

If a thread exited due to an unexpected exception (i.e. anything other
than shutdown), this should have been logged.

Do you have any recursive code? I wonder whether there's an outside
chance the threads are blowing their stack and dying quietly.

- Phil

Tuvell_Walter@emc.com wrote:
> I did have runs=0, and the threads did indeed exist at the start of
the
> test, then disappeared sometime overnight.
>
> There was nothing interesting in the error_*-N.log file, and I had
> out_*-N.log and data_*-N.log turned off.  However, I write my own
(very
> extensive) logfile, and there was nothing interesting in it either, at
> least not that I saw after a cursory examination.  But the logfile was
>   
>> 1G, and I didn't search with diligence.  Had I done so, I could have
>>     
> figured out exactly which threads died, and what their last action was
> (at least at script level).
>
> I don't have those records any more, but I'll keep an eye out for
this,
> and when/if it happens again I'll contact you.
>
> Thx.
>
> - Walt
>
>
>  
>
> -----Original Message-----
> From: Philip Aston [mailto:philip.aston@oracle.com] 
> Sent: Friday, August 14, 2009 1:09 PM
> To: grinder-use
> Subject: Re: [Grinder-use] What does it mean when Grinder threads die?
>
> The threads must have exited. Assuming you have runs=0, this is hard
for
> a single thread to achieve.
>
> Does the error log give any hint?
>
> - Phil
>
> Tuvell_Walter@emc.com wrote:
>   
>> During multi-day tests, I sometimes see Grinder threads die.  What
>>     
> does
>   
>> it mean?
>>
>> For example, yesterday I started a test with grinder.threads=12.
This
>> morning, after running overnight, only 1 thread ("Grinder thread 5")
>>     
> was
>   
>> still alive, as shown both by the Grinder GUI ("Running 1/12
>>     
> threads"),
>   
>> as well as the attached jstack dump (which shows nothing else
>> suspicious, insofar as I can tell).  The one live thread was happily
>> going about its business (sending/receiving tests to the server), and
>>     
> no
>   
>> problems were posted in the Grinder GUI or in the logfile.
>>
>> In fact during this test, there were 4 Agent machines.  Besides the
>>     
> one
>   
>> just discussed, another one had 10 threads still running (2 died),
>>     
> while
>   
>> the other 2 had all 12 threads running.  And the Console machine
>>     
> seemed
>   
>> just fine, too.
>>
>> What's happening?
>>
>>
>>  <<deadThreads.txt>> 
>>
>>   
>>
>>     
>
------------------------------------------------------------------------
>   
>>     
>
------------------------------------------------------------------------
> ------
>   
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>>     
> 30-Day 
>   
>> trial. Simplify your report design, integration and deployment - and
>>     
> focus on 
>   
>> what you do best, core application coding. Discover what's new with 
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>>
>>     
>
------------------------------------------------------------------------
>   
>> _______________________________________________
>> grinder-use mailing list
>> grinder-use@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/grinder-use
>>     


------------------------------------------------------------------------
------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008
30-Day 
trial. Simplify your report design, integration and deployment - and
focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
grinder-use mailing list
grinder-use@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/grinder-use


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
grinder-use mailing list
grinder-use@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/grinder-use
[prev in list] [next in list] [prev in thread] [next in thread]