I agree a "finally" clause for threadgroups would be useful. Also, I think the OnceOnly controller would be a logical place to add the other functionality for executing some requests only once for the whole thread group (regardless of number of threads).
I don't think it would be overly hard. After all, all you're doing is executing a controller (a "finally" controller), and the code for doing that is already there. All that needs doing is A) turning off or removing the finally controller during the initial run, and B) running just the finally controller after that. -Mike On 18 Jun 2003 at 22:03, Jeremy Arnold wrote: > Hello, > Perhaps this is a topic for the dev list, but I'll keep it here for now. > > I don't have the details figured out yet, but it has occurred to me > before that it would be useful if JMeter supported this sort of thing > more directly. What I have in mind is that a ThreadGroup (or perhaps > other components as well) could allow you to specify some action to > occur at the end of the test. This would be sort of like a "finally" > block for the test. We could execute this action when the test is > ending -- regardless of whether the test ended normally after some > number of iterations, or if it was stopped manually by the user, or > stopped automatically by the scheduler. > > We could also consider supporting a couple different modes -- > executing the action on each thread (useful for cases like this -- > logging out users), or once for the entire test (which could allow you > to execute some servlet at the beginning of the test to start gathering > some kind of statistics, and then call another servlet at the end of the > run to stop collecting statistics), or perhaps once per host if JMeter > is running across multiple client systems. > > I think this would require a bit of work to implement (and certainly > wouldn't be available in JMeter 1.9 final), but if there is interest > then I will start to think about this a bit more. > > Jeremy > > [EMAIL PROTECTED] wrote: > > >Oh, you're right - the cookiemanager specifically won't work here (I tested on a Timer because > >it was easier). The issue is that you need the exact same CookieManager object to carry over > >from ThreadGroup to ThreadGroup, which would be tough to do. First of all, JMeter would have > >to ensure that both threadgroups had the same number of threads, then grab the objects from > >thread #1 of the first threadgroup and hand it to thread #1 of the second thread group. And this > >might produce undesired behavior for some types of components (though it is the desired > >behavior for cookie managers - the engine code knows nothing about cookie managers being a > >special type of test component). > > > >Not to say it couldn't be done, but it's not a quick enhancement. > > > >It appears we only have partial solutions to your problem currently (ie, don't use scheduled > >threadgroups, and you can do it Sebastian's original way). On another note, however - > >shouldn't you fix an application that is dependent on users manually logging out? What if they > >close their browser without logging out? What if they move to a different website? > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Michael Stover [EMAIL PROTECTED] Yahoo IM: mstover_ya ICQ: 152975688 AIM: mstover777 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
