You could try putting the following in a User Parameters Pre-Processor
(uncheck Update Once Per Iteration if necessary):
run_time ${__javaScript((new Date()).getTime()}
Note that the variable is omitted from the JavaScript call as it is not needed.
This works in 2.1.1
run_date could be added to the Test Plan itself, unless you want to
run tests across a day boundary. [Must omit the variable from the call
in this case, as it causes an Exception].
Or you could use a Java Sampler at the start of the thread; this would
allow you to include the values in the log file if you wanted.
S
On 24/11/05, Christensen, Alan <[EMAIL PROTECTED]> wrote:
>
> I use the following javascript to compute some time related variables:
> ${__javaScript((new Date()).getTime(),run_time)} ,
> ${__javaScript(new Date(),run_date)}
>
> I then use ${run_time} and ${run_date} later in my script to establish
> unique emails and other unique information that I need.
>
> The dilemma is where to put the javascript above. Currently I have it
> in the name field of one of the HTTP samplers that executes at the
> beginning of each thread. This works beautifully for setting the time
> variables uniquely for each "user", but it also means that the sampler
> names are all different. This causes all accesses to this URL to show
> up as separate lines in the aggregate report, rather than being
> aggregated into a single line. Is there another place where I can place
> my javascript so that it doesn't have this particular side effect?
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
