The documentation for the Java Sampler is a bit vague about precisely how it should work, but the implementation doesn't appear to be quite right. There are three methods in JavaSamplerClient: setupTest, teardownTest, and runTest. Based on the Javadoc and implementation, I would expect to see the following behavior for a single thread running 3 iterations:
setupTest runTest runTest runTest teardownTest
Unfortunately, this is not what actually happens. The easiest way to see this is to set log_level.jmeter.protocol.java=DEBUG in jmeter.properties and do a short run of the SleepTest. This reveals the behavior:
setupTest runTest setupTest runTest setupTest runTest
You will see that setupTest is run for each iteration, and teardownTest is never run at all. (These observations are based on current CVS -- I haven't checked in any of the actual releases, but posts on jmeter-user from December indicate some similar observations.
So, question #1: does everybody agree that my "expected behavior" at the top of this note is what the Java Sampler _should_ do?
Question #2: if so, how do we make it do that?
I've started some work on answering question #2, but I'm not sure quite how to proceed with it. Here are my thoughts:
In the current implementation, each setupTest/runTest pair actually gets called on a new instance of the JavaSamplerClient implementation (SleepTest in this case) from a new instance of a JavaSampler object. This is because JavaSampler extends AbstractSampler which implements PerSampleCloneable. If JavaSampler instead implements Sampler directly, it can implement PerThreadCloneable, which appears to have the desired effect of having each thread reuse a single instance of the JavaSamplerClient implementation. I think there was a bit of discussion last month about making AbstractSampler not implement PerSampleCloneable so this could be decided for each sampler even if they implement AbstractSampler.
At this point we can move the setupTest call to the JavaSampler constructor. This gives the behavior:
setupTest runTest runTest runTest
The final step is to make the call to teardownTest after the last iteration. I don't see a way to do this within the current architecture. Am I missing something? (There is lots of JMeter that I'm not familiar with yet, so it's certainly possible.)
Assuming that I'm not missing anything, my proposal would be to add two methods to the Sampler interface: startRun and endRun. This would allow the Sampler to do any necessary initialization and cleanup. I think this makes sense for a PerThreadCloneable -- I'm not so sure that it makes sense for a PerSampleCloneable. Comments?
An alternative would be to add another kind of Listener -- maybe a RunListener -- which would get events for the start and end of the run. (I guess the JMeterThreadMonitor is sort of like this -- some modifications would be necessary for JMeterThread to support multiple monitors though.) Then when the JavaSampler objects were created they would have to register themselves as RunListeners...it would probably be too late at this point to get the startRun event, but initialization could be done in the constructor anyway. Then in the endRun event they could call teardownTest. I don't like this solution as much, although maybe it would be helpful for things other than Samplers.
Other ideas? I'm happy to do the code, but I need a bit of guidance on the "right way" to implement it.
Jeremy
Jeremy Arnold [EMAIL PROTECTED] http://xirr.com/~jeremy_a
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
