jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jerry Pulley <>
Subject Re: TriggeredController design
Date Tue, 20 Jan 2004 07:13:55 GMT
Hi, Mike.

First, the infinite recursion issue:  I've pasted in a simple controller
and GUI that demonstrates the issue with next() returning null.  If it
is a bug in JMeter 1.9.1, the reason none of the component unit tests
found it is probably that it requires the cooperation of the loop
controller in the ThreadGroup.  The component unit tests seem to focus
on their components outside the framework.  I don't know enough about
JMeter to write a unit test that exercises the entire framework like
that, so I just made a demo instead.  Set up a ThreadGroup with the
default properties and add a NullController.  It'll dump the call stack
at the 5th iteration; that should be enough to see what's happening
before it blows the stack.  When I traced it in a debugger the problem
seemed to be in the LoopController - GenericController interaction.

At any rate, once I saw what was going on I was able to deal with that
issue by hacking a NullSampler with a trivial sample(). 

That still left the question of why my triggered controller behaved as
it did.  If it had N subelements, all N executed the first time it was
triggered, but only N-1 executed on all subsequent triggerings.  My unit
tests exercised it as far as I understand the various JMeter contracts,
but I was missing the reinitialization behavior.

Your comment about reInitialize() led me to try calling the
GenericController version of it, and that solved the issue.  Thank you
very much.  Having to return the NullSampler instead of null is keeping
GenericController from reInitialize()ing, so for the moment I'm calling
it directly.

I used to understand JMeter ok, but things have changed since 1.7.  Are
there any good writeups on the GenericController and ThreadGroup


P.S.  Sorry for the long post.  I get so excited when things start

/* NullController */
package net.jpulley.jmeter19.controller;

import org.apache.jmeter.control.GenericController;
import org.apache.jmeter.samplers.Sampler;

public class NullController extends GenericController {
    private int callCount;

    public Sampler next() {
        if (++callCount == 5) {
        return null;

/* NullControllerGui */
package net.jpulley.jmeter19.controller;

import java.awt.BorderLayout;
import org.apache.jmeter.control.gui.AbstractControllerGui;
import org.apache.jmeter.testelement.TestElement;

public class NullControllerGui extends AbstractControllerGui {
    public NullControllerGui() {
    public String getStaticLabel() {
        return "Null Controller";
    public TestElement createTestElement() {
        NullController ctlr = new NullController();
        return ctlr;
    public void modifyTestElement(TestElement element) {
    private void init() {
        setLayout( new BorderLayout() );
        setBorder( makeBorder() );
        add( makeTitlePanel(), BorderLayout.NORTH );
/*end demo*/

Heh, might as well put in the relevant parts of the stack trace:

java.lang.Exception: Stack trace
    at java.lang.Thread.dumpStack(

On Mon, 2004-01-19 at 10:43, wrote:
> The semantics of the "next()" method are supposed to be like so:
> returns Sampler - sampler is intended to be executed.
> returns null, isDone() = false: This should indicate the the controller 
> has finished a full round of iteration, and the test should move on to 
> the next controller.  If the test runs another iteration, the controller 
> should be ready for everything to begin again.  This is why the 
> "nextIsNull()" method calls reinitialize().
> returns null, isDone() = true; The controller has finished entirely, and 
> should not be run again.  Indeed, it is generally dropped from the test 
> entirely.  
> If returning null and not setting isDone to true is causing a problem, 
> that sounds like either:
> 1. You next() method is getting into and infinite recursive loop when 
> called subsequently aftering returning a null.  If you haven't explicitly 
> looked into this possibility (ie written some unit tests for it) I consider 
> this most likely.
> 2.  JMeter has been changed in some way since I last looked at it 
> that has introduced a bug, because this was not a problem 
> previously.  I think this is unlikely since this particular bug would be 
> very noticeable in nearly all tests.
> -Mike

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message