To "fix" runtime controller, you could put the endOfLoop() check directly in the next() method. That way, it will know to return null as soon as its time is up. As it is currently, it only checks this if it's nextIsNull() method is ever called, which it won't be in the case presented in that bug - ie, where it's child is a forever loop.
This change would affect the controller, which currently only stops a run at boundaries of its children (ie, after its last child sampler, or the last child controller goes). This has the positive effect of treating the Runtime Controller's children as an inviolable group of requests that either all go, or none. If we make this change, then the Runtime Controller halts operation as soon as the time is up, even if it's on the third sampler of five. I don't see a third alternative, because the Loop Controller, when set to infinite, never sends any signals to its parent controllers on when it starts a new loop. To its children, yes, but not the parents. Which means for the Runtime Controller to decided "enough is enough", it has to make the decision arbitrarily, with no notion of where in its cycle the Loop Controller is at. Frankly, I think the scenario presented in the bug is one of the more obvious use-cases of the Runtime Controller, and I think it should be changed as I suggest. The docs would need to reflect the behavior change. -Mike On Wed, 2005-06-15 at 19:49 +0100, sebb wrote: > Various JMS test elements have no documentation - Peter, are you doing > all of these ? > - Messaging Request > - JNDI Default Configuration > - LDAPArgument List > > I can create empty place-holders, but I don't know enough to be able > to document them. > > There's a "new" bug in Runtime Controller - see > http://issues.apache.org/bugzilla/show_bug.cgi?id=35059 > > I must have broken that when I fixed various other problems with the > If, While and Once only controllers. Unfortunately I don't know how to > fix it without breaking the others ... > > AFAIK, there's no test case for the RT C, which is presumably why the > problem was not noticed earlier. I'm fairly sure that I can create a > test-case, but fixing it is another matter. > > There are of course other bugs, but the RT used to work, so it would > be good if it could be fixed. > > I still want to do some more fixes on HTTPsamplers and SampleResult > etc, but they can wait. > > BTW, the test load and save tests are failing because various extra > fields are being saved. > > S. > On 6/15/05, Peter Lin <[EMAIL PROTECTED]> wrote: > > I will finish writing the jms topic how-to and update the index number > > this weekend. > > > > > > peter > > > > > > On 6/15/05, Michael Stover <[EMAIL PROTECTED]> wrote: > > > What needs doing before we can release 2.1? As far as I'm concerned, > > > we're ready for at least a release candidate. Sebb - any todos > > > outstanding? > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
