1.9 RC1 strategy for variable substitution

["BAZLEY, Sebastian" <Se...@london.sema.slb.com>]

Some musings on the new variable resolution features in 1.9.

Taking as an example the function StringFromFile:

This currently retrieves the parameter list in setParameters(), and checks
that no more than two have been supplied.

It does not extract any of the values at this stage.

In the execute() procedure, it retrieves the values using:

	fileName=((CompoundVariable)values[0]).execute(); 
	myName = ((CompoundVariable)values[1]).execute();

I think it would be better to resolve the parameters once in
setParameters(), rather than incurring the execution overhead for every
sample.

Is it useful to be able to change the variable _name_ during a test run?
Changing fileName in execute() won't have any effect unless the file happens
to be at EOF. 
One could resolve the name in the openFile() routine - that would allow for
a list of files to be used.

[I suspect that similar considerations apply to other functions which take
parameters, but I've not looked at any.]

Does that make sense, or have I missed something?

==

As far as I can tell, retrieving a JMeter variable now recalculates the
variable each time.
This means that it is possible to get a different value each time. 
This is a big change from before, and can easily lead to bugs if any
implicitly called function has side effects.

Rather than autonatically recalculating the value each time, should there
perhaps be a new function to do the recalculation and save the new value?

Either way, I think (some) samplers will have to be recoded - at present
calling HTTPSampler.toString() twice in succession can give two different
results if it has variable parameters.

-- 
The opinions expressed herein are my own, and are not necessarily endorsed
by my employer ...

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org

Re: 1.9 RC1 strategy for variable substitution

[ms...@apache.org]

On 16 May 2003 at 13:34, BAZLEY, Sebastian wrote:

> Some musings on the new variable resolution features in 1.9.
> 
> Taking as an example the function StringFromFile:
> 
> This currently retrieves the parameter list in setParameters(), and checks
> that no more than two have been supplied.
> 
> It does not extract any of the values at this stage.
> 
> In the execute() procedure, it retrieves the values using:
> 
> 	fileName=((CompoundVariable)values[0]).execute(); 
> 	myName = ((CompoundVariable)values[1]).execute();
> 
> I think it would be better to resolve the parameters once in
> setParameters(), rather than incurring the execution overhead for every
> sample.

The overhead you speak of is pretty minimal if it's just a static string.  And it is necessary that 
all functions work this way in case a user does want to embed functions or variables within 
other functions.  Having it work for some variables and not others is just asking for users to 
come back and say "why can't I do this?"  Saying "because who in their right mind would want 
to" never seems to fly, though I've tried it before....

Anyway, it is purposeful the way it works now.

> 
> Is it useful to be able to change the variable _name_ during a test run?
> Changing fileName in execute() won't have any effect unless the file happens
> to be at EOF. 
> One could resolve the name in the openFile() routine - that would allow for
> a list of files to be used.

The timing of resolving the parameters values could be changed, true.  But it would still be a 
call to execute().

> 
> [I suspect that similar considerations apply to other functions which take
> parameters, but I've not looked at any.]
> 
> Does that make sense, or have I missed something?

Both :-)

> 
> ==
> 
> As far as I can tell, retrieving a JMeter variable now recalculates the
> variable each time.

Not really.  Check out org.apache.jmeter.testelement.property.FunctionProperty.  It caches 
function values so that a function is executed only once per sample at most.  Future calls to 
retrieve the value of the function get intercepted by FunctionProperty, and a cached value is 
returned instead.  The cached value is cleared at the end of each sample.  This does need to 
be documented.

For greater control of exactly how often the function is recalculated, you can put functions into 
a User Parameters object.

> This means that it is possible to get a different value each time. 
> This is a big change from before, and can easily lead to bugs if any
> implicitly called function has side effects.
> 
> Rather than autonatically recalculating the value each time, should there
> perhaps be a new function to do the recalculation and save the new value?
> 
> Either way, I think (some) samplers will have to be recoded - at present
> calling HTTPSampler.toString() twice in succession can give two different
> results if it has variable parameters.

Have you tried it?

-Mike

> 
> -- 
> The opinions expressed herein are my own, and are not necessarily endorsed
> by my employer ...
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> 



--
Michael Stover
mstover1@apache.org
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org