https://issues.apache.org/bugzilla/show_bug.cgi?id=52128
--- Comment #4 from Sebb <s...@apache.org> 2011-11-04 13:00:27 UTC --- (In reply to comment #3) > (In reply to comment #2) > > Sounds like a job for the setUp and tearDown thread groups. > > > > Have you tried those? > > I can't quite see how they can solve my case. Two things I would like to note > here: > 1. If I use the setup- and tear-down threads, I still get the results of the > samples in those threads collected by my listeners. So even in this case I get > garbage. That depends where you put the Listeners. > 2. I have a testcase where one thread group runs more than one loop (in my > case > 3). Before each loop starts sampling, I have to reset a field in a DB table. > After I have sampled my JDBC test requests, I need to cleanup the data that > was > created by the sample. All I want to collect is the timings of the JDMC test > request. If I use the setup and tear-down threads, the call is only made once > before the 3 loops are executed and after all 3 loops have ended. Thus having > a > JDBC pre- and post-processor would be nice. So far I have used the BSF > porcessors with some groovy, but this is not convenient if you have pure SQL > testers. Again, you can do this by careful placement of the Listeners. Also, Pre- and Post-Processors are intended for use before/after *each sample*; the use-case here seems rather different. Although it is possible to adjust the positioning of the listeners, that can become tedious, so another possibility is to add an option to the JDBC Sampler so it returns a null sample (the Test Action Sampler does this). It should probably only nullify the result if successful. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
