RE: Capturing Errors
Skylar Sutton writes on 04 October 2005 14:26:
> Hello all, newbie to The Grinder. Using G3 Beta 27...
> While running my scripts I occasionally get an error (stems from
> database issues we are having). Due to the amount of data we would
> like to capture, I'll need to leave my script running for long
> periods of time, simply pounding the server.
> When these errors are encountered they will created an error for
> each subsequent test on that thread. Data from one test is used to
> seed the next test, thus creating a snowball of errors when one
> Is there any way to acknowledge the fact that the script has
> encountered an error and kill the Grinder instance, or better yet
> swipe that thread's data from the data log (rather than logging it
> and showing an error in the console's "errors" column).
> I just hate to collect data all night if the tests fail half way
> through. Probably less brutal to the server to just end the tests
> than keeping spitting out null parameter errors.
There's currently no API to terminate an entire process, or even
a whole thread.
If you raise an exception from __call__, the current worker thread's
run will terminate, and the engine will use the thread to start the
next run. This is what most people want, and may be right for you.
(Presumably the next run would start at the beginning of your
Other than that, I can think of 2 hacks:
1. System.exit(). This is likely to lose the last buffer
of data from your data file.
2. Have your TestRunner have a "disable" flag. When you
decide your thread/process is no longer good, set the
flag and raise an exception. Check the flag at the
beginining of __call__(). If its set, sleep for a
second and return.
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl