I meant to respond to this earlier, but was trying to hit a deadline for my testing.
I really agree with you here. Maybe this is as simple as dividing the Once Only Controller into a "Once Only Startup" and "Once Only Cleanup". A "Force Cleanup" flag could be included on the Cleanup Controller to force it to run even if the tests were cancelled. I like the idea of a flag to indicate whether it runs just once or once per thread. -John -----Original Message----- From: Jeremy Arnold [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 4:04 PM To: JMeter Users List Subject: Re: Logging out Users 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] Note: The information contained in this email and in any attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. The recipient should check this email and any attachments for the presence of viruses. Sender accepts no liability for any damages caused by any virus transmitted by this email. If you have received this email in error, please notify us immediately by replying to the message and delete the email from your computer. This e-mail is and any response to it will be unencrypted and, therefore, potentially unsecure. Thank you. NOVA Information Systems, Inc. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
